Hi, >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. I don't think we can have the last bullet as MUST NOT, because there are implementations doing it, and I don't think there is any existing specification which forbids it. Regards, Christer > 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 > _______________________________________________ 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
