Subject: [Sipping] Reconciling O/A rollback with dialog state rollback

From: Robert Sparks <[email-masked]>
Date: Mon, 28 Jul 2008 11:19:53 +0100

During the SIPPING meeting this morning, I noted discomfort around  
potential conflicts from choosing one path for rolling back offer/ 
answer and rolling back dialog state on failed re-INVITEs.

I found the diagram we looked at in Montreal describing the problem  
with dialog state - here's a copy.

Christer's proposal 2 for the offer/answer situation is to stay with  
whatever offer/answer exchange completed successfully last (perhaps in  
the INVITE/183 below). Would it also be acceptable to stay with  
whatever remote Target was successfully set last? In the diagram below  
that means the NOTIFY in question would use A'.

At the moment, I can't think of why drawing the line in the sand at  
that place would be any worse than rolling back to the beginning of  
the INVITE transaction. Further, in the case of multiple usages, it's  
arguably better - if I have a successful reSUBSCRIBE in a usage  
sharing a dialog with a pending INVITE transaction, it feels wrong  
that the whatever target that reSUBSCRIBE might have set be rolled  
back by the INVITEs failure.

So, unless someone comes up with an obvious problem with this, then  
I'm ok going with Christer's proposal 2 for offer/answer and propose  
we do a correction for 3261 clarifying the treatment of remoteTarget  
on failed target refresh transactions addressing having overlapping  
transactions that succeed.

RjS
_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: <[email-masked]>
Date: Mon, 28 Jul 2008 13:43:10 +0300

Robert,

does this mean it would still be possible to get a reply to 3GPP from
this meeting on the preferred principle?

Documenting any changes on existing RFCs like 3261 would take more time,
but we would appreciate it in 3GPP if we could get feedback on the
principle of the preferred solution. The matter is rather urgent, since
we did not find this problem in the 3GPP standards meeting, but it was
brought to 3GPP after having been detected in interop testing.

Obviously hasty decisions should be avoided, but if we cannot give any
guidance from this meeting then the implementors may have to take their
own decisions which isn't good either.

BR,
Hannu Hietalahti
3GPP CT chairman
Mobile phone: +358 40 5021724

>-----Original Message-----
>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of ext Robert Sparks
>Sent: 28 July, 2008 13:20
>To: sipping LIST
>Subject: [Sipping] Reconciling O/A rollback with dialog state rollback
>
>During the SIPPING meeting this morning, I noted discomfort 
>around potential conflicts from choosing one path for rolling 
>back offer/ answer and rolling back dialog state on failed re-INVITEs.
>
>I found the diagram we looked at in Montreal describing the 
>problem with dialog state - here's a copy.
>
>Christer's proposal 2 for the offer/answer situation is to 
>stay with whatever offer/answer exchange completed 
>successfully last (perhaps in the INVITE/183 below). Would it 
>also be acceptable to stay with whatever remote Target was 
>successfully set last? In the diagram below that means the 
>NOTIFY in question would use A'.
>
>At the moment, I can't think of why drawing the line in the 
>sand at that place would be any worse than rolling back to the 
>beginning of the INVITE transaction. Further, in the case of 
>multiple usages, it's arguably better - if I have a successful 
>reSUBSCRIBE in a usage sharing a dialog with a pending INVITE 
>transaction, it feels wrong that the whatever target that 
>reSUBSCRIBE might have set be rolled back by the INVITEs failure.
>
>So, unless someone comes up with an obvious problem with this, 
>then I'm ok going with Christer's proposal 2 for offer/answer 
>and propose we do a correction for 3261 clarifying the 
>treatment of remoteTarget on failed target refresh 
>transactions addressing having overlapping transactions that succeed.
>
>RjS
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jul 2008 09:53:30 -0400

In a private side conversation, Ian pointed out to me that my proposal 
for rule changes about when UPDATE could be used in UACs and UASs, 
doesn't work in some precondition cases. So I don't have a viable 
recommendation for how to make the rollback approach work.

More inline.

Robert Sparks wrote:
> potential conflicts from choosing one path for rolling back offer/answer 
> and rolling back dialog state on failed re-INVITEs.

I felt it was good to dissociate the two in order to allow the 
possibility that the answers for the two might be different. Yet is is 
not a bad thing if the most desirable answers for the two turn out to be 
the same.

> I found the diagram we looked at in Montreal describing the problem with 
> dialog state - here's a copy.
> 
> the INVITE/183 below). Would it also be acceptable to stay with whatever 
> remote Target was successfully set last? In the diagram below that means 
> the NOTIFY in question would use A'.

IMO it is much clearer that target changes should not be rolled back. 
AFAIK this kind of change will be the result of changing circumstances 
in the UA, and it probably is not at liberty to undo. In effect, these 
are *declared* rather than *negotiated*.

> At the moment, I can't think of why drawing the line in the sand at that 
> place would be any worse than rolling back to the beginning of the 
> INVITE transaction.

For any case where you can't reach a stable, functional, state with a 
single O/A exchange, the rollback seems to have clear advantages. 
Preconditions is one example of this. Another arises from UAs that can 
support a variety of codecs, but only one at a time. They need multiple 
O/A exchanges to reach that stable state.

