Dale R. Worley wrote:
On Wed, 2005-10-19 at 12:43 -0400, Paul Kyzivat wrote:
BEWARE!
There is an ambiguity in 481: there is no way to distinguish between the
*dialog* going away and the *dialog-usage* going away.
This doesn't matter unless you are using a dialog for multiple purposes.
But suppose you had a dialog established by an invite, and within it you
sent a REFER, and thus got an implicit subscription to the refer event
package.
Then, suppose both ends send a BYE and terminate their invitation. When
the BYE reaches the other end, there will be no invite dialog usage
around, so a 481 response will be sent to the BYE. But the subscription
could still be active.
I hadn't understood that, that a BYE only terminates an INVITE dialog-
usage, and not the dialog containing it (unless there is only one
dialog-usage in the dialog).
IMO this is an artifact of shared dialogs being slipped into 3261
without enough thought. RFC3261 often talks about "dialog" when it ought
to be talking about an "invite dialog usage".
Its clearer if you look at 3265 - then termination of a subscription
does not necessarily terminate the dialog.
The way it has to work is that the dialog itself is reference counted
wrt the number of usages that share it. When all the usages are gone,
then the dialog goes away.
Certain catastrophic failures indicate that the dialog itself is broken.
In those cases it isn't entirely clear when you should still attempt to
signal to terminate each usage and when you should not. Presumably if
the problem is bad enough that signaling is futile, then all the
associated usages should be terminated.
If you establish a dialog by sending a SUBSCRIBE you don't terminate it,
or its dialog, with BYE. So its pretty clear that BYE is related to
INVITE. As a corollary, if INVITE and SUBSCRIBE are sharing a dialog
then the BYE shouldn't terminate the subscription.
In this case it is important:
- not to tear down the dialog itself while the subscribe is still active
- to explicitly terminate the subscribe when you don't want it any longer
But it does look like RFC 3261 requires that a 481 received by a UA will
cause the UA to terminate the dialog, not just the dialog-usage relevant
to the request:
Repeating myself from above: RFC3261 often talks about "dialog" when it
ought to be talking about an "invite dialog usage". There was some
discussion of this quite some time ago. It was my contention that 481
covers multiple situations that ought to have distinct codes:
- Dialog does not exist
- Call Leg Does Not Exist (a.k.a. invite dialog usage)
- Transaction does not exist
As I recall, the general opinion was that this is indeed a problem, but
that people preferred to deprecate the shared use of dialogs rather than
fix the problem. That means that when using shared dialogs one will have
to cope with the ambiguity.
Note that, as stated in Section 12.2.1.2, if the non-2xx final
response is a 481 (Call/Transaction Does Not Exist), or a 408
(Request Timeout), or no response at all is received for the re-
INVITE (that is, a timeout is returned by the INVITE client
transaction), the UAC will terminate the dialog.
In the case of a timeout, the assumption is that the target, or path to
it, is broken. This affects the dialog itself and all usages, so one
must presume that they are all to be terminated without further signaling.
But in the case of 481, there can be two causes:
- the request reached the target, but when the dialog id was
looked up, it was not found.
- the request reached the target, the dialog id was found,
but the usage required by the request (in this case the invite)
was not found.
- (the third case - transaction not found - can, I think, only
occur in cases that are unambiguous, such as a CANCEL.)
If in fact it is the usage that was missing, not the dialog, then acting
as if the dialog was gone will cause a mess. You will unnecessarily
terminate the other usages, while they remain active at the other end.
When the other end eventually sends a message for one of those usages,
it will receive a 481 in response, and then clean up.
If in fact the dialog *is* missing, and you act as if only the usage was
missing, then you will eventually get to the right state, but will
require a failed message for each additional usage to discover that.
So it is my *opinion* that the best way to cope with the ambiguity is to
treat the 481 as meaning the *usage* is missing.
Although I would expect it to be uncommon for a UA to "lose" a dialog-
usage without losing its containing dialog, so there should be little
practical penalty for having a 481 terminate the dialog.
I gave one example that can happen in practice, of glare between two
BYEs. Sounds unlikely, but I think it could be pretty easy for them to
be synchronized around a REFER - both referror and referree deciding to
drop their call.
This could in fact cause the "refer" subscription to be prematurely lost.
Paul
Dale
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
_______________________________________________
Sip-implementors mailing list
[email protected]
http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
