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

Anders,

Thanks for identifying this. I should have remembered.

So that is a case we don't have to cope with.

	THanks,
	Paul

Anders Kristensen wrote:
> 
> 
> On 4/20/2010 7:04 AM, Paul Kyzivat wrote:
>>
>>
>> DRAGE, Keith (Keith) wrote:
>>> Do remember that there are certain cases where the UAC will not ignore
>>> it. These are the cases where the message containing original answer
>>> has not yet arrived or been lost, and the protocol has not yet
>>> recovered from that.
>>
>> Hmm. Can you say more?
>>
>> Are you thinking of a case where the answer has been sent in a reliable
>> provisional, but the PRACK has not yet been received? And then that
>> *some* SDP is included in a subsequent unreliable provisional, or 2xx?
>>
>> That is an interesting case. The one that would be least wierd is:
>>
>> UAC UAS
>> | INVITE (SDP1) |
>> |----------------->|
>> | 1xx REL (SDP2) |
>> | X--------------|
>> | 2xx (no SDP) |
>> |<-----------------|
> 
> This is not a valid case. It's explicitly ruled out by 3262:
> 
>    If the UAS had placed a session description in any reliable
>    provisional response that is unacknowledged when the INVITE is
>    accepted, the UAS MUST delay sending the 2xx until the provisional
>    response is acknowledged.  Otherwise, the reliability of the 1xx
>    cannot be guaranteed, and reliability is needed for proper operation
>    of the offer/answer exchange.
> 
> Thanks,
> Anders
> 
>>
>> I think that implies a different best practice:
>>
>> If the UAS has sent an answer in a reliable provisional, if it sends a
>> 2xx before receiving a prack of the answer, it should include the answer
>> in the 2xx as well.
>>
>> (If the UAS intends to initiate another o/a it MUST await the prack, so
>> if the 1xx is lost it will be retransmitted.)
>>
>> Thanks,
>> Paul
>>
>>
>>
>>
>> | |
>> |<-----------------|
>> | |
>> | |
>> |----------------->|
>> | |
>> |<-----------------|
>> | |
>> | |
>> |----------------->|
>> | |
>> |<-----------------|
>> | |
>> | |
>> |----------------->|
>> | |
>> |<-----------------|
>> | |
>> | |
>> |----------------->|
>> | |
>> |<-----------------|
>> | |
>>
>>> regards
>>>
>>> Keith
>>>
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:[email protected]] On
>>>> Behalf Of Christer Holmberg
>>>> Sent: Tuesday, April 20, 2010 1:47 PM
>>>> To: OKUMURA Shinji; [email protected]
>>>> Subject: Re: [Sipping] Is SDP in an unreliable response "the answer" 
>>>> ???
>>>>
>>>>
>>>> Hi,
>>>>>>> Before sending an answer,
>>>>>>> - An UAS MAY send unreliable provisional responses with a SDP.
>>>>>>> - And the SDP MUST be identical to an answer SDP.
>>>>>>>
>>>>>>> After sending an answer,
>>>>>>> - The UAS should not insert a SDP in any response.
>>>>>>>
>>>>>>> Is this OK?
>>>>>> That text still doesn't say what an SDP inserted after sending the
>>>>>> answer means, only that it should not be sent.
>>>>> The SDP means nothing. it is neither an offer nor an answer.
>>>> Exactly. In my opinion that is what is important - not whether the
>>>> UAS inserts SDP or not.
>>>>
>>>>>> I still don't see why we need to make a separation about SDP sent
>>>>>> before and after the answer, because in both cases the SDP must be
>>>>>> identical to the answer.
>>>>> 1. RFC3261 says that UAS MAY send it before the answer and
>>>>> doesn't say nothing after the answer.
>>>> That is one reason why we are writing the draft - to clarify things
>>>> which may not be clear in the specs.
>>>>
>>>>> 2. The SDP MUST be ignored by UAC. it is meaningless.
>>>> I agree, and that is what we must be clear about. Because, as we
>>>> know, some people want to send a NEW offer (or updated answer) in a
>>>> subsequent response, and that is not allowed.
>>>>
>>>>
>>>>> 3. if another o/a exchange is occured (using UPDATE or
>>>> PRACK), it is not even a confirmation.
>>>>> And, again, I know there are many implementations that send
>>>> a copy of
>>>>> the SDP after the SDP answer has been sent, so instead of
>>>> saying that
>>>>> it should not be done I think it is much more important to
>>>> say that, if
>>>>> it is done, it must be identical to the SDP answer. In other
>>>> words, to
>>>>> make it clear that the UAS can not send a NEW offer (or
>>>> updated answer)
>>>>> in a subsequent response after the SDP answer has been sent.
>>>>>
>>>>> Since UAC MUST ignored it, there is no problem on a interworking.
>>>>> Why must it be identical to the SDP answer?
>>>> Well, if you look at it that way, fine. But, then the important thing
>>>> is that the UAC must ignore it - not that the UAS should not send it.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>
>>>>
>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Christer
>>>>>>
>>>>>> Hans Erik van Elburg <[email protected]> Mon, 19 Apr 2010
>>>>>> 13:55:41 +0200
>>>>>>>> - 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.
>>>>>>>>
>>>>>>> This is terribly confusing. Very probabe that noone will
>>>>> get it right.
>>>>>>> Triple negation. And talking about sending and answer before the
>>>>>>> answer has been sent. ???
>>>>>>>
>>>>>>>
>>>>>>>> - The UAS MUST NOT insert a SDP body in any response
>>>>> after the SDP
>>>>>>>> answer has been sent.
>>>>>>>>
>>>>>>> This means that you can't send it again after you've send
>>>> it in an
>>>>>>> unreliable provisional response. Do you want tto say that?
>>>>>>>
>>>>>>> /Hans Erik van Elburg
>>>> _______________________________________________
>>>> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
>>>> This list is for NEW development of the application of SIP Use
>>>> [email protected] for questions on current sip Use
>>>> [email protected] 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 [email protected] for questions on current sip
>>> Use [email protected] 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 [email protected] for questions on current sip
>> Use [email protected] 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 [email protected] for questions on current sip
> Use [email protected] 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 [email protected] for questions on current sip
Use [email protected] for new developments of core SIP