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

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 22 Dec 2009 10:42:06 -0500

Howdy,
I've re-submitted a draft I originally submitted to the SIP WG back when it was in existence.  The draft defines a session correlation identifier for troubleshooting purposes.  

I'd like to have this dispatched to the appropriate WG, preferably the SIP-CLF WG (since they're a prime customer of it).

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of [email-masked]
> Sent: Tuesday, December 22, 2009 10:30 AM
> To: [email-masked]
> Subject: I-D Action:draft-kaplan-dispatch-session-id-00.txt
> 
> 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-00.txt
> 	Pages           : 11
> 	Date            : 2009-12-22
> 
> There are several reasons for having a globally unique session
> identifier for the same SIP session, which can be maintained across
> B2BUAs and other SIP middle-boxes.  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-
> 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: "Richard Shockey" <[email-masked]>
Date: Tue, 22 Dec 2009 13:36:03 -0500

BIG +1  I never understood the objection to this idea. It helps solve a
multitude of problems.

>  From: [email-masked] [mailto:[email-masked]] On
>  Behalf Of Hadriel Kaplan
>  Sent: Tuesday, December 22, 2009 10:42 AM
>  To: [email-masked]
>  Subject: [dispatch] FW: I-D Action:draft-kaplan-dispatch-session-id-
>  00.txt
>  
>  
>  Howdy,
>  I've re-submitted a draft I originally submitted to the SIP WG back
>  when it was in existence.  The draft defines a session correlation
>  identifier for troubleshooting purposes.
>  
>  I'd like to have this dispatched to the appropriate WG, preferably the
>  SIP-CLF WG (since they're a prime customer of it).
>  
>  -hadriel
>  
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 22 Dec 2009 12:55:08 -0600

I'm remembering that Hadriel had two drafts at about the same time - one was 
a BCP on Call-ID, and one was on Session ID, and I'm remembering a lot of 
confusion during discussions.

So I'm hoping that at least some of the objection was caused by confusion!

https://datatracker.ietf.org/drafts/draft-kaplan-sip-secure-call-id/ and
https://datatracker.ietf.org/drafts/draft-kaplan-sip-session-id/, just for 
the record...

Thanks,

Spencer

----- Original Message ----- 
From: "Richard Shockey" <[email-masked]>
To: "'Hadriel Kaplan'" <[email-masked]>; <[email-masked]>
Sent: Tuesday, December 22, 2009 12:36 PM
Subject: Re: [dispatch] FW: 
I-DAction:draft-kaplan-dispatch-session-id-00.txt

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 23 Dec 2009 10:47:33 -0500

Yup, but they were really trying to solve two different problems, for different issues.

The secure-call-id one was trying to change the rfc3261 recommendation for call-id creation, so that middleboxes like SBC's wouldn't need to change them for security purposes, and so that dialog matching works better.  It won't make the call-id end-to-end though, because other B2BUAs/PBXs/etc. will still change the call-id.

The session-id was trying to create an identifier that crosses all boxes, for troubleshooting purposes.

They sound similar, but they're not.

-hadriel

> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Tuesday, December 22, 2009 1:55 PM
> To: Richard Shockey; Hadriel Kaplan; [email-masked]
> Subject: Re: [dispatch] FW: I-DAction:draft-kaplan-dispatch-session-id-
> 00.txt
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 23 Dec 2009 12:50:12 -0600

yeah, we still need to talk about the objections that weren't caused by 
confusion :-)

spencer

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Richard Shockey" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, December 23, 2009 9:47 AM
Subject: RE: [dispatch] FW: 
I-DAction:draft-kaplan-dispatch-session-id-00.txt

Yup, but they were really trying to solve two different problems, for 
different issues.

The secure-call-id one was trying to change the rfc3261 recommendation for 
call-id creation, so that middleboxes like SBC's wouldn't need to change 
them for security purposes, and so that dialog matching works better.  It 
won't make the call-id end-to-end though, because other B2BUAs/PBXs/etc. 
will still change the call-id.

The session-id was trying to create an identifier that crosses all boxes, 
for troubleshooting purposes.

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Wed, 23 Dec 2009 21:14:35 -0600

> I'd like to have this dispatched to the appropriate WG, preferably the SIP-CLF WG (since they're a prime customer of it).

Process question: If we think it is roughly in-scope for the CLF working 
group, do we need to "dispatch" it? Or just ask on their list and let 
them decide on whether to get the AD to add it to their charter?

And for what it is worth, I think we do need a session-correlator. 
Although I expect that somebody's SBC will remove it just for fun...

--
Dean

---

From: <[email-masked]>
Date: Thu, 24 Dec 2009 11:54:12 +0100

