Dear Christer Holmberg
In the Version 02 of my draft, I add "new modification"'s definition. You said you have a urgent issue this week, so perhaps you did not have time to read it :).
The framework of nested transaction is open for "codec refine" as sub-transaction or not.
Two main work of my draft is:
1. introducing nested transaction to session modification( this is for current and future).
2. define the cascade of nested transaction for current usages.
In fact, "codec refine" concerns to 2.
And it is in Version 00 and 01. If you and other think it is useful, I will added it again.
yours Gao
| "Christer Holmberg"
<christer.holmberg@xxxxxxxxxxxx>
2009-02-26 21:46 |
|
Hi,
>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.
Yes, but the question is to clearly define what a "new modfication" is. I think your draft doesn't define it clear enough (or, 3264 is not clear enough). Also, you may have offers/answer which contain both modifications and notifications.
Solution 1:
---------------
One could of course say that if the SDP version number is modified, then it is a new modification - no matter what has changed.
But, I THINK one has to update the SDP version number also for pure precondition notifications, so I am not sure it would work.
Solution 2:
---------------
Another way would be to recommend against using new modifications inside re-INVITEs. In real life I think the most common use-cases are going to be things like codec refine etc.
>I should point out that, the definition in "a new modification" just obeys RFC3264. But any organization or operator can add it definition.
3GPP, OMA, TISPAN, IETF etc shall NOT make their own definitions - there should be a common one. That's the main reason 3GPP sent the LS to IETF in the first place.
Becuase, if I call from my 3GPP client to an IETF client, the re-INVITE fails and 3GPP and IETF have different "defintions", we are in the same situation where we are today.
>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.
Everybody have to treat it in the same way. You can not assume that both endpoints are specified by the same "organization". Both the UAC and the UAS has to know what the status is if the re-INVITE fails.
Regards,
Christer
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.
-------------------------------------------------------- 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
