Subject: [Sip] draft-kaplan-sip-session-id-00.txt

From: "Dale Worley" <[email-masked]>
Date: Wed, 03 Dec 2008 12:28:41 -0500

I'm getting a bit confused by this discussion, and I think part of the
problem is terminology:

Let's avoid using the word "match" unless we mean a process which has
the usual properties of "match":  (1) If A matches B, then B matches A.
(2) If A matches B, then A and B are considered to some degree to be the
same thing.  Thus, if two requests have the same Via branch parameters,
they "match" because they are (should be) identical.  And if two
requests have the same call-id and tags, then they "match" because they
are part of the same dialog.  (And that relationship is symmetric.)

I think what people want is the concept "references".  If A references
B, then B does not necessarily reference A.  Thus, a dialog event
package references a dialog, but the dialog does not reference the
dialog event package.

I believe that we intend for two message to have the same Session-Id if
and only if they are legs of the same dialog (in the sense that each leg
was generated by a B2BUA as a continuation of another leg).  (Actually,
that should be "dialog set", as created by one out-of-dialog request.)

Dale

_______________________________________________
Sip mailing list  https://www.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: Wed, 03 Dec 2008 13:29:41 -0500

> that should be "dialog set", as created by one out-of-dialog request.)

This is still very fuzzy to me.

If a B2BUA (B) is doing 3pcc:

	         |------ C
	         |
	A ------ B
	         |
	         |------ D

and it first connects A to C, and later transfers the call to D, will A 
and C and D all have the same Session-Id?

Then take same picture, but make B be a conference focus, to which A, C 
and D are all connected. Will they ever have the same Session-Id?

Also, how are dialog event packages supposed to work? Is it expected 
that they will be extended to contain Session-Ids?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 14:18:37 -0500

I use the word "match" because the property of "matching" is what I mean.  "A" does have to equal "B" symmetrically, but the thing that is symmetric is the Session-ID ("A" and "B" are Session-IDs).
The "Reference" portion is to the general concept of a SIP session (or "dialog-set if you prefer), not the specific dialog leg defined by a call-id+tag set, so you could say a Session-ID is a reference to a collection of dialog legs.
The Session-ID alone does NOT really reference a specific call-id+tag set, for example.
For some cases that's all you need to match to get an action/property you desire, for example for correlating SIP messages in a wireshark trace.
In other cases you need to match both a Session-ID and a remote-tag, in order to "reference" a specific dialog leg - for example in a Replaces case.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale
> Worley
> Sent: Wednesday, December 03, 2008 12:29 PM
> To: SIP
> Subject: [Sip] draft-kaplan-sip-session-id-00.txt
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 15:07:41 -0500

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul
> Kyzivat
> Sent: Wednesday, December 03, 2008 1:30 PM
>

Yes, under the current model it would.  It's not a necessary scenario to have the same Session-ID, IMO, but it's covered that way. (but clearly the remote-tag would not match if D sent a Subscribe to A)

> and D are all connected. Will they ever have the same Session-Id?

As currently defined no, it would not.  I talked to some people about that at the IETF meeting, and they thought that was the right thing to do, as do I; but we couldn't define a textual explanation of what properties made that right.

> that they will be extended to contain Session-Ids?

Yes.  As an optional XML element update to them, which only gets used for matching if the call-id element did not match.

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Dec 2008 15:48:41 -0500

OK, at least the answers are the ones I was expecting to get.

You mentioned something like "dialog-set". I'm not certain yet if "set" 
is the proper term here. But assume for the moment that it is.

Then what you really have is a "dialog-set-id" right? Not a session-id.

It would be good to have a formal definition of a dialog-set. That would 
help with sorting out when individual dialogs get the same 
dialog-set-id. It might also go a long way toward providing a basis for 
defining an SBC and what it can/can't do. (I suspect that an SBC creates 
dialog-sets, and other B2BUAs do not.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 3 Dec 2008 23:43:50 -0500

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Wednesday, December 03, 2008 3:49 PM
>

I think very few people on this planet know what a SIP "dialog" is. :)
But the word "Session" is a more common word for operators (even though its definition in SIP is far more ambiguous, IMO).

For example, I think in your first 3PCC example (up top) most people really do expect that the same Session-ID be used for A-to-C.  Whether it should be the same for B-D is what (IMO) is fine but not necessary, but that's just my opinion; and I bet plenty of operators would consider that the same "Session" too and be surprised if it wasn't.

> (I suspect that an SBC creates

I don't think so.  For example, I would argue that half the SIP functional roles defined in 3GPP create dialog-sets in actual deployment.  Or for example, what a find-me app server does, which hunts for a user at multiple targets; or even what a typical IP-PBX does; or what the market-leading "feature servers" seem to do.

Basically, my assertion is that if you receive a SIP request from A as a UAS, and route or fork it to one or more targets (B/C/D) as a UAC, you have created a single dialog-set.  Let's assume it establishes with B.  IF you receive an in-dialog or dialog-referential request from A or B, and act upon that request as the UA without forwarding it back to A or B and the action creates another dialog, (e.g., you create a new INVITE), then I'd argue you're probably creating a new dialog-set; because that's what should have been created had it actually gone back to A or B and they'd created a new dialog.  But really I'd defer to other people's opinions on that.

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 04 Dec 2008 22:06:03 -0500

> I think very few people on this planet know what a SIP "dialog" is. :)

It's one of the few unambiguously defined things in SIP...

> But the word "Session" is a more common word for operators (even
> though its definition in SIP is far more ambiguous, IMO).
> 
> For example, I think in your first 3PCC example (up top) most people
> really do expect that the same Session-ID be used for A-to-C.  Whether
> it should be the same for B-D is what (IMO) is fine but not necessary,
> but that's just my opinion; and I bet plenty of operators would
> consider that the same "Session" too and be surprised if it wasn't.

"the same Session-ID to be used for A-to-C" ... as is used for *what*?
Do you mean, "the same session-id to be used for the A-to-B and B-to-C
dialogs of the A-to-C session"?

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Thu, 04 Dec 2008 21:59:20 -0500

On Wed, 2008-12-03 at 15:07 -0500, Hadriel Kaplan wrote:
> Yes, under the current model it would.  It's not a necessary scenario
> to have the same Session-ID, IMO, but it's covered that way. (but
> clearly the remote-tag would not match if D sent a Subscribe to A)

The impression I was left with from the draft was that a session-id
would be shared *only* by dialogs that "would be one dialog if the
B2BUAs were proxies".  That is, by dialogs that are logically all one
dialog, in terms of the media that are carried.

Now you're saying that a group of dialogs that are related in other ways
can also share a session-id.  I don't see any reference to that usage in
the draft's requirements (section 1.1) or use cases (section 1.2).

I think you need to clarify this or the discussion will be endlessly
confused.

Dale