Re: [Sipping] About offeranswer draft:

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Paul,

You say in another message,
>- but when "the answer" is received, it MUST be ignored
>  (rather than "used") if an earlier SDP has already been
>  received and so "treated as the answer".

I agree this is the one and only *intended* meaning of
the text.

Regards,
Shinji

Paul Kyzivat <pkyzivat@xxxxxxxxx>
Fri, 16 Apr 2010 19:16:10 -0400
>OKUMURA Shinji wrote:
>> Hi,
>> 
>> gao.yang2@xxxxxxxxxx
>> Thu, 15 Apr 2010 17:14:09 +0800
>>> Hi,
>>>
>>> OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx> 
>>> 发件人:  sipping-bounces@xxxxxxxx
>>> 2010-04-15 17:07
>>>
>>> 收件人
>>> sipping@xxxxxxxx
>>> 抄送
>>>
>>> 主题
>>> 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
>
>I think this is again getting into the realm of "how should the UAC 
>behave if the UAS is non-conforming?"
>
>We are not obligated to clarify that at all, though we *may* provide a 
>suggestion if it seems important.
>
>But I am opposed to expecting the UAC to detect the non-conformance in 
>order to take specific remedial action. I think that is what "should UAC 
>refresh the media plane by the real answer" is talking about.
>
>*If* the UAC detects this non-conformance (the indeterminacy), then it 
>*could* attempt to remedy it by "refreshing the media plane". But there 
>may be indeterminacy that has not been detected. I guess that too could 
>be remedied by doing an extra O/A to "refresh". But that would increase 
>the number of messages in cases when there is no indeterminacy at all. 
>And if the refresh were attempted using a reINVITE, it could simply lead 
>to yet another indeterminacy.
>
>So I prefer to say nothing about the "refresh" in this draft.
>
>	Thanks,
>	Paul
>
>>>>> 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip
Use sip@xxxxxxxx for new developments of core SIP


[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux