Subject: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt

From: "Paul E. Jones" <[email-masked]>
Date: Sun, 28 Nov 2010 17:23:23 -0500

Folks,

I want to bring to your attention this new draft some colleagues and I put
together to try to address the need for a "session identifier" that allows
for end-to-end session identification.  We also see utility that goes beyond
just identifying the session end-to-end, as outlined in the document.  We
believe this approach will satisfy those needs and do so in a very simple,
straight-forward way.  Equally important, this approach will work with SIP,
H.323, and other session signaling protocols.

We welcome any feedback you'd like to provide.

Thanks!
Paul

> -----Original Message-----
> From: [email-masked] [mailto:i-d-announce-
> [email-masked]] On Behalf Of [email-masked]
> Sent: Sunday, November 28, 2010 5:15 PM
> To: [email-masked]
> Subject: I-D Action:draft-jones-ipmc-session-id-00.txt
> 
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> 
> 	Title           : End-to-End Session Identification in IP-Based
> Multimedia Communication Networks
> 	Author(s)       : P. Jones, et al.
> 	Filename        : draft-jones-ipmc-session-id-00.txt
> 	Pages           : 8
> 	Date            : 2010-11-28
> 
> This document describes an end-to-end Session Identifier for use in IP-
> based Multimedia Communication systems that enables endpoints,
> intermediate devices, and management systems to identify a session end-
> to-end, associate multiple endpoints with a given multipoint conference,
> track communication sessions when they are redirected, and associate one
> or more media flows with a given communication session.
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-jones-ipmc-session-id-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 29 Nov 2010 07:39:27 +0100

Hi,

Other than the syntax, what is the difference between this and Hadriel's session-id draft (draft-kaplan-dispatch-session-id)?

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul E. Jones [[email-masked]]
Sent: Monday, November 29, 2010 12:23 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt

Folks,

Thanks!
Paul

> implementation to automatically retrieve the ASCII version of the

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Nov 2010 07:28:18 -0500

Christer,

Most significantly, the Session-ID is not constructed by one endpoint and
passed to the other.  Rather, the Session-ID is formed through the
concatenation of UUIDs provided by both parties.  At any time during the
call, an intermediary can redirect the call (which often happens) and a new
session ID is constructed when the transferred party sees that the
session-uuid from the remote end has changed.  I believe with Hadriel's,
there is a question lingering as to who assigns the session ID when there
are session transfers, joins, etc.  In our draft, there will always be a
unique session ID constructed from UUID components from each device.

By constructing the Session-ID from two UUIDs, we can also determine which
of several devices are participating in the same multipoint conference.  If
A, B, C, and D are all connected to and MCU, M, then all of those devices
would receive the same UUID value from M and would form a part of the
Session-ID used by each device.

The goal of Hadriel's draft and ours are the same.  We even considered using
the same header name, but ultimately decided to place the UUID in the
Contact header.  We have not particular attachment to use of UUIDs (versus
any other unique value like a hash).  What we think is important is
addressing the issues of who assigns the Session ID and how it evolves when
the session is transferred, joined, etc. and how we can associate devices
participating in multipoint conferences.

Paul

> From: Christer Holmberg [mailto:[email-masked]]
> Sent: Monday, November 29, 2010 1:39 AM
> To: Paul E. Jones; [email-masked]
> Cc: [email-masked]
> Subject: RE: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-
> 00.txt
> 
> Hi,
> 
> Other than the syntax, what is the difference between this and Hadriel's
> session-id draft (draft-kaplan-dispatch-session-id)?
> 
> Regards,
> 
> Christer
> 
> I want to bring to your attention this new draft some colleagues and I
> put together to try to address the need for a "session identifier" that
> allows for end-to-end session identification.  We also see utility that
> goes beyond just identifying the session end-to-end, as outlined in the
> document.  We believe this approach will satisfy those needs and do so
> in a very simple, straight-forward way.  Equally important, this
> approach will work with SIP, H.323, and other session signaling
> protocols.
> 
> > This document describes an end-to-end Session Identifier for use in
> > IP- based Multimedia Communication systems that enables endpoints,
> > intermediate devices, and management systems to identify a session
> > end- to-end, associate multiple endpoints with a given multipoint
> > conference, track communication sessions when they are redirected, and
> > associate one or more media flows with a given communication session.
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Nov 2010 08:14:49 -0500

On Nov 29, 2010, at 7:28 AM, Paul E. Jones wrote:

> The goal of Hadriel's draft and ours are the same.  

It is?  I got the impression it was for correlation for purposes other than troubleshooting.  Right now, the session-id draft's goal is purely troubleshooting; and to do so for any SIP request type.

-hadriel

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 29 Nov 2010 08:25:59 -0500

Hi Paul et. al., 

I agree that session correlation end-to-end is highly desirable in some applications and this approach of endpoint exchange of UUID seems ok (although I have not thought about all the weird corner cases SIP forking might induce).

IMHO the existence of genuine B2BUA's dooms any attempt to correlate sessions. If they fundamentally act as two UAs then no correlation will happen. 

IF we could have language that a B2BUA MUST do something (and implementors actually listened) then this approach would work. The approach here does seem kinda cool - since it could traverse protocols - but I still think the core issue is that a genuine B2B seems to be something the real world wants...and they don't seem over-keen to correlate sessions. 

Does this group think that we can mandate that a B2BUA or SBC MUST do something (and that it would be implemented)?

Peter Musgrave

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Nov 2010 07:41:20 -0600

And my impression was that Hadrian wanted to keep session-id for 
troubleshooting alone, to minimize the incentive of middleboxes to drop the 
header field or otherwise dork with it...

> It is?  I got the impression it was for correlation for purposes other 
> than troubleshooting.  Right now, the session-id draft's goal is purely 
> troubleshooting; and to do so for any SIP request type.
>
> -hadriel

One thing that's not clear to me - in discussions about correlation, I've 
talked to some folk who want really crisp definitions of when things are 
correlated (and would have the same session-id), and when they would not - 
does forking count? does call forwarding count? does call transfer count? 
does conferencing count?

My impression from talking to Hadriel is that his view was more "because I 
said so" - "if I do something and reuse the session-id, I did that for a 
reason". I am wondering if "because I said so" is a better strategy for 
troubleshooting, and more precise definitions would be a better strategy for 
other uses - if that makes sense, two header fields would make sense to me.

Thanks,

Spencer

---

From: Roni Even <[email-masked]>
Date: Mon, 29 Nov 2010 16:01:21 +0200

Hi Paul,
I thought that for the MCU case there is the conference event package that
will provide this information
Roni Even

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul E. Jones
> Sent: Monday, November 29, 2010 2:28 PM
> To: 'Christer Holmberg'; [email-masked]
> Cc: [email-masked]
> Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-
> 00.txt
> 
> Christer,
> 
> > From: [email-masked] [[email-masked]] On Behalf
> Of
> > Paul E. Jones [[email-masked]]

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 29 Nov 2010 09:12:02 -0500

On 11/29/2010 8:41 AM, Spencer Dawkins wrote:
> troubleshooting alone, to minimize the incentive of middleboxes to drop
> the header field or otherwise dork with it...

I find this very distressing:

Our typical approach is to provide general mechanisms that can be used 
in a variety of ways. And IMO that is the preferred approach.

But now we find arguments that we should make very narrowly focused 
mechanisms because anything general purpose will be viewed as a threat. 
Pursuing that approach will lead to either:
- complexity and inefficiency as we define separate but equal mechanisms
   for each potential use
- lack of function because the effort to define another similar
   mechanism for another purpose is just not worth the effort
- lack of interop due to introduction of proprietary mechanisms.

Its not session-id that is the problem here - it is just a symptom of 
the problem. The problem is middle boxes and the damage they do, or just 
threaten to do.

At Mastricht we had an informal meeting to discuss the possibility of 
doing something similar to Behave for SBCs, but it went nowhere - there 
was no consensus that anything meaningful could be done. But I think we 
will continue to have problems like this one with session-id until we 
find a way to confront this. ISTM we really need a "declaration of SIP 
rights" that spells out the things that a well defined middle box will 
not mess with. And it needs to be defined not as an enumeration of 
already defined things, but rather as an algorithm that may be applied 
to yet-to-be-defined things as well.

I'm curious if others feel this way, or am I just a lone raging lunatic?

	Thanks,
	Paul

> One thing that's not clear to me - in discussions about correlation,
> I've talked to some folk who want really crisp definitions of when
> things are correlated (and would have the same session-id), and when
> they would not - does forking count? does call forwarding count? does
> call transfer count? does conferencing count?
>
> My impression from talking to Hadriel is that his view was more "because
> I said so" - "if I do something and reuse the session-id, I did that for
> a reason". I am wondering if "because I said so" is a better strategy
> for troubleshooting, and more precise definitions would be a better
> strategy for other uses - if that makes sense, two header fields would
> make sense to me.
>
> Thanks,
>
> Spencer

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Nov 2010 09:12:36 -0500

Hi Paul,

With regard to using the two-sided approach in order to handle conference call cases, this was discussed way back for the session-id draft as well... but the issue was that many/most conference servers don't actually know that multiple calls are part of the same conference until the user presses a conference code in DTMF, which is after the call is answered.  Do you expect the conference server to issue a re-INVITE in such cases, to transmit a new UUID for its side?

With regards to specifics about the proposed mechanism:
1) Putting it in the Contact header means it won't work for MESSAGE requests, since they have no Contact; and it would be weird in a REGISTER which can have multiple Contacts.  At the end of the day, this ID isn't really a property of the Contact.
2) Putting it in the Contact header means it will be very difficult to get SBCs/B2BUAs to "leave it alone" without having to change their internal software, arguably more so than if it were in a separate header.
3) Using a UUID is not "safe", in the sense that it reveals a MAC address and therefore the vendor/manufacturer of the UA, so an SBC would be motivated to remove/replace this. (I know it's a minor concern, but some people do worry about this) 

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Nov 2010 09:14:44 -0500

Oh cool, even Roman emperors want something like this. ;)

-hadriel

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 29 Nov 2010 16:30:24 +0200

Hi Paul,

I find the approach of endpoints exchange of a unique value to form the 
session-id
quite interesting.

your description of how to use it in a multipoint conference  (section 6)
actually can be easily adapted also for disaggregated media scenario 
described in SPLICES wg
and in draft: 
http://tools.ietf.org/id/draft-loreto-splices-disaggregated-media-00.txt

not completly sure that UUID and using Contact to exchange it are the 
right/safe way to do it.

cheers
/Sal

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 29 Nov 2010 15:50:11 +0100

Some of my comments have already been raised, but a couple have not:

- Using two UUIDs to form a session-id, how do we expect session-ids to be unique? For example, a PSTN gateway would presumably have a single UUID for all its calls. So all calls between the same pair of gateways (or all calls hairpinning back to the same gateway) would have identical session-IDs. Some of these calls may exist in parallel, thereby leading to incorrect determination (if I understand correctly) that the calls are part of the same multi-party conference.

- Another example where two session-ids for parallel calls could share the same UUID is where a user device has one call in progress and then another, unrelated call arrives, which perhaps waits for the user to become free, and then perhaps the user alternates between the two calls. Making the assumption the two calls are part of a multi-party conference would be incorrect.

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul E. Jones
> Sent: 28 November 2010 22:23
> To: [email-masked]
> Cc: [email-masked]

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Nov 2010 10:22:16 -0500

The goal of identifying sessions end-to-end is the same.  How the 
session ID is used might not be a shared goal.  Troubleshooting, 
relating sessions to media flows, identifying sessions that are part of 
the same conference, etc. are things we might do with that session ID.

In any case, I would hope we can come up with a single way to identify 
sessions that can work with a all session protocols and can be generic 
enough to be useful.

Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 29 Nov 2010 09:30:35 -0600

Hi, Paul,

> Our typical approach is to provide general mechanisms that can be used in 
> a variety of ways. And IMO that is the preferred approach.

I am sympathetic to your distress.

Taking a step back for a moment - later in my note, I asked whether the 
definition of a "session" might be different for troubleshooting, than for 
the general case. If we get the answer back that the definition might be 
different, then I think we can table the discussion about general mechanisms 
versus narrowly-focused mechanisms for another time (and I have confidence 
that the issue will pop back up, before the RAI area hits end-of-life).

> Its not session-id that is the problem here - it is just a symptom of the 
> problem. The problem is middle boxes and the damage they do, or just 
> threaten to do.
>
> will continue to have problems like this one with session-id until we find 
> a way to confront this. ISTM we really need a "declaration of SIP rights" 
> that spells out the things that a well defined middle box will not mess 
> with. And it needs to be defined not as an enumeration of already defined 
> things, but rather as an algorithm that may be applied to 
> yet-to-be-defined things as well.
>

I'm not sure why the expectations for NAT-level middlebox BCPs should be 
different from the expectations for SBC-level BCPs, so I think this 
conversation is worth having, independent of the 
two-mechanisms-versus-one-mechanism discussion and the 
general-mechanism-versus-narrowly-focused-mechanism discussion mentioned 
about.

Thanks,

Spencer

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Nov 2010 10:45:38 -0500

John,

Perhaps the draft was not clear on this point.  An endpoint would create 
a unique UUID for each session it initiates or answers.  It would remain 
static through the life of that session.  In this way each session ID 
would be unique.

Pal

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 29 Nov 2010 18:38:32 +0100

Requirements might be quite different, depending on what you want to do.

For trouble-shooting, we seem to need a session-id that ties together different legs of a call that traverses one or more B2BUAs. Call this SID1.

For conferencing, we might want to tie together several calls that are all part of the same multi-party conference. Call this SID2. Each of the calls tied together under SID2 would have different values for SID1.

We might need to tie together two or more calls in a thread, e.g., before and after transfer. Call this SID3. Calls with the same SID3 would have different SID1s. Moreover, if you transferred a call into a conference, the original call and the call that ends up in the conference might have the same SID3, but this would not equate to the SID2 that ties together the different calls in the conference.

By the way, for session recording in SIPREC, I could imagine any of these types of SID might be relevant as part of the metadata.

John

> Sent: 29 November 2010 15:22
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [dispatch] FW: I-D 
> Action:draft-jones-ipmc-session-id-00.txt
> 
> > It is?  I got the impression it was for correlation for 
> purposes other than troubleshooting.  Right now, the 
> session-id draft's goal is purely troubleshooting; and to do 
> so for any SIP request type.
> >
> > -hadriel
> >

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 30 Nov 2010 00:00:02 +0530

John,
 
Please read inline
 
Thanks
Partha

________________________________

From: [email-masked] on behalf of Elwell, John
Sent: Mon 11/29/2010 11:08 PM
To: Paul E. Jones; Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt

<Partha> With Paul UUID, the first portion of UUID serves the purpose of SID2 and the complete UUID serve the purpose of SID1</Partha>

We might need to tie together two or more calls in a thread, e.g., before and after transfer. Call this SID3. Calls with the same SID3 would have different SID1s.

<Partha> First portion of UUID shall be considered as SID3 which is common between before and after transfer. The whole portion is different SID1 </Partha>

 Moreover, if you transferred a call into a conference, the original call and the call that ends up in the conference might have the same SID3, but this would not equate to the SID2 that ties together the different calls in the conference.

By the way, for session recording in SIPREC, I could imagine any of these types of SID might be relevant as part of the metadata.
<Partha> As we discussed in SIPREC, all 3 session-id are applicable and it depends upon on the deployment. draft-jones-ipmc-session-id-00 seems to serve most of SIPREC usecases. </Partha>
John

---

From: "Parthasarathi R (partr)" <[email-masked]>
Date: Tue, 30 Nov 2010 00:25:49 +0530

Paul K, 
 
I agree that it is better to define the middle box behavior. There is no progress in SBC Bar BOF at IETF-78 as we could not rightly spell out the behavior of different SBC. I doubt whether it is possible to converge. I really doubt whether IETF will ever accept B2BUA issues in the single charter. 
 
session-id (unique session identifier) is one of the common behavior which is mainly used/broken by middle boxes (SBC/B2BUA). SPLICE, SIPREC, SIPSCOTCH are the examples where SIP folks are in need of some sort of unique id.  It will be good atleast individual pieces of middle box (B2BUA) behavior are progressed. Something is better than nothing. Please let me know your opinion here.
 
Thanks
Partha

From: [email-masked] on behalf of Paul Kyzivat (pkyzivat)
Sent: Mon 11/29/2010 7:42 PM
To: [email-masked]
Subject: Re: [dispatch] FW: I-D Action:draft-jones-ipmc-session-id-00.txt

        Thanks,
        Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 29 Nov 2010 15:07:19 -0500

On Nov 29, 2010, at 9:12 AM, Paul Kyzivat wrote:

> ... [snip] ...

The thing I find distressing is the continual belief that session-id (or any variant thereof) is tied to the SBC "problem" and crossing them.  Session-id isn't just about SBCs.  It's about PBX's, softswitches, app servers, feature servers, etc.  All kinds of things are B2BUAs and replace the call-id/tags on their UAC side.  If this were just about crossing SBC's, I wouldn't bother publishing something in the IETF.  Frankly, I'd call up three other vendors in the SBC market, and between us that would cover >90% of it.

And if there were a push for a BEHAVE of SBCs, it would have to start off with not believing SBCs somehow restrict your "SIP rights".  This isn't a NAT or Firewall you're silently crossing as a bump in the wire to reach the public Internet.  Your client sent its SIP request to the SBC, which is the UAS.  Your SIP ends there.  It's like telling me a SIP PSTN Gateway restricts your "SIP rights" because it doesn't pass some new SIP header through SS7/ISUP.  Or telling me my SIP phone restricts your rights if my phone doesn't support REFER or Invite-Replaces from you.  You may not get a feature you want, but you have no inalienable "right" to get all features from any/every UAS you send a message to.

> I'm curious if others feel this way, or am I just a lone raging lunatic?

Is that an exclusive "or"?  ;)

-hadriel

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Mon, 29 Nov 2010 16:50:03 -0600

> Does this group think that we can mandate that a B2BUA or SBC MUST do something (and that it would be implemented)?

I don't think this is really possible, no, primarily due to the fact 
that 'B2BUA' covers a wide range of possible constructions, with very 
different behavior. Is a call center ACD that receives incoming calls 
from a SIP ITSP and delivers them to agents that use SIP softphones a 
'B2BUA'? It probably is, but its rules for what will, or could, be 
carried over from one SIP dialog to another are going to be radically 
different from what a PBX would do, or what an SBC would do.

I can imagine such language saying something along the lines of "if the 
UAS is going to initiate another dialog as part of the processing of the 
first dialog, then it MUST/SHOULD ...", but it doesn't seem likely that 
such language could exhaustively define when an outbound dialog is 
sufficiently coupled to an inbound dialog for these requirements to come 
into force.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 29 Nov 2010 18:44:28 -0500

Hadriel,

It's OK if the conference server does not know what UUID to send.    
Once the user enters the conference details, the call might be 
transferred to another device and/or just change state and dropped into 
an existing conference.  Either way, a new INVITE would be sent from the 
conference server to the remote endpoint with the new UUID.  This new 
UUID would then replace the previous value received.  At this point, the 
call could be seen as being part of the same conference.  UUID values 
from either endpoint might change at any time due to transfers or 
replacement of "call legs" that are not necessarily signaled.  Either 
way, the Session ID is updated through the whole process.  Further, 
those who need to know the current Session ID would have that 
information, whether it is the endpoint or intermediaries.

To your points:
1) Would a standalone MESSAGE be a part of a session?  Is this statement 
true for MESSAGE sent as a part of a session? (You've got me on that 
one.)  In any case, we can most certainly send this as a new header like 
you did in your draft.  My first cut at this introduced a new header 
called Session-ID-UUID.  It's a bit long, so I'd prefer Session-UUID.  
But, I definitely have no love for where we place the UUID or even 
whether its a UUID or not.  It could be an SHA-1 hash of random data for 
all I care: just want something that's "guaranteed" to be unique.
2) Interesting.  I'll take your word on that, though I'm not sure why 
one place would be more challenging than another.
3) People say this, though I never understood why.  That said, if one 
wishes to hide the MAC, there are procedures to generate UUIDs using 
random numbers.  I forget off hand what UUID "version" that is, but 
there are ones with random digits.  In any case, we could create a 
version 0 UUID (i.e., has the MAC) and then run that through a hash 
function like SHA-1.

