Re: [Sipping] Is SDP in an unreliable response "the answer" ???

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux