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

I agree with Shinji below. But there are three things going on in this 
draft:

- collecting together and clarifying the rules as they are,
   including various inferences that are not apparent to
   all readers.

- best practices wneh sending messages.
   If these best practices are followed, certain
   problems are avoided

- best practices when receiving messages.
   This helps address the problem situations that
   may arise if the sender is doing something
   *valid* but which does not follow the best
   practices for sending.

Having a best practice for sending that avoids a problem doesn't 
eliminate the value is documenting a best practice for coping with that 
problem.

	Thanks,
	Paul

OKUMURA Shinji wrote:
> Christer,
> 
> Christer Holmberg <[email protected]>
> Wed, 21 Apr 2010 13:55:15 +0200
>> Hi, 
>>
>>> I understand that this is a very rare case,
>>>
>>>         A                                 B
>>>         |                                 |
>>>         |INVITE (offer)                   |
>>>         |================================>|
>>>         |                  1xx-rel(answer)|
>>>         |<===========\  /=================|
>>>         |             \/                  |
>>>         |             /\ 18x-norel(answer)|
>>>         |<===========/  \=================|
>>>         |PRACK                            |
>>>         |-------------------------------->|
>>>         |                                 |
>>>
>>> IIUC, if 18x-norel has a SDP(answer), UAC(A) can not insert 
>>> new offer into PRACK.
>> You now seem to be suggesting that an SDP answer can be
>> transported unreliably. I strongly disagree to such statement.
> 
> NO. An SDP answer transported unreliably is only a "preview" of
> the true answer.
> I know it well.
> 
>> A copy of the SDP answer can be sent unreliably, and the UAC can
>> use it, but the "real" SDP answer must still be sent reliably.
>>
>> Maybe "ignore" is the wrong wording. The UAC cannot ignore
>> the fact that the reliable response contains the SDP answer,
>> because THAT SDP finishes the offer/answer transaction,
>> but it does not need to parse it.
> 
> That's right. "ignore" confuse me. Another clarification is
> necessary.
> 
> If 18x-norel has no SDP, this confusion can not be occured.
> Because offer/answer rules are complicated enough,
> somening unnecessary should not exist.
> 
> It's "Best" Current Practices, I think.

> Regards,
> Shinji
> 
>> Regards,
>>
>> Christer
>>
>>> To avoid this situation UAS should not ...
>>>
>>> Regards,
>>> Shinji
>>>
>>> Christer Holmberg <[email protected]> Wed, 21 
>>> Apr 2010 12:23:39 +0200
>>>> Hi,
>>>>
>>>> <Dean Willis hat on>
>>>>
>>>> Offer/answer is a mess. Instead, let's regard media as an 
>>> application 
>>>> on top of SIP, and use an Info Package for negotiating the 
>>> media. There 
>>>> is no connection to the SIP transactions, which means we don't need 
>>>> complicated rules on when and where to insert SDP, and we 
>>> don't need to 
>>>> describe how offer/answer works for re-INVITEs etc.
>>>>
>>>> <Dean Willis hat off>
>>>>
>>>> I don't disagree with what people are saying, but trying to read it 
>>> >from a I-am-a-new-implementor-and-I-would-like-to-
>>>> get-it-right-from-the-beginning perspective I don't think 
>>> anything is 
>>>> clarified. Eg. talking about that an SDP sent after the 
>>> answer would be 
>>>> "missunderstood as a new offer"
>>>> is confusing. The important thing is not whether the UAS 
>>> includes the 
>>>> UAS answer in subsequent responses or not, because the UAC 
>>> still has to 
>>>> handle such situation.
>>>> What is important is that the UAS MUST NOT send a *new* offer.
>>>>
>>>> Regards,
>>>>
>>>> Christer
>>>>
>>>>> -----Original Message-----
>>>>> From: [email protected]
>>>>> [mailto:[email protected]] On Behalf Of OKUMURA Shinji
>>>>> Sent: 21. huhtikuuta 2010 8:45
>>>>> To: [email protected]
>>>>> Subject: Re: [Sipping] Is SDP in an unreliable response 
>>> "the answer" ???
>>>>> Hi,
>>>>>
>>>>> Hans Erik van Elburg <[email protected]> Tue, 20 Apr 2010 
>>>>> 21:53:17 +0200
>>>>>> On Tue, Apr 20, 2010 at 3:47 PM, Paul Kyzivat <[email protected]> wrote:
>>>>>>> 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.
>>>>>>>
>>>>>> [HE] I miss what the UAC should do in this case for subsequent 
>>>>>> responses, does the following hold as well:
>>>>>> "If the UAC sent an offer in the INVITE, then after it receives SDP 
>>>>>> (the answer) in an unreliable response to the INVITE, any SDP in 
>>>>>> subsequent responses to the INVITE MUST be ignored/granted/... ." ?
>>>>> I agree. And it's certainly "ignored".
>>>>>
>>>>>> Regardless what the correct behaviour is, it is missing in
>>>>> your summary.
>>>>>>> - 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.
> _______________________________________________
> 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