I'm certainly open to most aspects of the text.  Most importantly, I'd 
like to see progress on defining a session ID value we can use 
end-to-end in the spirit of what I've proposed, as I think it meets your 
requirements and those I have.

Paul

---

From: Laura Liess <[email-masked]>
Date: Tue, 30 Nov 2010 16:15:40 +0100

It seems that Hadriel's Session-ID for troubleshooting and the new
UUID based Session-ID are almost complimentary concerning their pros
and cons.
 a) Troubleshooting Session-ID:
        + Works for every kind of SIP-messages
        + External trubleshooting devices are able to correlate
different segments of a call, also when the end device initiating the
call does not support the Session ID.  The first B2BUA in the call
constructs the Session-ID on behalf of the end device, as a hash of
the Call-ID it receives  from the end device.
        + Hides the identity (and IP-address) of the end device
        -  Does not cover all use cases where dialog correlation is needed.

b) UUID based Session-ID
       + Possibly covers all or most use cases where dialog
correlation is needed.
 Works for every kind of SIP-messages
        + External trubleshooting devices are able to correlate
different segments of a call, also when the end device initiating the
call does not support the Session ID.  The first B2BUA in the call
constructs the Session-ID on behalf of the end device, as a hash of
the Call-ID it receives  from the end device.
        + Hides the identity (and IP-address) of the end device

2010/11/30 Paul E. Jones <[email-masked]>:
>  Hadriel,
>
> It's OK if the conference server does not know what UUID to send.    Once
> the user enters the conference details, the call might be transferred to
> another device and/or just change state and dropped into an existing
> conference.  Either way, a new INVITE would be sent from the conference
> server to the remote endpoint with the new UUID.  This new UUID would then
> replace the previous value received.  At this point, the call could be seen
> as being part of the same conference.  UUID values from either endpoint
> might change at any time due to transfers or replacement of "call legs" that
> are not necessarily signaled.  Either way, the Session ID is updated through
> the whole process.  Further, those who need to know the current Session ID
> would have that information, whether it is the endpoint or intermediaries.
>
> To your points:
> true for MESSAGE sent as a part of a session? (You've got me on that one.)
>  In any case, we can most certainly send this as a new header like you did
> in your draft.  My first cut at this introduced a new header called
> Session-ID-UUID.  It's a bit long, so I'd prefer Session-UUID.  But, I
> definitely have no love for where we place the UUID or even whether its a
> UUID or not.  It could be an SHA-1 hash of random data for all I care: just
> want something that's "guaranteed" to be unique.
> 2) Interesting.  I'll take your word on that, though I'm not sure why one
> place would be more challenging than another.
> 3) People say this, though I never understood why.  That said, if one wishes
> to hide the MAC, there are procedures to generate UUIDs using random
> numbers.  I forget off hand what UUID "version" that is, but there are ones
> with random digits.  In any case, we could create a version 0 UUID (i.e.,
> has the MAC) and then run that through a hash function like SHA-1.
>
> I'm certainly open to most aspects of the text.  Most importantly, I'd like
> to see progress on defining a session ID value we can use end-to-end in the
> spirit of what I've proposed, as I think it meets your requirements and
> those I have.
>
> Paul
>
>> With regard to using the two-sided approach in order to handle conference
>> call cases, this was discussed way back for the session-id draft as well...
>> but the issue was that many/most conference servers don't actually know that
>> multiple calls are part of the same conference until the user presses a
>> conference code in DTMF, which is after the call is answered.  Do you expect
>> the conference server to issue a re-INVITE in such cases, to transmit a new
>> UUID for its side?
>>
>> 1) Putting it in the Contact header means it won't work for MESSAGE
>> requests, since they have no Contact; and it would be weird in a REGISTER
>> which can have multiple Contacts.  At the end of the day, this ID isn't
>> really a property of the Contact.
>> 2) Putting it in the Contact header means it will be very difficult to get
>> SBCs/B2BUAs to "leave it alone" without having to change their internal
>> software, arguably more so than if it were in a separate header.
>> 3) Using a UUID is not "safe", in the sense that it reveals a MAC address
>> and therefore the vendor/manufacturer of the UA, so an SBC would be
>> motivated to remove/replace this. (I know it's a minor concern, but some
>> people do worry about this)
>>
>> -hadriel
>>
>>
>>> put

