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
