Dear Gonzalo Camarillo and all the people in the SIPPING mail list:
I think this problem is important. We should choose a right way for the future.
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. :)
I think my draft have solved this problem, and without any violation of current RFCs. But I still prefer the inspection from the people outside the SIPPING mail list.
Gao
| Gonzalo Camarillo <Gonzalo.Camarillo@xxxxxxxxxxxx>
发件人: sipping-bounces@xxxxxxxx 2009-02-26 19:42 |
|
Folks,
it is time to close the offer/answer rollback issue. We need to make a
decision and move forward.
We face this issue when one or more offer/answer exchanges are
successfully completed within a re-INVITE that ends up failing. The
question is, what should the session state be after the re-INVITE fails.
For more details on this issue, see:
http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-10#section-6.2
A more-or-less straight forward solution would be to specify that the
session state should be that of the last offer/answer exchange that was
completed successfully. We lose the atomicity of the re-INVITE, but it
is a price most people seem willing to pay according to our discussions.
Now, there is an additional issue with this solution. What happens if
the last successfully completed offer/answer exchange contained
preconditions that were never met? In that case, media changes in that
offer/answer exchange that were affected by the preconditions had not
been executed. Per RFC3312:
http://tools.ietf.org/html/rfc3312#section-6
"However, offers containing
preconditions sent in the middle of an ongoing session need further
explanation. Both user agents SHOULD continue using the old session
parameters until all the mandatory preconditions are met. "
A solution to this issue could be to specify that, when the re-INVITE
fails, the session state should be that which is *in use* at that point.
Of course, we need to clarify what "in use" exactly means. The idea
would be the following:
An INVITE request establishes a session:
INVITE
------------------>
200
<------------------
After this first offer/answer exchange, we have an audio stream and a
video stream using the following codecs:
audio stream: audio codec 1
video stream: video codec 1
Now we have a re-INVITE with an offer that changes the codec for the
audio stream to audio codec 2 and the video codec to video codec 2. The
change in the video codec is subject to preconditions. The answer
arrives in a reliable 1xx response:
audio stream: audio codec 2
video stream: video codec 2 (subject to preconditions)
re-INVITE
------------------>
1xx
<------------------
Now, the session state in use is the following:
audio stream: audio codec 2
video stream: video codec 1
The video codec has not been changed (yet) because the preconditions for
the video stream has not been met yet.
Now, the re-INVITE fails with a 4xx response. The session state *in use*
would be the one above, which is a mixture between the first the second
offer/answer exchanges. The state of the audio stream comes from the
second exchange while the state of the video stream comes from the first
exchange (because the preconditions in the second exchange for that
media stream were never met).
At this point, the endpoints could perform a new offer/answer exchange
just to make sure they both are on the same page.
Do people think it would be worthwhile specifying/clarifying this *in
use* concept?
We would appreciate comments on this because, as stated above, we would
like to close this in a relatively short time.
Thanks,
Gonzalo
_______________________________________________
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
