Hi, The text talks about generating additional offers, but not about including a copy of previously sent ones. Regards, Christer > -----Original Message----- > From: sipping-bounces@xxxxxxxx > [mailto:sipping-bounces@xxxxxxxx] On Behalf Of OKUMURA Shinji > Sent: 19. huhtikuuta 2010 14:50 > To: sipping@xxxxxxxx > Subject: Re: [Sipping] Is SDP in an unreliable response "the > answer" ??? > > Christer, > > I don't intend to be strongly particular about the last "MUST NOT". > > But RFC3261 say, > o Once the UAS has sent or received an answer to the initial > offer, it MUST NOT generate subsequent offers in any > responses > to the initial INVITE. This means that a UAS based on this > specification alone can never generate subsequent > offers until > completion of the initial transaction. > > What do the above statements forbid? > > Regards, > Shinji > > Christer Holmberg <christer.holmberg@xxxxxxxxxxxx> Mon, 19 > Apr 2010 13:32:12 +0200 > > > >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 > _______________________________________________ > 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
