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