If the individual O/A exchanges are committed, it means that after the 
first O/A exchange of a reinvite, a previously functional media session 
will have to be abandoned in favor of what may be an incompletely 
resolved new session. And then, if the reinvite fails, yet another O/A 
exchange will be required to attempt to get back to the previously 
existing functional state.

For example, consider the case of a reinvite intended to transition from 
a low bandwidth codec to a higher bandwidth codec, in an environment 
using preconditions to reserve bandwidth. And further, assume that the 
UAC can't support both codecs at the same time. The first exchange might 
offer the new codec, along with the old, indicate that preconditions 
haven't been resolved (because bandwidth hasn't been reserved, nor has 
which codec to use.) After the answer, this gets committed. Then the 
attempt to get increased bandwidth fails in the UAS, so it sends a 
failure to the reinvite. At that point, we are left with an agreement 
for both the low and high bandwidth codecs, which the UAC can't use 
concurrently, and no bandwidth to support the high bw codec. To fix 
this, the UAC will need to initiate another reinvite or update with an 
offer to go back to the low bandwidth codec. Until that is settled the 
session is in an awkward state.

But it seems we may have gotten ourselves into a situation where this 
approach is the only one that works.

> Further, in the case of multiple usages, it's 
> arguably better - if I have a successful reSUBSCRIBE in a usage sharing 
> a dialog with a pending INVITE transaction, it feels wrong that the 
> whatever target that reSUBSCRIBE might have set be rolled back by the 
> INVITEs failure.

Yes, I agree that the target change must stick.

> So, unless someone comes up with an obvious problem with this, then I'm 
> ok going with Christer's proposal 2 for offer/answer and propose we do a 
> correction for 3261 clarifying the treatment of remoteTarget on failed 
> target refresh transactions addressing having overlapping transactions 
> that succeed.

Well, my conclusion is that the immediate O/A commit is not a desirable 
state of affairs, but I don't see how to make the rollback of O/A work 
unambiguously. So I will reluctantly agree to go forward with the 
immediate commit of O/A. The fact that this makes it consistent with the 
treatment of other dialog state makes it a bit more palatable.

In the end, there is going to be pain for somebody no matter which way 
we go.

	Thanks,
	Paul

> ------------------------------------------------------------------------
>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 28 Jul 2008 17:50:37 +0300

Hi Hannu,

as I indicated in the SIPPING session, we hope to provide you with a 
preliminary answer before the end of this week. I say preliminary 
because, as you point out, it will take a while to update the specs.

Cheers,

Gonzalo

---

From: Bob Penfield <[email-masked]>
Date: Wed, 30 Jul 2008 08:35:28 -0400

I agree that remote target changes should not be rolled back.

I also agree that completed O/A exchanges should not be rolled back. However, I would include a recommendation that the UA that initiated the change is responsible for doing a re-INVITE to return the session to a stable/functional state if necessary (i.e. a manual rollback).

Cheers,
(-:bob

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, July 28, 2008 9:54 AM
To: Robert Sparks
Cc: sipping LIST
Subject: Re: [Sipping] Reconciling O/A rollback with dialog state rollback

More inline.

        Thanks,
        Paul

---

From: "Christer Holmberg" <[email-masked]>
Date: Wed, 30 Jul 2008 15:57:20 +0200

Hi, 

>I agree that remote target changes should not be rolled back.

I guess that would also be a good thing to document - somehow -
somewhere.

>I also agree that completed O/A exchanges should not be rolled back.
However, I would include a recommendation that the 
>UA that initiated the change is responsible for doing a re-INVITE to
return the session to a stable/functional state if 
>necessary (i.e. a manual rollback).

I agree we need to write something about that.  However, there has been
some off-line discussions on which UA should do the manual rollback, so
we need to discuss that.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Paul Kyzivat
Sent: Monday, July 28, 2008 9:54 AM
To: Robert Sparks
Cc: sipping LIST
Subject: Re: [Sipping] Reconciling O/A rollback with dialog state
rollback

More inline.

Robert Sparks wrote:
> potential conflicts from choosing one path for rolling back 
> offer/answer and rolling back dialog state on failed re-INVITEs.

> the INVITE transaction.

> Further, in the case of multiple usages, it's arguably better - if I 
> have a successful reSUBSCRIBE in a usage sharing a dialog with a 
> pending INVITE transaction, it feels wrong that the whatever target 
> that reSUBSCRIBE might have set be rolled back by the INVITEs failure.

        Thanks,
        Paul

> This list is for NEW development of the application of SIP Use 
> [email-masked] for questions on current sip Use 
> [email-masked] 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
[email-masked] for questions on current sip Use
[email-masked] 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
[email-masked] for questions on current sip Use
[email-masked] 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 [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 30 Jul 2008 11:13:49 -0400

> I also agree that completed O/A exchanges should not be rolled back. However, I would include a recommendation that the UA that initiated the change is responsible for doing a re-INVITE to return t…

I'm not certain it is that clear cut. The two sides may not have the 
same perception of what constitutes a stable state.
It may be relatively clear with preconditions, but otherwise not.
For instance I know of UAs that cannot support two codecs concurrently, 
and so always need to renegotiate if they end up with two. But it may 
only be the UAS that has a problem.

However it would also be troublesome if both initiate an attempt to fix 
it - then we get glare. But at least we have rules to handle glare.

Perhaps we need to enumerate the ways in which the resulting state may 
be non-viable. But that doesn't sound like fun.

	Paul