答复: Re: 答复: Re: 答复: Re: 答复: Re: Closing the offer/answer rollback issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Thanks for your correct.

If one side without precondition, the other with. It might make different view.


And in fact, by my proposal, "late commitment" is the final commitment of Re-INVITE.
Two side's differet view of precondition will not violate the rollback.








Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>

2009-02-26 22:11

收件人
gao.yang2@xxxxxxxxxx
抄送
Christer Holmberg <christer.holmberg@xxxxxxxxxxxx>, sipping <sipping@xxxxxxxx>, sipping-bounces@xxxxxxxx
主题
Re: 答复: Re: 答复: Re: 答复: Re: [Sipping] Closing the offer/answer rollback issue





Hi,

your example is not possible. An answerer cannot downgrade the
precondition 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: [Sipping] 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.



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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux