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

Here is my attempt at summarizing the discussion conclusions:

Normative things (stated or implied in existing RFCs):

- If the UAC sent an offer in the INVITE, then after it receives SDP 
(the answer) in a reliable response to the INVITE, any SDP in subsequent 
responses to the INVITE MUST be ignored.

- Further, if SDP is received in an unreliable response to the invite 
prior to receiving SDP in a reliable response, then it MUST be treated 
as the answer for purposes of media processing, but not for purposes of 
determining when another offer may be sent or received.

- if the UAS receives an offer in the INVITE, it MUST NOT include SDP in 
any response it sends until it has determined the intended answer SDP to 
the offer.

- once the intended answer SDP is determined, it MUST be sent in a 
reliable response to the INVITE. It MAY be sent in one or more 
*preceding* unreliable provisional responses.

Non-normative, best practice suggestions:

- if the UAS receives an offer in the invite, once it has sent the 
answer in a reliable response, it should not send any SDP in subsequent 
responses to the INVITE.

	Thanks,
	Paul

Christer Holmberg wrote:
> 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