Hi, I think "*same* SDP is mandatory for UAS's behavior", 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 gao.yang2@xxxxxxxxxx Thu, 15 Apr 2010 16:42:48 +0800 >Hi Shinji, > >OKUMURA Shinji <shinji.okumura@xxxxxxxxxxxx> >发件人: sipping-bounces@xxxxxxxx >2010-04-15 16:22 > >收件人 >sipping@xxxxxxxx >抄送 > >主题 >Re: [Sipping] About offeranswer draft: > >Hi Gao, > >gao.yang2@xxxxxxxxxx >Thu, 15 Apr 2010 14:32:20 +0800 >>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
