Subject: [dispatch] New version: draft-kaplan-dispatch-session-id-01

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Apr 2010 14:42:34 -0400

Howdy,
Based on discussions at IETF-76, I have submitted an updated draft-kaplan-dispatch-session-id-01.

Pursuant to the changed rules for SIP header field registration in RFC 5727, I have changed the draft to be Informational and I'm fine with going the Individual submission path instead of a WG, if there is no interest for this to be DISPATCHed elsewhere.  I believe this document complies with the intent of RFC 5727.

Comments/concerns/flames are appreciated.
 
The main changes since last version:
- changed it to be Informational, and put in text for rfc5727.
- removed the specific hash algorithm for the generated value, to make it easier for folks to just use a random number/algorithm
- changed it to be 16-chars of hex ascii (0-9a-f), so a 64-bit binary number can be generated/recorded/used
- relaxed the requirements on B2BUA's so that the generation of it is optional, but pass-through/copy is still mandatory

> -----Original Message-----
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : A Session Identifier for the Session Initiation Protocol (SIP)
	Author(s)       : H. Kaplan
	Filename        : draft-kaplan-dispatch-session-id-01.txt
	Pages           : 11
	Date            : 2010-04-17

There is a need for having a globally unique session identifier for the same SIP session, which can be consistently maintained across Proxies, B2BUAs and other SIP middle-boxes, for the purpose of Troubleshooting.  This draft proposes a new SIP header to carry such a value: Session-ID.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-kaplan-dispatch-session-id-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Laura Liess <[email-masked]>
Date: Tue, 20 Apr 2010 14:27:00 +0200

Hadriel,

I don't think that there is no interest for the draft to be
DISPATCHed. We had a lot of discussion on it in the past. It's just
that people are busy and the current DISPATCH process requires a lot
of overhead (charter, chairs...). In principle, I am OK with any way
to get the Session-ID to RFC. Proposed Standard or Informational.  As
far as I know , other SDOs and also other carriers, not only DT,
already use/refer the Session-ID.

Comment to the draft:
- I am OK with allowing other algorithms than Call-ID hash. However,
the description of the hash algorithm in the 00 version was very
usefull and avoided problems with different algorithms being used by
the B2BUA and monitoring systems. I don't see any reason for not
including it as an implementation example.

- Chapter 3. Overview, 3-rd paragraph: "Instead this new header field
provides an identifier for troubleshooting uses only."
 Implementations and other SDOs (I know of 3GPP) already use
Session-ID for SIP-services as Conferencing, to correlate both legs of
a dialog across a B2BUA. There is no other SIP-identifier they can use
for this. So my proposal is to allow this in the Session-ID draft.
Otherwise we either have inconcistency between IETF and IMS documents.

Kind regards
Laura

2010/4/17 Hadriel Kaplan <[email-masked]>:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 20 Apr 2010 09:08:57 -0400

Hi Hadriel,

I am interested in the draft.

One thing that confused me (and maybe I'm just easily confused) was
the term 'out-of-dialog INVITE' in the Example (Section 7). I'm
inferring this is an INVITE which starts a dialog (i.e. has no To:
tag). I would have referred to this as a dialog-creating INVITE. Is
'out-of-dialog INVITE' a standard term? (I tend to to thing of methods
like MESSAGE when I read "out-of-dialog")

Peter Musgrave

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Apr 2010 00:44:39 -0400

Hi Peter, 
Yeah I should probably change that term to dialog-creating, and will do so for the next rev. (I see and use the term "out-of-dialog request" all the time to refer to any request that's not in a dialog, including dialog-creating INVITE and SUBSCRIBE, but if it confuses people it's easy to change :)

-hadriel

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2010 9:09 AM
> To: Laura Liess
> 
> Hi Hadriel,
> 
> >> Pursuant to the changed rules for SIP header field registration in RFC
> 5727, I have changed the draft to be Informational and I'm fine with going
> the Individual submission path instead of a WG, if there is no interest
> for this to be DISPATCHed elsewhere.  I believe this document complies
> with the intent of RFC 5727.
> >>
> >> - removed the specific hash algorithm for the generated value, to make
> it easier for folks to just use a random number/algorithm
> >> - relaxed the requirements on B2BUA's so that the generation of it is
> optional, but pass-through/copy is still mandatory
> >>
> >> There is a need for having a globally unique session identifier for the
> same SIP session, which can be consistently maintained across Proxies,
> B2BUAs and other SIP middle-boxes, for the purpose of
> Troubleshooting.  This draft proposes a new SIP header to carry such a
> value: Session-ID.
> >>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 21 Apr 2010 10:52:25 +0200

I don't have a problem with "out-of-dialog" request (meaning any request that is not mid-dialog). The term "dialog-creating" doesn't work if you want to include things that don't create dialogs, e.g., PUBLISH, MESSAGE. In this particular draft, if we are only referring to INVITE, I guess it doesn't matter.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: 21 April 2010 05:45
> To: Peter Musgrave; Laura Liess
> Cc: [email-masked]; Martin Hülsemann; Roland Jesske
> Subject: Re: [dispatch] New version: 
> draft-kaplan-dispatch-session-id-01
> 
> 
> Hi Peter, 
> Yeah I should probably change that term to dialog-creating, 
> and will do so for the next rev. (I see and use the term 
> "out-of-dialog request" all the time to refer to any request 
> that's not in a dialog, including dialog-creating INVITE and 
> SUBSCRIBE, but if it confuses people it's easy to change :)
> 
> -hadriel
> 
> 
> > >> Based on discussions at IETF-76, I have submitted an 
> updated draft-
> > kaplan-dispatch-session-id-01.
> > >>
> > >> - changed it to be 16-chars of hex ascii (0-9a-f), so a 
> 64-bit binary
> > number can be generated/recorded/used
> > >> A New Internet-Draft is available from the on-line 
> Internet-Drafts
> > directories.
> > >>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 21 Apr 2010 09:20:11 -0400

> From: Elwell, John [mailto:[email-masked]]
> Sent: Wednesday, April 21, 2010 4:52 AM
> 
> I don't have a problem with "out-of-dialog" request (meaning any request
> that is not mid-dialog). The term "dialog-creating" doesn't work if you
> want to include things that don't create dialogs, e.g., PUBLISH, MESSAGE.
> In this particular draft, if we are only referring to INVITE, I guess it
> doesn't matter.

It applies to any message, but Peter was talking about the Example section where I showed an "out-of-dialog INVITE". 

-hadriel

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Apr 2010 10:49:16 -0500

At 03:52 AM 4/21/2010, Elwell, John wrote:
>I don't have a problem with "out-of-dialog" 
>request (meaning any request that is not 
>mid-dialog). The term "dialog-creating" doesn't 
>work if you want to include things that don't 
>create dialogs, e.g., PUBLISH, MESSAGE. In this 
>particular draft, if we are only referring to 
>INVITE, I guess it doesn't matter.

"dialog-creating" INVITE is MUCH preferred over 
"out-of-dialog" INVITE, as some will not easily 
understand the latter - and be easily confused 
when this appears.  It's just not that intuitive (at least to me as well).

Someone reading "dialog-creating" INVITE could 
say to themselves "duh, it's an INVITE always creating a dialog?"

redundancy is better than something less clear

James

---

From: Hans Erik van Elburg <[email-masked]>
Date: Wed, 21 Apr 2010 18:53:17 +0200

Since the dark days that RFC3261 seen the light a
dialog-creating-INVITE or out-of-dialog INVITE is called an "initial
INVITE" and an in-dialog INVITE is called a re-INVITE. I prefer those
ancient well understood terms over the new ones used in this
conversation.

Initial INVITEs create dialogs, that is what they do, re-INVITEs don't.

Initial INVITEs belong to the class of "initial requests for a dialog"
and hence also to "initial requests", re-INVITEs to the class of
"in-dialog requests" or "subsequent requests".

The term out-of-dialog request seems problematic as it assumes the
existence of a dialog where one might not exist.

/Hans Erik van Elburg

On Wed, Apr 21, 2010 at 5:49 PM, James M. Polk <[email-masked]> wrote:
>> that is not mid-dialog). The term "dialog-creating" doesn't work if you want
>> to include things that don't create dialogs, e.g., PUBLISH, MESSAGE. In this
>> particular draft, if we are only referring to INVITE, I guess it doesn't
>> matter.
>
> "dialog-creating" INVITE is MUCH preferred over "out-of-dialog" INVITE, as
> some will not easily understand the latter - and be easily confused when
> this appears.  It's just not that intuitive (at least to me as well).
>
> Someone reading "dialog-creating" INVITE could say to themselves "duh, it's
> an INVITE always creating a dialog?"
>

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 21 Apr 2010 16:10:41 -0500

>Initial INVITEs create dialogs, that is what they do, re-INVITEs don't.

these "old terms" work too  ;-)

I was just evaluating Hadriel's two new terms...

James

> >> that is not mid-dialog). The term 
> "dialog-creating" doesn't work if you want

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Apr 2010 11:54:55 -0400

Hi Laura,
Comments inline...

> From: Laura Liess [mailto:[email-masked]]
> Sent: Tuesday, April 20, 2010 8:27 AM
> To: Hadriel Kaplan
> 
> of overhead (charter, chairs...). 

Sorry I should have been clearer - I didn't mean no interest in it, I meant no interest in DISPATCHing it to an existing WG. (and I definitely do NOT think it warrants a new WG :)

> including it as an implementation example.

The concept of specifying the algorithm was only to guarantee the value wouldn't reveal which vendor had created it.  But it wouldn't have made it possible for a monitoring system to determine the session-id value for messages which don't already have a session-id, because the hash used a private key unique to every system.  In other words, two different systems would generate two different Session-IDs for the same Call-ID.  That was by design.

So since it was only to avoid revealing the vendor, I got comments back that a random number would be good enough for that, and reduce the work/performance-hit of doing a strong hash.

> Otherwise we either have inconcistency between IETF and IMS documents.

Is there a doc I can go look at which describes how they're going to use it?

-hadriel

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 26 Apr 2010 11:50:05 +0200

Hi,

I also think this draft has many more uses than just troubleshooting I know for example it has been discussed as being potentially useful to the SIPREC work.

For this reason I would like to see the draft published as Standards Track.

Regards
Andy

> Sent: 23 April 2010 16:55
> To: Laura Liess
> Sorry I should have been clearer - I didn't mean no interest 
> in it, I meant no interest in DISPATCHing it to an existing 
> WG. (and I definitely do NOT think it warrants a new WG :)
> 
> 
> > Comment to the draft:
> The concept of specifying the algorithm was only to guarantee 
> the value wouldn't reveal which vendor had created it.  But 
> it wouldn't have made it possible for a monitoring system to 
> determine the session-id value for messages which don't 
> already have a session-id, because the hash used a private 
> key unique to every system.  In other words, two different 
> systems would generate two different Session-IDs for the same 
> Call-ID.  That was by design.
> 
> So since it was only to avoid revealing the vendor, I got 
> comments back that a random number would be good enough for 
> that, and reduce the work/performance-hit of doing a strong hash.
>  
>

---

From: Peter Musgrave <[email-masked]>
Date: Mon, 26 Apr 2010 06:19:30 -0400

Hi,

I too would like to see this standards track.

I already have plans to use it for some internal call logging (and I
can see it's value to siprec also).

Regards,

Peter

---

From: Laura Liess <[email-masked]>
Date: Mon, 26 Apr 2010 15:57:04 +0200

Hi Hadriel,

Comments inline...

> So since it was only to avoid revealing the vendor, I got comments back that a random number would be good enough for that,
> and reduce the work/performance-hit of doing a strong hash.
>

For us it is important only not to reveal the IP-address in the
original Call-ID. We also intend the messsage correlation software to
know the key. The external  monitoring system stores all the in- and
outgoing SIP-messages for a B2BUA. For every incomming, out-of-dialog
message, the message correlation software looks for the Session-ID. If
it finds one, it identifies all other messages, in and out, and the
correlation is done.   If there is no Session-ID in the message, it
takes the Call-ID, hashes it with the key of the B2BUA and searches
for an outgoing message with this Session-ID.

> Is there a doc I can go look at which describes how they're going to use it?

3GPP TS 24.605 shows how it is used for Conferencing.  See
http://www.3gpp.org/ftp/Specs/html-info/24605.htm  Here is the message
flow.
In TS 24.229 the Session-ID usage was extended to dialog correlation
in general.
http://www.3gpp.org/ftp/Specs/html-info/24229.htm
Please make sure you download the last versions, at the bottom of the
tables, for both specifications.

They decided to use Session-ID because there is no other mechanism for
dialog correlation. Such mechanism is needed both for troubleshooting
and dialog correlation.

My opinion is that we should try to get a WG to solve both problems.

Laura

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 11:55:08 -0400

> Sent: Monday, April 26, 2010 9:57 AM
> 

As currently defined the B2BUA would insert the same Session-ID in the responses it generates back upstream to the UAC - is that not enough for a monitoring system to correlate both sides?   I don't know the answer; hopefully some monitoring vendors will chime in.  I told several of them about this draft but I don't know if they had anyone join dispatch.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Tue, 27 Apr 2010 12:45:49 -0500

> - changed it to be 16-chars of hex ascii (0-9a-f), so a 64-bit binary number can be generated/recorded/used

If this is only for troubleshooting, that's probably Good Enough [tm]. 
But I've seen a few messages clamoring for this to be useful for 
non-debugging purposes. If these identifiers are used for correlation 
after the fact -- especially for something with real-world ramifications 
like billing, legal intercept, criminal forensics or the like -- I think 
64 bits is a bit paltry.

Keep in mind that SIP is being deployed in carrier grade systems, with 
high rates of throughput.

For estimation purposes, let's consider AT&T's voice network. As of 
1999, it carried about 300 millon calls per day [1].  Let's imagine some 
day in the future in which these are all traveling over SIP, but the 
traffic load has mysteriously not increased. So we're being somewhat 
optimistic about SIP's adoption, but very pessimistic about calling 
patterns.

This is a classic example of the Birthday Paradox [2]. Using a 64-bit 
integer as the number of bins:

- If you were to analyze one day's traffic, you'd have about a 0.2% 
chance of a collision.

- Analyzing one week of traffic (seven days), that chance goes up to 11.2%.

- And, over the course of a month (30 days) -- where there might be 
billing implications --  it skyrockets to 88.9%.

Now, if you doubled length of the identifier -- to 128 bits -- you'd 
have to process 26 quadrillion (26 * 10^15) calls before your chance of 
collision rose as high as .0001%. That's about 238,000 years worth of calls.

And *that* should be good enough for non-debugging purposes. So I'd 
propose we use 32 hex chars instead of 16.

/a

[1] 
http://www2.research.att.com/areas/visualization/papers_videos/abstract.php?id=CG-AbelloGKN99
[2] 
http://en.wikipedia.org/wiki/Birthday_problem#Cast_as_a_collision_problem

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 27 Apr 2010 14:16:22 -0400

> propose we use 32 hex chars instead of 16.

If we care about message size, maybe radix64 (22 chars instead of 32)?

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 27 Apr 2010 14:44:36 -0400

Good point.  I'll change it back to 128 bits.
-hadriel

> From: Adam Roach [mailto:[email-masked]]
> Sent: Tuesday, April 27, 2010 1:46 PM
> To: Hadriel Kaplan
> Cc: [email-masked]
> Subject: Re: [dispatch] New version: draft-kaplan-dispatch-session-id-01
>

---

From: Laura Liess <[email-masked]>
Date: Wed, 28 Apr 2010 16:40:25 +0200

> As currently defined the B2BUA would insert the same Session-ID in the responses it generates back upstream to the UAC - is that not enough for a monitoring system to correlate both sides?   I don'…

What if the answer is missing? How can you tell then if the B2BUA did
not sent the INVITE or if the UAS did not answer or if the B2BUA
discarded the response instead of sending it to the UAC?  Or did I
miss something?

Laura