Re: Review of draft-ietf-mmusic-ice-sip-sdp-10
Roman Shpount <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <CAD5OKxt+Hhik8Hx9aCs+fb2yJND3=vFn+by1GqOAyoJVzE+HBA@mail.gmail.com> |
On Mon, Mar 13, 2017 at 4:51 AM, Suhas Nandakumar <[email protected]> wrote: > > Section 4.2.2.2.3 specifies, during offer processing, that the > implementation "SHOULD wait for [ICE] checks to complete" before sending an > answer. Keeping in mind that these updates typically happen with the SIP > UPDATE method, and given that RFC 3261 specifies "TUs SHOULD respond > immediately to non-INVITE requests" (cf. RFC3261 section 17.1), I'm > concerned about the timing implications here. We should minimally point out > that we're explicitly telling UAs to ignore this normative statement in > RFC3261, and make sure that we've done the analysis to ensure that we're > not going to cause problems for the SIP state machine (I'm concerned, in > particular, about unnecessary SIP retransmissions here). > > [Suhas] - I am not aware of any analysis being done. What do you suggest > we need to do ? > > I think current draft assumes that answers to session updates are note sent until ICE nomination is complete. I do not think this is realistic, especially when continuous nomination is used. My suggestion is to allow offer/answer exchanges in while ICE nomination is in process. I would also suggest that complete current list of ICE candidates should be sent in each of those of exchanges. I have sent the suggestion regarding this in earlier email today. Regards, _____________ Roman Shpount _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic