[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Bob Penfield wrote:

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).
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


Cheers,
(-:bob

-----Original Message-----
From: sipping-bounces at ietf.org [mailto:sipping-bounces at ietf.org] 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

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:

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 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.

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'.


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


------------------------------------------------------------------------

_______________________________________________
Sipping mailing list  https://www.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org 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 at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP