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
