Re: About offeranswer draft:

Hi,

[email protected]
Thu, 15 Apr 2010 17:14:09 +0800
>Hi,
>
>OKUMURA Shinji <[email protected]> 
>发件人:  [email protected]
>2010-04-15 17:07
>
>收件人
>[email protected]
>抄送
>
>主题
>Re: [Sipping] About offeranswer draft:
>
>Hi,
>
>I think "*same* SDP is mandatory for UAS's behavior",
>
>[Gao] As you think *same* if mandatory, why not just ignore the real 
>answer, if it has gotten one in one previous unreliable response?

Because I am a kind man for an ill-behaved UAS.

nantene

>and
>"That same exact answer MAY also be placed in any provisional
>responses sent prior to the answer." means it adequately for me.
>
>Regards,
>Shinji
>
>
>>>Hi Paul and Shinji,
>>>
>>>I guess I can converge my discussion on the point, should UAC refresh the 
>>>media plane by the real answer? 
>>>
>>>Or, just ignore the real answer, if it has gotten one in one previous 
>>>unreliable response?
>>
>>IMO UAC should refresh the current view of a session description
>>by the real answer.
>>
>>[Gao] By myself, I also prefer this one.
>> 
>>>And no matter what direction we choose, we should do the evaluation about 
>>>whether it is violation/correction of RFC3261.
>>
>>I think, in RFC3261 UAC's behavior is described based on the
>>premise that UAS never include the different SDP from the answer
>>into the prior unreliable responcse.
>>It is absolutely an implicit premise. But it is not bad, I think.
>>
>>So then we can think that UAC's behavior for the different SDP
>>is not described in RFC. Therefor it can be BCP and does not
>>violate RFC.
>>
>>[Gao] If we want to BCP thing for different SDP, we need to clarify that 
>>*same* SDP is not mandatory for UAS's behavior.
>>I am not sure whether "*same* SDP is not mandatory for UAS's behavior" is 
>
>>normative change from RFC3261 or not.
>>
>>Quod Erat Demonstrandum.
>>
>>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