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