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