---

From: Laura Liess <[email-masked]>
Date: Tue, 30 Nov 2010 16:38:50 +0100

Sorry for the previous unfinished message. Here is the complete one.

 b) UUID based Session-ID
       + Possibly covers all or most use cases where dialog
 correlation is needed.
       - Does not work for every kind of SIP-messages
       - External trubleshooting devices are not able to correlate
         different segments of a call when the end device initiating the
         call does not support the Session ID.
       - Does not hide  the identity (and IP-address) of the end device

Hadriel's Session-ID is already up and running within many boxes.

Maybe it is possible to find a solution which has the pros of both
proposals and is compatible with the already implemented Session-ID?
Just a thought, I am not sure it works: The first UA or B2BUA
calculates the Session-ID as described in Hadriel's draft. If it
supports the new mechanis, it concatenates the UUID to it and writes
the result into the Session-ID header.  The next UA adds its own UUID
to it if its supports the new mechanism ans so on. I think the
correlation for troubleshooting would work, and the correlation for
conferencing would work if the conference initiator supports the new
mechanism.  the Session-ID may be different for different messages of
the same call segment, but there we have the call-ID.

Thanks a lot
Laura

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 30 Nov 2010 12:08:59 -0500

Laura,

I think it's good to overcome the weaknesses of both proposals.  
However, what we could not understand is how Hadriel's draft would 
accommodate things such as joining two sessions together as a B2BUA.  
This happens with enterprise PBXes, for example.  If A and B both have 
sessions established with C, then C joins those together in some way so 
that there is now a single session between A and B, what is the session 
ID?  The approach we suggest would accommodate that.

Our proposal does hide the user's identity if random numbers are used 
for the UUIDs, which is a valid option when generating UUIDs.  We could 
also hash the values.

Carrying the UUIDs inside a new header (e.g., Session-UUID) is also 
possible and, as I mentioned separately, was the way the first 
(pre-published) draft had it.

The approach we propose will also work with H.323, which is something I 
intend to introduce there, too.

What is not clear is how our proposal comes up short for the 
troubleshooting case.  I can see a situation where A (a device 
supporting Session-UUID) might call B (without this support) and then 
there's no way to get the complete Session ID for troubleshooting.  I 
don't see a solution for that case with our approach.

I am not opposed to having two values going across the wire, though I 
would prefer to avoid that.  It gets really ugly when we have so may 
different kinds of identifiers flowing across the network.  It would be 
really good to have one solution that meets everyone's needs.

What we want is to have a session ID that allows for calls to be 
transffered/joined/merged/etc. and to be able to still have an 
end-to-end ID all devices agree upon as call legs are moved around.  
We'd also like to be able to use that ID to relate media flows with 
signaling flows (e.g., allow RTCP packets to contain the composed 
Session ID).  We would appreciate the ability to relate calls to a 
conference by taking note of shared UUID values.  We'd also appreciate 
the ability to take note of changes related to sessions (e.g., call 
joins) as UUID components change.

Paul

On 11/30/2010 10:38 AM, Laura Liess wrote:
>> 2010/11/30 Paul E. Jones<[email-masked]>:
>>>   Hadriel,
>>>

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 30 Nov 2010 12:12:06 -0500

You're entirely right.  The primary challenge we have with tracking 
calls and associating media flows is the fact that the PBX manipulates 
calls in lots of interesting ways.

Paul

On 11/29/2010 3:07 PM, Hadriel Kaplan wrote:
> The thing I find distressing is the continual belief that session-id (or any variant thereof) is tied to the SBC "problem" and crossing them.  Session-id isn't just about SBCs.  It's about PBX's, softswitches, app servers, feature servers, etc.  All kinds of things are B2BUAs and replace the call-id/tags on their UAC side.  If this were just about crossing SBC's, I wouldn't bother publishing something in the IETF.  Frankly, I'd call up three other vendors in the SBC market, and between us that would cover>90% of it.
>