Christer, Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Wed, 21 Apr 2010 13:55:15 +0200 >Hi, > >>I understand that this is a very rare case, >> >> A B >> | | >> |INVITE (offer) | >> |================================>| >> | 1xx-rel(answer)| >> |<===========\ /=================| >> | \/ | >> | /\ 18x-norel(answer)| >> |<===========/ \=================| >> |PRACK | >> |-------------------------------->| >> | | >> >>IIUC, if 18x-norel has a SDP(answer), UAC(A) can not insert >>new offer into PRACK. > >You now seem to be suggesting that an SDP answer can be >transported unreliably. I strongly disagree to such statement. NO. An SDP answer transported unreliably is only a "preview" of the true answer. I know it well. >A copy of the SDP answer can be sent unreliably, and the UAC can >use it, but the "real" SDP answer must still be sent reliably. > >Maybe "ignore" is the wrong wording. The UAC cannot ignore >the fact that the reliable response contains the SDP answer, >because THAT SDP finishes the offer/answer transaction, >but it does not need to parse it. That's right. "ignore" confuse me. Another clarification is necessary. If 18x-norel has no SDP, this confusion can not be occured. Because offer/answer rules are complicated enough, somening unnecessary should not exist. It's "Best" Current Practices, I think. Regards, Shinji >Regards, > >Christer > >> >> To avoid this situation UAS should not ... >> >> Regards, >> Shinji >> >> Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Wed, 21 >> Apr 2010 12:23:39 +0200 >> >Hi, >> > >> ><Dean Willis hat on> >> > >> >Offer/answer is a mess. Instead, let's regard media as an >> application >> >on top of SIP, and use an Info Package for negotiating the >> media. There >> >is no connection to the SIP transactions, which means we don't need >> >complicated rules on when and where to insert SDP, and we >> don't need to >> >describe how offer/answer works for re-INVITEs etc. >> > >> ><Dean Willis hat off> >> > >> >I don't disagree with what people are saying, but trying to read it >> >from a I-am-a-new-implementor-and-I-would-like-to- >> >get-it-right-from-the-beginning perspective I don't think >> anything is >> >clarified. Eg. talking about that an SDP sent after the >> answer would be >> >"missunderstood as a new offer" >> >is confusing. The important thing is not whether the UAS >> includes the >> >UAS answer in subsequent responses or not, because the UAC >> still has to >> >handle such situation. >> >What is important is that the UAS MUST NOT send a *new* offer. >> > >> >Regards, >> > >> >Christer >> > >> >> -----Original Message----- >> >> From: sipping-bounces@xxxxxxxx >> >> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji >> >> Sent: 21. huhtikuuta 2010 8:45 >> >> To: sipping@xxxxxxxx >> >> Subject: Re: [Sipping] Is SDP in an unreliable response >> "the answer" ??? >> >> >> >> Hi, >> >> >> >> Hans Erik van Elburg <ietf.hanserik@xxxxxxxxx> Tue, 20 Apr 2010 >> >> 21:53:17 +0200 >> >> >On Tue, Apr 20, 2010 at 3:47 PM, Paul Kyzivat <pkyzivat@xxxxxxxxx> wrote: >> >> >> Here is my attempt at summarizing the discussion conclusions: >> >> >> >> >> >> Normative things (stated or implied in existing RFCs): >> >> >> >> >> >> - If the UAC sent an offer in the INVITE, then after it receives >> >> >> SDP (the >> >> >> answer) in a reliable response to the INVITE, any SDP in >> >> >> subsequent responses to the INVITE MUST be ignored. >> >> >> >> >> >> - Further, if SDP is received in an unreliable response to the >> >> >> invite prior to receiving SDP in a reliable response, then it MUST >> >> >> be treated as the answer for purposes of media processing, but not >> >> >> for purposes of determining when another offer may be sent or received. >> >> >> >> >> >[HE] I miss what the UAC should do in this case for subsequent >> >> >responses, does the following hold as well: >> >> >"If the UAC sent an offer in the INVITE, then after it receives SDP >> >> >(the answer) in an unreliable response to the INVITE, any SDP in >> >> >subsequent responses to the INVITE MUST be ignored/granted/... ." ? >> >> >> >> I agree. And it's certainly "ignored". >> >> >> >> >Regardless what the correct behaviour is, it is missing in >> >> your summary. >> >> > >> >> >> - if the UAS receives an offer in the INVITE, it MUST NOT include >> >> >> SDP in any response it sends until it has determined the intended >> >> >> answer SDP to the offer. >> >> >> >> >> >> - once the intended answer SDP is determined, it MUST be sent in a >> >> >> reliable response to the INVITE. It MAY be sent in one or more >> >> >> *preceding* unreliable provisional responses. >> >> >> >> >> >> Non-normative, best practice suggestions: >> >> >> >> >> >> - if the UAS receives an offer in the invite, once it has sent the >> >> >> answer in a reliable response, it should not send any SDP in >> >> >> subsequent responses to the INVITE. _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
