Subject: Re: [Insipid] What session is the session ID for?

From: Christer Holmberg <[email-masked]>
Date: Mon, 8 Oct 2012 09:09:35 +0200

Hi,

When I read Paul K's e-mail, I start to think that this may once again turn out in a never ending editorial exercise, which at the end brings very little good.

In the beginning, the idea of session-id was very simply: an identifier between two endpoints, which B2BUAs are less likely to modify than the Call-Id etc. Period.

Then people start talking about transfer, later about 2-part values etc.

Now, as far as transfer is concerned, I believe we already have a mechanism to correlate transferred sessions: History-Info. Simply add the value of the original session as an embedded header field in History-Info, and you're done.

No need to be able to do the correlation based on the value itself, and probably no need for a 2-part value.

Simple :)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 8. lokakuuta 2012 2:53
To: [email-masked]
Subject: [Insipid] What session is the session ID for?

On the call the other day somebody (Keith?) was commenting that some use case was out of scope because the association between the "legs" was at the "application level".

I would like to assert that any time we are talking about an entity that involves multiple dialogs connected by a B2BUA then we are talking about a construct that has been established at a level above SIP - what we call the "application level"

For instance this is so when we have a PBX B2BUA that creates two call "legs" and associates them into one call. And it also happens when an SBC associates an incoming dialog with an outgoing dialog.

What we *ought* to do is actually create a framework/architecture for such constructs built from multiple SIP dialogs, with proper terminology, definitions, etc. Then we would have a basis for defining things like this "session id".

STRAW is also working in this space, and is a little closer to making such definitions, though it is still pretty fluffy.

Such an activity is perhaps outside the current scope and aspirations of either INSIPID or STRAW. The question is whether those WGs can be successful without such work.

	Thanks,
	Paul
_______________________________________________
insipid mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/insipid

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 8 Oct 2012 06:19:07 -0400

Christer,

>From the day we introduced our proposal, we've not added to the complexity
at all.  The two-part values are a very simple solution to the problem of
identifying calls end-to-end through SIP and H.323 networks, through
transfer scenarios, and call "joins" on a PBX.  We can word-smith the
requirements forever if we want, but I don't changes what we need to do.

History-Info does not work since one end may not even know the call changed.
As Hadriel mentioned, the SBC will often block a REFER.  A call might be
placed from A to B and B just happens to be 4 different endpoints due to
forking.  In our proposal, that would mean there are for Session-IDs (A||B1,
A||B2, etc.).

I'm still quite convinced that we need a solution like what we proposed,
since everything else I've ever seen proposed fails in one way or another.
I don't think the problem of identifying sessions end-to-end reliably is
that challenging, though there are obviously some trade-offs with any
solution.

Paul

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Christer Holmberg
> Sent: Monday, October 08, 2012 3:10 AM
> To: Paul Kyzivat; [email-masked]
> Subject: Re: [Insipid] What session is the session ID for?
> 
> Hi,
> 
> When I read Paul K's e-mail, I start to think that this may once again
> turn out in a never ending editorial exercise, which at the end brings
> very little good.
> 
> In the beginning, the idea of session-id was very simply: an identifier
> between two endpoints, which B2BUAs are less likely to modify than the
> Call-Id etc. Period.
> 
> Now, as far as transfer is concerned, I believe we already have a
> mechanism to correlate transferred sessions: History-Info. Simply add
> the value of the original session as an embedded header field in
> History-Info, and you're done.
> 
> On the call the other day somebody (Keith?) was commenting that some use
> case was out of scope because the association between the "legs" was at
> the "application level".
> 
> I would like to assert that any time we are talking about an entity that
> involves multiple dialogs connected by a B2BUA then we are talking about
> a construct that has been established at a level above SIP - what we
> call the "application level"
> 
> For instance this is so when we have a PBX B2BUA that creates two call
> "legs" and associates them into one call. And it also happens when an
> SBC associates an incoming dialog with an outgoing dialog.
> 
> What we *ought* to do is actually create a framework/architecture for
> such constructs built from multiple SIP dialogs, with proper terminology,
> definitions, etc. Then we would have a basis for defining things like
> this "session id".
> 
> STRAW is also working in this space, and is a little closer to making
> such definitions, though it is still pretty fluffy.
> 
> Such an activity is perhaps outside the current scope and aspirations of
> either INSIPID or STRAW. The question is whether those WGs can be
> successful without such work.
> 
> 	Thanks,
> 	Paul