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