Hi, your example is not possible. An answerer cannot downgrade theprecondition from mandatory to optional. See Section 5.2 of RFC 3312: http://tools.ietf.org/html/rfc3312#section-5.2 Desired Strength: We define an absolute ordering for the strength-tags: "none", "optional" and "mandatory". "Mandatory" is the tag with the highest grade and "none" the tag with the lowest grade. An answerer MAY upgrade the desired strength in any entry of the transaction status table, but it MUST NOT downgrade it. Therefore, it is OK to upgrade a row from "none" to "optional", from "none" to "mandatory", or from "optional" to "mandatory", but not the other way around. Cheers, Gonzalo gao.yang2@xxxxxxxxxx wrote:> > A's Offer> audio stream: audio codec 2> video stream: video codec 2 (A's preconditions, mandatory)> > B's Answer> audio stream: audio codec 2> video stream: video codec 2 (A's preconditions, optional)> > A will use> audio stream: audio codec 2> video stream: video codec 1> > B will use> audio stream: audio codec 2> video stream: video codec 2> > > It is different of "strength-tag ". And precondition itself can be > different, such as B care something A never care.> > > > *Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>*> > 2009-02-26 21:59> > > 收件人> gao.yang2@xxxxxxxxxx> 抄送> Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>, sipping > <sipping@xxxxxxxx>, sipping-bounces@xxxxxxxx> 主题> Re: 答复: Re: 答复: Re: Closing the offer/answer rollback issue> > > > > > > > > Hi,> > I am talking about the parameters you are actually *using* in your media> session. For example, you are exchanging media using a particular codec.> That is the session in use.> > Now, you may want to change that codec subject to preconditions. If> those preconditions are never met and you never get to change to the new> codec, then the session "in use" has not changed. See my original email> for an example of this situation.> > Thanks,> > Gonzalo> > gao.yang2@xxxxxxxxxx wrote:> >> > Dear Gonzalo Camarillo> >> > You mean that one side should suspend until its and the other side's> > precondition OK?> >> > I do think it is RFC3312's meaning.> >> >> > RFC3312:> > A user agent server knows that all the preconditions are met for a> > media line when its *local status table* has a value of "yes" in all> > the rows whose strength-tag is "mandatory". When the preconditions> > of all the media lines of the session are met, session establishment> > SHOULD resume.> >> > Direction Current Desired Strength> > ______________________________________> > local send no none> > local recv no none> > remote send no optional> > remote recv no none> >> > m=audio 20002 RTP/AVP 0> > a=curr:qos local sendrecv> > a=curr:qos remote none> > a=des:qos optional local sendrecv> > a=des:qos mandatory remote sendrecv> >> > It is one side's precondition. Perhaps the other side has different> > precondition.> >> > And I think one side need not to care about the other side's precondition> >> >> >> > *Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>*> >> > 2009-02-26 21:33> >> > > > 收件人> > gao.yang2@xxxxxxxxxx> > 抄送> > Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>, > sipping> > <sipping@xxxxxxxx>, sipping-bounces@xxxxxxxx> > 主题> > Re: 答复: Re: [Sipping] Closing the offer/answer > rollback issue> >> >> > > >> >> >> >> >> > Hi,> >> > > Two sides can have different precondition, so it can be one side's> > > precondition satisfied while the other's not.> >> > endpoints should not care about whether or not *some* preconditions are> > met. They just care about the *current* media state. The media state> > only changes when *all* preconditions are met.> >> > Cheers,> >> > Gonzalo> >> >> > --------------------------------------------------------> > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of this > communication to others.> > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > originator of the message. Any views expressed in this message are those > of the individual sender.> > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system.> > > > --------------------------------------------------------> ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.> This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.> This message has been scanned for viruses and Spam by ZTE Anti-Spam system. _______________________________________________Sipping mailing list https://www.ietf.org/mailman/listinfo/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
