Hi,
I don't want to distinguish "refine codec", because then we
may later find out other things that should also be
distinguished.
In my opinion "refine codec" is as much modification as
anything else.
Regards,
Christer
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On Behalf Of gao.yang2@xxxxxxxxxx
Sent: Thursday, February 26, 2009 4:39 PM
To: Paul Kyzivat
Cc: sipping; Gonzalo Camarillo
Subject: [Sipping] 答复: Re: 答复: Re: 答复: Closing the offer/answer rollback issue
Dear Paul Kyzivat
What is "a new modification" by user's view will make the cascade of the O/A pairs in modification.
And we should give user the session state they anticipanted.
Precondition notification is not "a new modification". And most of the people would agree this.
And distinguish it is not a hard way.
Another well known is "refine codec", it is also practical to distinguish it.
And it really open the door for complex modification using more than one O/A pair as precondition.
Gao
| Paul Kyzivat
<pkyzivat@xxxxxxxxx>
2009-02-26 22:11 |
|
Gonzalo,
I think your proposal/concept about "in use" is interesting.
But is is it in fact the case that all involved parties agree on what
that is?
I think this could especially be a problem for B2BUAs that don't
terminate media. Their *only* knowledge about the current state is what
they have learned from the signaling. Based on that they may have to
decide which SDP reflects what is currently "in use". But perhaps this
isn't really a problem and the B2BUA will simply discover the current
state later based on subsequent interactions with the two UAs.
Also, "using" has two parts: "sending" and "receiving". There are
definitely windows during which one end is "sending" something but the
other side isn't "receiving" it yet.
There are also those middleboxes that control "media gates" - only
letting media pass if the O/A conforms to their policies. Its unclear to
me how they are affected by this decision. But it could enhance the
difference between what one side is sending and the other side is receiving.
Replying to Gao/Christer - I remain confused about what constitutes a
"new modification". I know there are sequences in use where the initial
exchange is done with a=inactive, and then another o/a is exchanged,
within the (re)INVITE to switch to a=sendrecv. Is that a "new
modification", or not?
Thanks,
Paul
Gonzalo Camarillo wrote:
> Hi,
>
> what I would like to know is if rolling back to the session state "in
> use" is an acceptable solution for you.
>
> Thanks,
>
> Gonzalo
>
>
> gao.yang2@xxxxxxxxxx wrote:
>> I think we are talking the same thing :).
>>
>> The main problem is What the session state is.
>>
>> Perhaps I said somthing on How to have a clear session state. I think
>> the two has correlation.
>>
>>
>>
>>
>> *Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>*
>>
>> 2009-02-26 21:30
>>
>>
>> 收件人
>> gao.yang2@xxxxxxxxxx
>> 抄送
>> sipping <sipping@xxxxxxxx>, sipping-bounces@xxxxxxxx
>> 主题
>> Re: 答复: [Sipping] Closing the offer/answer rollback issue
>>
>>
>>
>>
>>
>>
>>
>>
>> Hi,
>>
>> > I think this problem is important. We should choose a right way for the
>> > future.
>>
>> yes, that is why we should make a decision, close it, and move forward.
>>
>> > Could we make the main proposal(such as mine and Christer Holmberg's) as
>> > a WG draft. I think it is important to let the people outside the
>> > SIPPING mail list to join in the disccussion, if they want. :)
>>
>> we already have a WG draft. What we are discussing here is how to close
>> an open issue within that draft. I made a concrete proposal on this
>> thread and asked for feedback on it. Please, focus on discussing that
>> point so that we can move forward. If you want to discuss different
>> issues, feel free to do it in a different thread.
>>
>> Thanks,
>>
>> 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.
>
> _______________________________________________
> 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
-------------------------------------------------------- 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
