| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-02-26 20:43 |
|
Hi,
>"late commitment" of modification triggered by Re-INVITE is important from user's experience.
Assume I send a re-INVITE with an offer, without preconditions or UPDATEs. If the receiving user is prompted to accept/reject the offer, I don't think there will be a 18x with an answer. If the receiving user accepts the offer there will be a 200 with the answer, or if the receiving user rejects the offer there will be some error response.
[Gao] I agree with you. Without precondition or UPDATE is simple, and the session state is clear.
Then, assume I send a re-INVITE with an offer, WITH preconditions, UPDATEs etc etc etc. At some point the re-INVITE will either be rejected or accepted.
So, would it not be easier to ALWAYS apply "late commitment" - no matter whether there are preconditions, UPDATEs or not?
And, that would be the same as saying that there is a full rollback if the re-INVITE fails.
[Gao] Precondition notification and a new modification will make different result.
Precondition notification is part of the orignal modification triggered by Re-INVITE, so it obeys "late commitment".
A new modification is a new one, so it have nothing to do with Re-INVITE and its final response.
So, the session state is clear.
I re-arrage the Rules in version 02 by the talk in the mail list with you and others, I think it is more readable.
I should point out that, the definition in "a new modification" just obeys RFC3264. But any organization or operator can add it definition.
Such as "refine of Codec", some people in or out of my corporation treat it is part of the original the modification; some treat it not.
In the framework of nested transaction, it is just the form of the nested transaction. Any understanding has clear session state.
As IETF's text are the base of others, so I omit any definition beyond RFCs.
>And UPDATE race condition has a solution in theory in my draft. BCP proposal is anonther way :)
Yes.
Regards,
Christer
If you have time now, I'd like to have a further talk now.
yours Gao
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx> 发件人: sipping-bounces@xxxxxxxx 2009-02-26 20:05 |
|
Hi,
If we want to go for a solution where the precondition state matters,
there is one issue:
Assume that one side has indicated that his preconditions are met, but
the other side has still not indicated it. What happens now if the
re-INVITE fails?
I ASSUME we would have to say that if all preconditons - on both sides -
are met, the change is comitted and there is no fallback. If the
preconditions are met only on one side, and the re-INVITE fails, there
is a fallback. Or?
In addition, there is also the "late commitment" concept by Gao.
I am afraid that we make all this too complicated for its own good. The
easiest solution is to say that all changes are commited (or current
agreement), OR that there is always a full rollback if the re-INVITE
fails.
The second alternative was favored e.g. by Paul, but the problem was the
UPDATE race condition. But, that could be solved by the BCP proposal by
Gao: use UPDATEs only "inside" a re-INVITE transaction.
It is also quite difficult to discuss this per e-mail: a face-to-face
meeting, with a big whiteboard, would be much better. But, AFAIK many of
the key persons in this issue are not coming to SFO, so I don't know
when such meeting could take place...
Regards,
Christer
-----Original Message-----
From: sipping-bounces@xxxxxxxx [mailto:sipping-bounces@xxxxxxxx] On
Behalf Of Gonzalo Camarillo
Sent: Thursday, February 26, 2009 1:43 PM
To: sipping
Subject: [Sipping] Closing the offer/answer rollback issue
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
_______________________________________________
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.
-------------------------------------------------------- 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
