Subject: [Sip] Re: Dialog usage: Forking impacts

From: "Christer Holmberg" <[email-masked]>
Date: Tue, 7 Mar 2006 00:18:57 +0200

Hi Paul,

It is true that both 2 and 3 can establish early dialogs with 1. The issue, as I said in another mail, is that when 200 OK is received UA_1 may terminate all other early dialogs - not only specific dialoge usages.

The problem is of course that RFC3261 does not talk about dialog usages - only "full" dialoges.

Regards,

Christer

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Mar 2006 18:20:44 -0500

> It is true that both 2 and 3 can establish early dialogs with 1. The issue, as I said in another mail, is that when 200 OK is received UA_1 may terminate all other early dialogs - not only specific…

So your issue is that UA_1, by using a different interpretation of 3261, 
may decide it should terminate the complete dialog and all usages, and 
so have unintended consequences. Once again I agree that pointing this 
out would be a good thing.

> The problem is of course that RFC3261 does not talk about dialog usages - only "full" dialoges.

The way I think of it is 3261 did, at least implicitly, define both the 
concept of the dialog and the dialog usage, as distinct things. But it 
inadvertently gave them both the same name. Sometimes it uses that name 
to talk about dialogs, and other times to talk about dialog usages. The 
reader is left to sort out the ambiguity.

Its as if you had two acquaintances, both named Bob, and you talk about 
them both to your friends:
- Bob is a great software engineer
- Bob is a slimy SOB lawyer
- Bob is next to me coding up the latest dialog usage implementation
- Bob is in Texas watching the defendant in his latest trial be executed
- Bob has red hair

Often you can figure out from context which Bob is being referenced. But 
not always.

	Paul

---

From: "Dale R. Worley" <[email-masked]>
Date: Tue, 07 Mar 2006 23:17:18 -0500

> reader is left to sort out the ambiguity.

I would say it a bit differently:  The writers of 3261 didn't fully
conceptualize the distinction between dialog and dialog usage, and used
the same word for both.  We are now realizing that the distinction needs
to be made, and have to sort out the ambiguities in the original text.

The evidence that we are doing this correctly is that we can construct a
simple model (a dialog is a bundle of dialog usages, whose existence is
implicitly controlled by the existence of the usages) and that when 3261
is disambiguated in the light of that model:

1) the logic of the protocol remains fairly simple,
2) lots of messy edge cases "just work out" to give the results you'd
really want in the first place, and
3) it provides a clean, systematic framework for almost any imaginable
extension of the current "shared usage" situation.

However, there is one nit that needs to be dealt with, I think.  Since
messages can be reordered by the network, a UA can see the termination
of the last usage that it knows of in a dialog (e.g., receiving the 200
for a BYE) before it receives the initiation of another usage (e.g.,
receiving a SUBSCRIBE), while the other UA may have sent the SUBSCRIBE
before receiving the BYE.  So whether there are any usages of a dialog
active at a moment is not knowable by a UA.

This means that the dialog state (the route set and the CSseq's) has to
be kept around for a while after the UA thinks the dialog has ended.
Does there need to be a timer for disposing of this information?  Or can
we sleaze it by having the SUBSCRIBE re-establish the dialog state at
the other UA?  I don't think that works, as the sender of the SUBSCRIBE
expects the NOTIFYs to have CSeq's that continue from whatever it last
received, so the UAS for the SUBSCRIBE must not have thrown away its
state for that dialog.

So I think we need to define a timer, "length of time after the
termination of the last dialog usage you know of in a dialog that you
can start a new usage" (probably 0), and "length of time after the
termination of the last dialog usage you know of in a dialog that you
can safely delete your dialog state information" (3 minutes?).

Dale

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 8 Mar 2006 09:59:11 +0100

Dale,

> active at a moment is not knowable by a UA.

I think "active usages" needs to be defined in a way that ~is~ knowable for 
a UA. If not, things become too complex since you cannot define logic / 
rules in terms of unknown state. So I would define active usages as "all 
usages that have state!=terminated".

In the above scenario, once the first UA sends its BYE the invite usage is 
terminated (as per RFC4235, reading it as if "call" really means 
"invite-usage"). Though this has not been explicitly stated (to my 
knowledge), I think a UA should not accept incoming new usages when no more 
active usages remain in the dialog.

> received, so the UAS for the SUBSCRIBE must not have thrown away its

Following my line of reasoning above, the UA should refuse the new usage (I 
would say using a 481 response). Hence there is no need to keep the dialog 
state around. draft-ietf-sipping-dialogusage-01 does not make the 
distinction between "termination" and "destruction" (yet), I believe this 
remains something to be discussed.

> can start a new usage" (probably 0),

In other words, the UA should not start (initiate) a new usage when all 
existing usages have terminated. I argue that it should also not accept new 
usages

> and "length of time after the

Here I believe we need the distinction between "termination" and 
"destruction" (==deletion in your wording). Usages are terminated when 
sending BYE, NOTIFY w/ terminated, etc. They are destroyed when a response 
to the "termination request" comes back, or when there is a timeout.

The dialog is considered terminated ( "ended" in your text above ) when all 
usages are terminated, i.e. termination requests have been sent / received 
for all of them. The dialog is destroyed after the last usage has been 
destroyed (in other words: when there are no more active transactions).

There would be no need for a separate timer, all of the above is done using 
the regular transaction timers.

Regards,

jeroen

---

From: Zhou Hong <[email-masked]>
Date: Wed, 08 Mar 2006 17:39:27 +0800

I think maybe we can define a new dialog state Zombie before state 
Terminated. in this state not receive and deal with any new dialog 
usages,otherwise terminate all old  dialog usages. The dialog state change 
to Terminated when all dialog usages finished.

Hong