Christer, I wanted to describe the condition strictly. But my wording was not strict and not simple. I'm sorry. However IMO we need 3 statements. - An UAS MAY insert a SDP body that is identical to the SDP answer, in an unreliable provisional response before the SDP answer has been sent. - The UAS MUST NOT insert a SDP body that is not identical to the SDP answer, in an unreliable provisional response before the SDP answer has been sent. - The UAS MUST NOT insert a SDP body in any response after the SDP answer has been sent. Regards, Shinji Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Mon, 19 Apr 2010 11:20:52 +0200 > >Hi, > >Do we really need 3 bullets to say that all SDPs included in the responses have to be the same??? > >Wording like "different SDP from the answer into before sending the answer" is also very confusing. > >Why not simply say something like: > >- A UAS MAY insert a SDP body that is identfical to the SDP answer, in a response before and after the SDP answer has been >sent. The UAS MUST NOT insert a SDP body that is not identical to the SDP answer. > >Regards, > >Christer > >> -----Original Message----- >> From: sipping-bounces@xxxxxxxx >> [mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji >> Sent: 19. huhtikuuta 2010 12:07 >> To: sipping@xxxxxxxx >> Cc: pkyzivat@xxxxxxxxx >> Subject: Re: [Sipping] Is SDP in an unreliable response "the >> answer" ??? >> >> Hi Paul, >> >> Paul Kyzivat <pkyzivat@xxxxxxxxx> >> Fri, 16 Apr 2010 18:14:28 -0400 >> >I think we are now down to the essence of the question: >> > >> >gao.yang2@xxxxxxxxxx wrote: >> > >> >> > Could you please show the text in 3261 which says that >> the SDP in >> >> an > unreliable response is the SDP answer? >> >> >> >> [Gao]: text from RFC3261: >> >> >> >> o If the initial offer is in an INVITE, the answer MUST be in a >> >> reliable non-failure message from UAS back to UAC which is >> >> correlated to that INVITE. For this >> specification, that is >> >> only the final 2xx response to that INVITE. That >> same exact >> >> answer MAY also be placed *in any provisional >> responses sent* >> >> * prior to the answer*. The UAC *MUST *treat *the >> first session* >> >> * description it receives as the answer*, and MUST >> ignore any >> >> session descriptions in subsequent responses to >> the initial >> >> INVITE. >> >> >> >> And, considering UAS send SDP in unreliable response before the >> >> answer, then the SDP would be the *the first session* >> >> * description it receives*. >> >> >> >> RFC3261 using the word "AS THE ANSWER", not as if. >> > >> >At this point, we are arguing about the *intent* of the text - it is >> >clearly confusing to some people. >> > >> >And AFAIK we (me, Gao, Shinji, and Christer) are all in >> agreement that >> >the intent of the existing text is that: >> > >> >- *if* the UAC receives SDP in an unreliable response before >> > receiving it in a reliable response, it MUST begin to use it >> > in the same way that it would use it if that SDP had been >> > received in a reliable response, >> > >> >- but that it is not officially "the answer", and so it is not >> > yet permissible to initiate another o/a exchange until a reliable >> > response containing "the answer" is received. >> > >> >- but when "the answer" is received, it MUST be ignored >> > (rather than "used") if an earlier SDP has already been >> > received and so "treated as the answer". >> > >> >Are *we* all in agreement that this is the one and only *intended* >> >meaning of the text? >> >> I agree. >> And then >> >> - UAS MAY include the same SDP as the answer into >> any provisional responses before sending the answer. >> >> - UAS MUST NOT include the different SDP from the answer into >> any provisional responses before sending the answer. >> >> - UAS MUST NOT include the any SDP into any provisional >> responses after sending the answer. >> >> we agree all of the above, don't we? >> >> >Then the issue is that *someone else* (who Gao has had >> occasion to do >> >interop testing with) is claiming that there is a different, yet >> >legitimate, interpretation of the exiting text. Namely: >> > >> >- *if* the UAC receives SDP in an unreliable response before >> > receiving it in a reliable response, it MUST begin to use it >> > in the same way that it would use it if it had been received >> > in a reliable response, >> > >> >- the UAC MUST (or SHOULD?) consider this SDP to be "the answer", >> > and hence it MAY send another offer, even before receiving >> > another copy of that answer SDP in a *reliable* response. >> > >> >- still it MUST ignore SDP in subsequent responses to the >> > INVITE. >> > >> >If so, then the question comes down to: >> > >> >Is this alternate interpretation a valid and legitimate >> interpretation >> >of the existing text, or not? >> > >> >I agree that this is a fair question to ask, and I am not >> yet settled >> >on an answer to it. >> > >> >I am approaching this in the manner of a mathematical proof by >> >contradiction: If this alternative interpretation leads to >> some sort of >> >inconsistency, then it is not valid. If we can find no >> inconsistencies, >> >then it is a valid interpretation. And if it is, then the text is >> >ambiguous and will require normative changes to fix. >> >> Even though I do not have the conviction to fill the >> precondition of the proof by contradiction... >> >> At that time if UAC sends an UPDATE with new offer, UAS >> probably rejects it with 500 response. >> >> Is it a contradiction? >> >> Regards, >> Shinji >> >> >So, we can either seek out such an inconsistency, OR we can simply >> >concede that the text is ambiguous and begin work on a normative >> >correction to address it. >> > >> >I'm pretty sure that we are going to reach the same endpoint >> either way. >> >So its a matter of whether we need a normative document to convince >> >everyone or not. >> > >> >I'd appreciate feedback on my logic above. >> > >> > Thank you, >> > Paul >> _______________________________________________ >> 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 _______________________________________________ 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
