|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
- collecting together and clarifying the rules as they are, including various inferences that are not apparent to all readers. - best practices wneh sending messages. If these best practices are followed, certain problems are avoided - best practices when receiving messages. This helps address the problem situations that may arise if the sender is doing something *valid* but which does not follow the best practices for sending.Having a best practice for sending that avoids a problem doesn't eliminate the value is documenting a best practice for coping with that problem.
Thanks, Paul OKUMURA Shinji wrote:
Christer, Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Wed, 21 Apr 2010 13:55:15 +0200Hi,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, ShinjiRegards, ChristerTo avoid this situation UAS should not ... Regards, ShinjiChrister Holmberg <christer.holmberg@xxxxxxxxxxxx> Wed, 21 Apr 2010 12:23:39 +0200applicationHi, <Dean Willis hat on>Offer/answer is a mess. Instead, let's regard media as anon top of SIP, and use an Info Package for negotiating themedia. Thereis no connection to the SIP transactions, which means we don't need complicated rules on when and where to insert SDP, and wedon't need todescribe 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 thinkanything isclarified. Eg. talking about that an SDP sent after theanswer would beincludes the"missunderstood as a new offer"is confusing. The important thing is not whether the UASUAS answer in subsequent responses or not, because the UACstill has tohandle 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@xxxxxxxxSubject: 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 +0200On Tue, Apr 20, 2010 at 3:47 PM, Paul Kyzivat <pkyzivat@xxxxxxxxx> wrote:[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/... ." ?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.I agree. And it's certainly "ignored".Regardless what the correct behaviour is, it is missing inyour 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
_______________________________________________ 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