> And for what it is worth, I think we do need a
session-correlator. 
Session-ID is badly needed by the troubleshooting guys. It is also
needed in 3GPP IMS for the conference service, for session correlation
across SBCs and application servers. We already plan to implement the
current version of the draft. 

	> Although I expect that somebody's SBC will remove it just for
fun...
I don't think so. People, also incumbent carriers, learn from
implementation experience, and they are the main customers for SBCs.  

	> them decide on whether to get the AD to add it to their
charter?

I think this would make sense. 

Laura  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: Thursday, December 24, 2009 4:15 AM
> To: Hadriel Kaplan
> Cc: [email-masked]
> > I've re-submitted a draft I originally submitted to the SIP 
> WG back when it was in existence.  The draft defines a 
> session correlation identifier for troubleshooting purposes.  
> > 
> > I'd like to have this dispatched to the appropriate WG, 
> preferably the SIP-CLF WG (since they're a prime customer of it).
>

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 24 Dec 2009 10:01:21 -0600

Speaking as sipclf co-chair, I've been assured by my AD that session ID is 
not part of what sipclf is currently chartered to do.

I believe the "dispatching" part is for DISPATCH to say (1) this work 
matters, and (2) the right way to proceed is $PLAN... where $PLAN could be 
sending it to sipclf and adding it to the sipclf charter, but there can also 
be other $PLANs.

I'm not clear what the boundaries of what needs to be dispatched are - but 
session ID isn't close to those boundaries!

Spencer

> group, do we need to "dispatch" it? Or just ask on their list and let them 
> decide on whether to get the AD to add it to their charter?
>

---

From: Dean Willis <[email-masked]>
Date: Tue, 29 Dec 2009 01:16:27 -0600

[email-masked] wrote:

 > Dean Said:

My experience with incumbent carriers is much less hopeful. As far as I 
can tell, they only learn from new legislation or regulation, and then 
ony when fined large amounts for ignoring the rules.

Are we aware of any regulators willing to issue large fines for removing 
  the proposed session-OD?

--
Dean

---

From: <[email-masked]>
Date: Tue, 29 Dec 2009 12:36:26 +0100

Dean,

> Are we aware of any regulators willing to issue large fines 

Personally, I see two scenarios which may lead to the Session-ID being removed:

  1) I, don't expect such rules from regulators, rather the other way round. Regulators want control and legal interception and personal data privacy. 
Imagine some bad guys use the session-ID to send pornographic stuff end-to-end. Then the regulator will require carriers to disalow SIP-Headers with such content. What could a carrier do? Session-ID is a Hash and the carrier can not inspect its content and sort out just the "bad" Session-IDs. Probably in this case the first SBC in the network will have to drop the end device generated Session-ID and generate a new Session ID. Unfortunatly, not very e2e friendly. But do you see a better, more end-device-friendly solution, for this problem? 

   2) Another problem may occur is with SBCs and B2BUAswhich are Session-ID non-aware  (e.g. application servers). Many of them use positive rather then negative lists do decide what to drop and what to pass to the next hop. They drop headers which they don't know, exactly as the PSTN-switches did. Maybe this will change some time (from my point of view this is, in practice, a money machine for vendors and quite expensive for carriers), but this is what we have today. When such SBCs and B2BUAs are not upgraded with regard to Session ID, they will drop it, just because they don't know it. I think we can help to minimize the number of boxes which do not support Session-ID and drop it, by trying to reach soon a stable version of the draft, which can be used as a reference for vendors and monitoring systems.

Despite these problems, I am quite optimistic concerning the Session-ID:  

In the DT SIP network all, nodes will be upgraded to support the Session-ID because this is required by both customer support and by the sequrity guys to improve the customer service. 
 
    - When a customer calls the customer support "My call to....could not be set up" the support must trace all SIP messages of this call e2e. This is not possible without an e2e identifier. (I know, in part a self-made problem, but only in part. Regulators require legal interception and Callling Line Identification Restriction. One needs B2BUAs to do this. Maybe not so many of them...) 
    -  When customers complain about being charged for calls to special numbers they didn't call, we have, in most cases, to deal with stolen user-id and password. The security guys need to go through old traces and reconstruct the calls e2e.

Session-ID is needed to improve the customer service, so is for DT a "must". I don't now what other carriers do, but I think they have, or will have soon, similar problems. But I think people will use Session-ID, as soon as the draft has a stable status.   

Thanks a lot
Laura

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, December 29, 2009 8:16 AM
> To: Liess, Laura
> Cc: [email-masked]; [email-masked]; Hülsemann, 
> Martin; Jesske, Roland