Re: About offeranswer draft:

Keith,

I agree with with the point I think you are making. But we are walking a 
fine line here. The goal has not been to enact changes with this draft. 
There are some cases where the spec is definitely ambiguous, and for 
those we have had to get another stds track doc to fix - e.g. reinvite.

In other cases the specs are far from clear, but if you read them very 
carefully some seemingly ambiguous cases can be found to be corollaries 
of existing text. In that situation, having this draft write down those 
determinations doesn't change anything but is of great aid to developers.

And then there remain cases that are ambiguous, but where some best 
practices can avoid the ambiguities.

If you were referring specifically to the comment:

> Just putting that aside for now, I think there is a consensus that
> Rc4 does not need a modification of current RFC3261.

then I am actually not sure at the moment which category this falls 
into. Its worthy of discussion.

	Thanks,
	Paul

DRAGE, Keith (Keith) wrote:
> As far as I am concerned we are NOT writing these things into offer answer
> 
> offer answer is meant to be a general clarification of what exists at the moment.
> 
> The statements you are proposing update RFC 3264 and need to be in a candidate standards track RFC that does that.
> 
> regards
> 
> Keith 
> 
>> -----Original Message-----
>> From: [email protected] 
>> [mailto:[email protected]] On Behalf Of OKUMURA Shinji
>> Sent: Wednesday, April 14, 2010 8:32 AM
>> To: [email protected]
>> Subject: Re: [Sipping] About offeranswer draft:
>>
>> Hi Gao,
>>
>> [email protected]
>> Wed, 14 Apr 2010 12:21:45 +0800
>>> [email protected] 写于 2010-04-14 11:17:23:
>>>
>>>> Hi Gao,
>>>>
>>>> In the following case,
>>>>
>>>>       UAC                   UAS
>>>>        | F1  INVITE (SDP1)   |  <-- offer
>>>>        |-------------------->|
>>>>        | F2     1xx (SDP2)   |
>>>>        |<--------------------|
>>>>        | F3     1xx (SDP3)   |
>>>>        |<--------------------|
>>>>        | F4 1xx-rel (SDP4)   |  <-- answer
>>>>        |<--------------------|
>>>>        | F5 1xx-rel (SDP5)   |
>>>>        |<--------------------|
>>>>        | F6    1xxl (SDP6)   |
>>>>        |<--------------------|
>>>>        | F7  2xx INV(SDP7)   |
>>>>        |<--------------------|
>>>>        | F8     ACK          |
>>>>        |-------------------->|
>>>>     (PRACK transactions are not shown)
>>>>
>>>> I tried to arrange the rules.
>>>> (small letters mean informational)
>>>>
>>>> UAC,
>>>> (Rc1)   MUST treat SDP2 as the answer.
>>>> (Rc2)   MUST ignore SDP5, SDP6 and SDP7.
>>>> (Rc3)   may treat SDP3 as the answer.
>>> [Gao] OK
>>>
>>>> (Rc4)   should treat SDP4 as the answer and confirm the 
>> current O/A 
>>>> status by sending new offer.
>>> [Gao] support of this, though this may be modification of 
>> current RFC3261.
>>
>> You will probably think of the following statements,
>> RFC3261/13.2.1 Creating the Initial INVITE
>> 	(snip) "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."
>>
>> No doubt this is one of the cussword built in this document.
>> It is a personal interpretation of mine,
>> 	"as the answer" is associated with not "treat" but "receives",
>> 	and "treat" means "not ignore".
>>
>> Just putting that aside for now, I think there is a consensus that
>> Rc4 does not need a modification of current RFC3261.
>>
>>>> UAS,
>>>> (Rs1)   should not send SDP5, SDP6 and SDP7.
>>>> (Rs2)   must not send SDP2 and SDP3 if these are not the 
>> same as SDP4.
>>>> Rc3 and Rc4 are new added descriptions.
>>>> Rs1 and Rs2 are current descriptions in this draft.
>>>>
>>>> I think "MUST NOT" is suitable for (Rs1).
>>>> Because RFC3261 says
>>>>    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.
>>>>
>>> [Gao] Yes.
>>>
>>>> SDP5 and SDP7 are regarded as "subsequent offers".
>>> [Gao] as "MUST NOT" is suitable for (Rs1), so there must be no 
>>> "subsequent offers" in subsequent response.
>> Certainly UAC MUST ignore SDPs no matter what these are.
>>
>> Regards,
>> Shinji
>> _______________________________________________
>> 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