Subject: [sipcore] 答复: Re: New revision of the re-INVITE handling draft

From: [email-masked]
Date: Thu, 23 Jul 2009 19:31:39 +0800

Hi，

  It seems that clear definition of "legacy UAS" is necessary too.

Also, if the UAC sends a re-INVITE with SDP that is "sendonly",
does the UAC have rules to determine whether the UAS use the new 
paramters, 
or not?

Regards,
Eric

GaoYang140197/user/zte_ltd 写于 2009-07-23 17:11:56:

> Hi,
> 
> I don't know way mail list's *sometimes* has problem in dispacting my 
mail.
> 
> For your question:
> 
> In fact, this is a backword-compatible problem. And IMO，it gives 
> out a way to synchronize session state for UAC and UAS. Which 
> session state for synchronization is proper can be deduced from 
> media streams *in use*. So, this is the same question as *in use* 
definition.
> 
> Thanks.
> 
> Gao
> 
> ===================================
>  Zip    : 210012
>  Tel    : 87211
>  Tel2   :(+86)-025-52877211
>  e_mail : [email-masked]
> ===================================
> 
> WangLiBo135681/user/zte_ltd
> 2009-07-23 16:46
> 
> 收件人
> 
> GaoYang140197/user/zte_ltd@zte_ltd
> 
> 抄送
> 
> Gonzalo Camarillo <[email-masked]>, Paul Kyzivat 
> <[email-masked]>, OKUMURA Shinji <[email-masked]>, SIPCORE
> <[email-masked]>, [email-masked]
> 
> 主题
> 
> 答复: Re: [sipcore] New revision of the re-INVITE handling draft
> 
> hi,
> 
>    Pity can't receive your mails dispatched from the list =_=!!
> 
>    I read the draft again. It seems the states are useless.If re-
> INVITE is accepted,
> everything is ok.And if re-INVITE is rejected, UAC generate a new 
> re-INVITE with 
> old state, they don't need to concern about which state they were 
> at. Is it right?
> 
> 6.  UAC Behavior
> 
>    The behavior of a UAC communicating with a UAS that supports this
>    specification (i.e., a UAS that follows the guidelines in Section 5)
>    is straight forward.  However, a UAC may face a legacy UAS that uses
>    an error response to undo already-executed changes within a re-
>    INVITE.
> 
>    In order to cope with this type of UAS, a UAC that receives an error
>    response to a re-INVITE for which changes have been already executed
>    SHOULD generate a new re-INVITE or UPDATE request in order to make
>    sure that both UAs have a common view of the state of the session.
>    The purpose of this new offer/answer exchange is to synchronize both
>    UAs, not to request changes that the UAS may choose to reject.
>    Therefore, the session parameters in the offer/answer exchange SHOULD
>    be as close as those in the pre-re-INVITE state as possible.
> 
> 

> 
> GaoYang140197/user/zte_ltd 写于 2009-07-23 16:11:05:
> 
> > Hi,
> > 
> > I am agree with Gonzalo. And Wang Libo(my colleague)'s question is 
> > the same as Shinji's. Accessory is my mail for Shinji(but I don't 
> > know why this mail was not dispatched by mail list).
> > 
> > My means is that time point of "in use" has no impact on the 
> > rationality of the way(new UPDATE/200OK) handling session state's 
> > rollback here.
> > The rationality of choosed session state for rollback is separate 
> > from the way proposed by draft-camarillo-sipcore-reinvite-00. It is 
> > RFC3264 concerned. And as RFC3264 does not consider session 
> > modification overlaps more than one O/A pairs, such as precondition,
> > we need clarification for it. But I think it can be a separate text.
> > 
> > Thanks.
> > 
> > Gao
> > 
> > ////////////////////////////////////////////////////mail for 
> > Shinji///////////////////////////////////////////////////////////
> > 
> > Hi Shinji,
> > 
> > About non-2xx of Re-INVITE:
> > The way proposed in draft-camarillo-sipcore-reinvite-00 is 
> > *forbiding* non-2xx of Re-INVITE after O/A.
> > So, your example is not exist along the way of draft-camarillo-
> > sipcore-reinvite-00. And the alternative way for rejecting sessin 
> > modification here is using a new UPDATE/200OK  before the 2xx of Re-
> > INVITE. I think it is effective here. What's your points?
> > 
> > About "in use":
> > 
> > The meaning of "in use"(as defined in RFC3264): When answerer send 
> > new media stream(or send media using new parameters), media is "in 
> > use". And for offerer, it considers the new parameters to be in use 
> > when (new) media is received or using new parameters.
> > So, the meaning of "in use" is quit clear here.
> > 
> > The time point of "in use": it is dependent on cases:
> > 
> > Case 1: Changing audio stream's codec without precondition and 
> > adding vedio stream with precondition.
> > Modification of audio would be "in use" before precondition satisfied.
> > 
> > Case 2: Changing audio stream's codec with precondition and and 
> > adding vedio stream with precondition.
> > Modification of audio would be "in use" on the point of 
> preconditionsatisfied.
> > 
> > Case 3: Adding vedio stream with precondition, which needs user's 
decision.
> > As in preconditon use cases, user of UAS only has the chance to 
> > decide accepting/rejecting session modification after precondition
> satisfied. 
> > Vedion stream would be "in use" after precondition satisfied.
> > 
> > While using a new UPDATE/200OK pair before final response of Re-
> > INVITE, the time point of "in use" has no impact on the session state.
> > 
> > Thanks.
> > 
> > Gao
> > 
> > ////////////////////////////////////////////end of the mail for 
> > Shinji///////////////////////////////////////////////////////
> > 
> > ===================================
> >  Zip    : 210012
> >  Tel    : 87211
> >  Tel2   :(+86)-025-52877211
> >  e_mail : [email-masked]
> > ===================================
> > 
> > Gonzalo Camarillo <[email-masked]> 
> > 2009-07-23 15:43
> > 
> > 收件人
> > 
> > [email-masked]
> > 
> > 抄送
> > 
> > [email-masked], Paul Kyzivat <[email-masked]>, SIPCORE 
> > <[email-masked]>, [email-masked]
> > 
> > 主题
> > 
> > Re: [sipcore] New revision of the re-INVITE handling draft
> > 
> > Hi,
> > 
> > >   In order to make "Already-executed Changes" clear, the draft 
should 
> > > state 
> > > when UAS/UAC start to listen on the new port, and when UAS/UAC use 
> > > new media parameters. It's essential for users to find the 
rightstate, I 
> > > think.
> > > 
> > 
> > yes, it is essential. In any case, the draft will not define anything
> > new in this respect. We will use the definition in RFC 3264 and 
clarify
> > it if needed.
> > 
> > Thanks for your comments,
> > 
> > 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.