Re: About offeranswer draft:

OKUMURA Shinji wrote:
> 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

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 [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