Subject: [Sipping] About "rollback of re-Invite" - Explanation of precondition notification.

From: [email-masked]
Date: Thu, 19 Feb 2009 20:02:18 +0800

I will added it in to next version. As:

Suspending/resuming of session modification is session level issue, so any 
m-lines with precondition will make session suspended.

Any Offer/Answer without any other modification of session except for 
precondition notification, and is during suspending state of session 
modification is called precondition notification.

Any modification except for precondition notification will make the 
Offer/Answer a new modification.

Any Offer/Answer without any other modification of session except for 
precondition notification, but after suspending state of session 
modification MUST NOT be treated as precondition notification anymore. It 
is a new modification.

WangLiBo135681/user/zte_ltd
2009-02-19 19:54

收件人
"Christer Holmberg" <[email-masked]>
抄送
[email-masked], [email-masked]
主题
答复: RE: Re: [Sipping] About "rollback of re-Invite" - case with 
preconditions met when reINVITE fails

Hi， 

I agree, we should find a way cover all use-cases. 

Firstly, i think, we should try to find a way  to solve all problem in 
certain 
terms, and then make the way as a suggestion. 

   Just as the words in RFC3311: 
   ""Although UPDATE can be used on confirmed 
   dialogs, it is RECOMMENDED that a re-INVITE be used instead."" 

Secondly, we use the finding way to all use-cases, and enrich the way with 

some patches in order to let the suggested way cover all use-cases. 

For UPDATEs and re-INVITEs, there are three common cases. 

case 1: UPDATEs are for pre-condition in the re-INVITEs. 
case 2: UPDATEs are new modifications outside the re-INVITEs. 
case 3: UPDATEs are new modifications just during the re-INVITEs, 
    but obey the offer/answer model. 

Followed are solutions for the above three case. 

case 1: It's just a pre-condition notification, if failure happens, 
    rollback to the state before the re-INVITE. 

case 2: This UPDATE can be distinguished from others easily, and should 
    refresh the state if successful, and remain the state just before 
    UDPATE if failure. 

case 3: We should record the state if negotiation is successful,and 
rollback 
    to the state before UPDATE if failure happens. 

    And there is a rule: if both UPDATE and re-INVITE success, we should 
    record the state commited by UPDATE. if UPDATE successes and re-INVITE 
fails, 
    we should record the state commited by UPDATE. if UPDATE fails and 
re-INVITE 
    successes ,we should record the state commited by re-INVITE.If both 
fail, 
    we should rollback the state before re-INVITE. 
    
    This case is also mentioned in 
"draft-gaoyang-sipping-session-state-criterion-01" 
    4.3.1  Problem. 

From above, UPDATEs outside re-INVITEs make the solution much more 
difficult, 
we have to find which UPDATEs are for notifications and which are not. We 
should 
determine which state to commit when both success.Also if UDPATEs can be 
raised at 
any time ,more 491 and 500+retry will be found, and so on. 

So i suggest UPDATEs with SDP should better be replaced by re-INVITE，but 
that not 
means forbidden，just a suggestion. 
And there also are solutions to solve all UPDATEs. 

Waiting for your comments. 

Begards, 

Eric.wang 

"Christer Holmberg" <[email-masked]> 写于 2009-02-19 
16:24:03:

> 
> Hi,
> 
> 
> >In my opinion,the re-INVITE should fallback to the state before the
> re-INVITE. 
> >And it doesn't matter what the precodition state is. Because the 
> re-INVITE is 
> >rejected,the state of its precondition state seems useless. 
> >
> >By limiting UDPATEs for new modification outside re-INVITE,we can find 
the 
> >right state to fallback. 
> 
> This issue does only talk about UPDATEs "inside" the re-INVITE.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
>    "Christer Holmberg" <[email-masked]> 写于 
> 2009-02-19 03:24:04:
> 
>    > Hi, 
>    > 
>    > Let's look into this precondition proposal. 
>    > 
>    > There are some issues that needs to be taken into consideration. 
>    > 
>    > Issue 2: 
>    > ----------- 
>    > 
>    > Assume I send a re-INVITE, and I use precondition. I modify the 
SDP,
>    > and indicate that preconditions are not met.
>    > 
>    > Then I receive a relaible 18x, and the first offer/answer 
>    > transaction has succeeded. 
>    > 
>    > Later I send an UPDATE request, where I indicate that 
> preconditions are met. 
>    > 
>    > Then I receive a 200 for the UPDATE, indicating that preconditions 
>    > are met also at the other end. 
>    > 
>    > Then the re-INVITE fails. Now, according to the ZTE proposal, is 
>    > there a full fallback? The UPDATE was sent as part of the nested 
>    > precondition procedure, but the preconditions were fullfilled 
before
>    > the re-INVITE failed? 
>    > 
>    > Does it matter what the precondition state is when the re-INVITE 
>    > fails, or is there always a full fallback? 
>    > 
>    > Regards, 
>    > 
>    > Christer 
>    > 
> 
>    --------------------------------------------------------
>    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.