Re: About "rollback of re-Invite" - case with precondition and non-precondition

"Christer Holmberg" <christer.holmberg@xxxxxxxxxxxx> · Thu, 19 Feb 2009 11:09:03 +0100

Hi,

Maybe my example was bad.

What if the audio m- line is modified in one of the 
UPDATEs, and not in the re-INVITE.

Regards,

Christer

  From: gao.yang2@xxxxxxxxxx 
  [mailto:gao.yang2@xxxxxxxxxx] 
Sent: 19. helmikuuta 2009 
  12:06
To: Christer Holmberg
Cc: sipping@xxxxxxxx; 
  wang.libo@xxxxxxxxxx
Subject: 答复: RE: RE:  About "rollback 
  of re-Invite" - case with precondition and 
  non-precondition

Dear Christer Holmberg 

The audio should rollback. The reason is 
  "late commitment of 200OK of Re-INVITE". 

Make 
  your example simple:

The SDP before the re-INVITE:

m=audio 
  codec1

SDP offer in re-INVITE:

m=audio codec2

SDP 
  answer in 18x:

m=audio codec2 

4xx 
  response to the re-INVITE. 

And the 
  session state should rollback to code1, too. 

The reason is that 200OK(Re-INVITW) is the final commitment of the 
  modification triggered by Re-INVITE. And this is defined in RFC3261, 
  emphasized again in RFC3311. 

Gaoyang 

      "Christer Holmberg" 
        <christer.holmberg@xxxxxxxxxxxx> 
        2009-02-19 16:34 

              收件人
            <gao.yang2@xxxxxxxxxx> 

              抄送
            <sipping@xxxxxxxx>, 
              <wang.libo@xxxxxxxxxx> 

              主题
            RE: RE:  About "rollback 
              of re-Invite" - case with precondition and 
          non-precondition

Hi,

>One m- line uses preconditions, and 
  the other doesn't is legitimate SDP in Offer/Answer pair. 

Yes, and 
  that is why I raised the issue :)

>But the semantics of 
  suspending/resuming of session modification defined in RFC3312 is session 
  level definition. So, any m-line with precondition would make the session with 
  precondition. 

>And RFC3264 do not define the ability of 
  accepting/rejecting of m-line separately, so I think make Offer/Answer pair as 
  the smallest transaction is adequate currently. And make m-line level 

>accepting/rejecting/suspending/resuming is attractive for me, and I'd 
  like to talk it(later). 

Note that I am not talking about rejecting m- 
  lines. All offer/answers succeed, but the question is related to the fallback 
  when the re-INVITE fails.

>But the new Offer/Answer pair can be 
  treated as precondition notification of the previous modification only when 
  its other parts of SDP without modification. So, removing/adding of codec in 
  any m-line(precondition m-line 
>or no-preconditon m-line) will make it 
  beyond precondition notification. 

For the m- line which uses 
  preconditions the offer/answer may be treated as a notification, but for the 
  m- line which does NOT use preconditions it is more than that. So, in case of 
  re-INVITE failure one needs to know whether the "fate" of the two m- lines are 
  different.

Let's take an example:

The SDP before the 
  re-INVITE:

m=audio codec1
m=video codec2

SDP offer in 
  re-INVITE:

m=audio codec2
m=video codec9, precon=not 
  met

SDP answer in 18x:

m=audio codec2
m=video codec9, 
  precon=not met

Now, after this the audio m- line o/a should be 
  comitted, because no preconditions were used.

SDP offer in 
  UPDATE

m=audio codec2               

   (No change)
m=video codec9, precon=met         
          ("notification")

SDP answer in 200 
  (UPDATE)

m=audio codec2
m=video codec9, 
  precon=met

4xx response to the re-INVITE.

Now, 
  according to your proposal, the video m- line should be rolled back to codec2 
  (the state before the re-INVITE), since preconditions were used.

But, 
  what happens to the audio m- line 
  modfication?

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.

_______________________________________________
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