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