Subject: [Sip] comments on draft-kaplan-sip-session-id-01

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 21 Mar 2009 11:28:59 -0400

I think we all agree that it would be nice if there was an identifier 
that worked through b2bua, which we could use to identify dialogs.

However, I think the problem is far more complicated than this document 
talks about. The focus is on making it work through SBC type of boxes 
which aren't doing a lot of fancy call control, but are rewriting 
call-id and doing security things. There, I think the problem is easy.

However, there are lots of cases where more complicated dialog 
manipulation mucks this up in a really horrible way. In particular, 
enterprise features like transfer, park/pickup, and so on, are often 
implemented by means of re-INVITEs on dialogs all anchored in the 
IP-PBX. For example, consider the following transfer implementation:

A calls B. A calls C. Both calls are routed through an IP-PBX, which 
acts as a b2bua, and so we end up with something which looks like this:

  Please view in a fixed-width font such as Courier.

                     +------------+       S1
                S1   |            | ------------    B
             --------|            |
      A         S2   |   server   |
             --------|            |       S2
                     |            | -------------   C
                     |            |
                     +------------+

Where S1 and S2 are the two session IDs. So far, so good. Now, A 
transfers the call to B. A sends a REFER on dialog S1. Like it or not, 
due to frequent REFER/transfer interop issues, this is sometimes 
implemented as a re-INVITE from the server, connecting B and C's media 
streams together, and then disconnecting A, so that you end up with:

  Please view in a fixed-width font such
               as Courier.

         +------------+       S1
         |            | ------------    B
         |            |
         |   server   |
         |            |       S2
         |            | -------------   C
         |            |
         +------------+

Now B and C are talking to each other. What is the session ID for this 
dialog? B and C were both originally the UAS on different dialogs with 
different session IDs!

The problem happens more generally for any 3pcc operation, and the 
meta-issue is how to come up with a clear notion of who 'owns' the 
sessionID creation and destruction in cases where calls are transferred, 
moved, conferenced, parked and picked up all over the place.

As such, a true comprehensive solution to this problem is much more 
complicated than just 'tell the SBCs to stop mucking with this header'. 
It would need to account for a wider range of 3pcc and other dialog 
manipulations which occur in the wild. Or, we could try to scope this in 
a more limited way, focusing on the basic A-calls-B case and solve just 
the SBC problem.

Which is it?

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   111 Wood Avenue South
Cisco Fellow                                   Iselin, NJ 08830
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 21 Mar 2009 19:04:32 -0400

Hi Jonathan,
Yeah there was some email discussion about the various cases whereby the session-id wouldn't match anymore.  There are many, no doubt.  My point back then was that's ok: this is fixing cases that are broken, and not breaking cases that are working, so it's improving the situation even if not with 100% coverage.

But I got the sense several folks didn't like the idea of not fixing 100% of the cases, so I updated this draft a couple weeks ago to rev-02, and removed all the dialog-matching stuff and just made session-id for troubleshooting purposes.  I submitted secure-call-id to handle the Call-ID changing issues separately, in a different way.

-hadriel

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Jonathan Rosenberg
> Sent: Saturday, March 21, 2009 11:29 AM
> To: IETF SIP List
> Subject: [Sip] comments on draft-kaplan-sip-session-id-01
> 
> _______________________________________________
> 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: <[email-masked]>
Date: Mon, 23 Mar 2009 18:22:01 +0100

Jonathan,

The Session-ID it's already on the way to be implemented because it's
needed quite badly now. Most SIP services use B2BUAs.  Their operation
guys have big problems to correlate the call legs and find what's wrong
when customers call because their SIP ATA-box doesn't work. I can guess
your comment but there isn't anything we can do about it. The B2BUAs are
there to stay. 
The alternative to the Session-ID is every SIP serrvice implementing ist
own proprietary stuff. We can not want this happen.

We currently use the IP-address and ports in SDP for correlation in SIP
and MGCP/MeGaCo. This covers now about 90% of the traffic, but this will
change soon and we need something else.   

I agree with you that there is a clear need to solve the whole problem.
But I don't think we have a solution for it within the next eight weeks.

So let's get the Session-ID agreed as soon as possible so people can use
it. On the other side let's work on the more general problem. In my
opinion, the current version of the context-ID requirements draft is
intended to go into this direction, or did I miss something? 

Laura 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Jonathan Rosenberg
> Sent: Saturday, March 21, 2009 4:29 Pm 
> To: IETF SIP List

---

From: Dale Worley <[email-masked]>
Date: Wed, 25 Mar 2009 00:26:28 -0400

> dialog? B and C were both originally the UAS on different dialogs with 

The essential problem (which also shows up in
draft-loreto-sipping-context-id-requirements) is that you need to
express a correlation between two dialogs, but the correlation is
discovered after both of the dialogs have been initiated.

If I may be immodest, the References header could a solution:  State
that two dialogs are related to each other by (effectively) naming both
call-id's together, rather than by assigning them a common identifier
when they are created.

In regard to correlating the two legs of a call through an SBC, see
section 5.2 of draft-worley-references-02.  The SBC can put a References
header in a message going out on one leg that contains the call-id of
the dialog on the other leg, or vice-versa.  If the SBC wants to be
paranoid, it can create a pseudo-random pseudo-Call-Id and put it in a
References header in two messages, one going out each leg.  That's not
elegant, but it's effective and safe -- and doesn't depend on the UAs.

As far as I can tell, the References header handles all of the use cases
people have stated.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Mar 2009 03:10:27 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dale
> Worley
> Sent: Wednesday, March 25, 2009 12:26 AM
> 

Yeah but I'm not trying to solve that scenario. Session-ID is only trying to create a dialog identifier for a single "end-end dialog" that survives B2BUA's, for the purposes of troubleshooting that dialog.  It's NOT trying to correlate all subsequent dialogs, across all space/time, which may have some relationship to the original one.
  
For example, take Jonathan's example of two-calls get joined together with a REFER processed by a PBX (I think that's one we've actually discussed before, but maybe not).  There is dialog A and dialog B, and at some point half of A and half of B are joined together with re-INVITEs.  Personally I actually think that's a brand new session.  Because had the REFER actually gone end-to-end, that's exactly what would have happened: dialog C would be created.  Just because they happen to be re-using dialog identifiers (call-id/tags) from the original A and B dialogs, is essentially just a nuance of SIP protocol mechanics.  From the user's perspective they got transferred, from the admins/provider's perspective they got transferred, and from an architecture perspective they got transferred (i.e., the real "ends" of the dialog have now changed).

I don't debate that from a troubleshooting perspective it would be valuable to know that the new C dialog was created from the original A and B dialogs, but I'm not sure that needs to be known on the wire.  I mean minimally the PBX logs will show it.  But I can see the benefit for both.

> call-id's together, rather than by assigning them a common identifier

Yeah I think it adds value to have the References header.  I just don't think it should be referencing Call-ID's, or else we'll have to replace that too.  It should be referencing Session-ID's or secure-call-id's.  :)

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 25 Mar 2009 16:59:47 -0400

On Wed, 2009-03-25 at 03:10 -0400, Hadriel Kaplan wrote:
> Yeah I think it adds value to have the References header.  I just
> don't think it should be referencing Call-ID's, or else we'll have to
> replace that too.  It should be referencing Session-ID's or
> secure-call-id's.  :)

Certainly in security-sensitive situations, referencing Call-IDs, or at
least, ones created by UAs, would be undesirable.  But down in section
5.2 it describes how to have the B2BUA generate "linking" identifiers:

   A possible solution to this problem is for the B2BUA to create a
   "phantom" Call-Id that is suitably random, and use it in References
   headers sent in both the initial request and response.  By the
   transitivity property[Section 2], the dialogs on both sides of the
   B2BUA are declared to be related, even if the referenced dialog
   contains no messages.

   For two chained B2BUAs with no forking, this would give a message
   flow like this:

       UA 1            B2BUA 1         B2BUA 2         UA 2

            --->
            INVITE [email-masked]
            Call-Id: qwerty@aa

                            --->
                            INVITE [email-masked]
                            Call-Id: asdfgh@transit
                            References: QAZWSXEDCRFV;rel=serial

                                            --->
                                            INVITE [email-masked]
                                            Call-Id: zxcvbn@bb
                                            References: QAZWSXEDCRFV
                                                 ;rel=serial

                                            <---
                                            SIP/2.0 200 OK
                                            Call-Id: zxcvbn@bb

                            <---
                            SIP/2.0 200 OK
                            Call-Id: asdfgh@transit
                            References: QAZWSXEDCRFV;rel=serial

            <---
            SIP/2.0 200 OK
            Call-Id: qwerty@aa
            References: QAZWSXEDCRFV;rel=serial

Dale

---

From: Venkatesh <[email-masked]>
Date: Wed, 25 Mar 2009 14:40:57 -0700

A crazy thought occurred to me while I was reading this draft. If the intent
is for debugging and such, I am wondering if there is any value in
considering the re-use of the P-Charging-Vector header for this purpose?
After all, this is supposed to be unique, required to be carried across
Proxies, B2BUA's if one is present, reflected in CDR's if one is generated
by an entity?? Agree that this header had specific intents and cannot span
across "trust" boundaries, but I am not sure if a SP cares when the request
'leaves' their trust boundary? It seems to satisfy the requirement for
debugging? Flame away :-).
Venkatesh

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 25 Mar 2009 23:32:00 +0100

This only works if essentially your insertion and deletion requirements of the header are the same as those required by your accounting system.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Venkatesh
Sent: Wednesday, March 25, 2009 9:41 PM
To: Dale Worley
Cc: IETF SIP List
Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01

A crazy thought occurred to me while I was reading this draft. If the intent is for debugging and such, I am wondering if there is any value in considering the re-use of the P-Charging-Vector header for this purpose? After all, this is supposed to be unique, required to be carried across Proxies, B2BUA's if one is present, reflected in CDR's if one is generated by an entity?? Agree that this header had specific intents and cannot span across "trust" boundaries, but I am not sure if a SP cares when the request 'leaves' their trust boundary? It seems to satisfy the requirement for debugging? Flame away :-).

Venkatesh

On Wed, Mar 25, 2009 at 1:59 PM, Dale Worley <[email-masked]<mailto:[email-masked]>> wrote:

           --->
           INVITE [email-masked]<mailto:[email-masked]>
           Call-Id: qwerty@aa

                           --->
                           INVITE [email-masked]<mailto:[email-masked]>
                           Call-Id: asdfgh@transit
                           References: QAZWSXEDCRFV;rel=serial

                                           --->
                                           INVITE [email-masked]<mailto:[email-masked]>
                                           Call-Id: zxcvbn@bb
                                           References: QAZWSXEDCRFV
                                                ;rel=serial

                                           <---
                                           SIP/2.0 200 OK
                                           Call-Id: zxcvbn@bb

                           <---
                           SIP/2.0 200 OK
                           Call-Id: asdfgh@transit

           <---
           SIP/2.0 200 OK
           Call-Id: qwerty@aa

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]<mailto:[email-masked]> for questions on current sip
Use [email-masked]<mailto:[email-masked]> for new developments on the application of sip

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 25 Mar 2009 22:44:04 -0400

Yeah JDR mentioned the same thing.  Unfortunately that header value is created by middleboxes and removed by middleboxes.
-hadriel

________________________________
From: Venkatesh [mailto:[email-masked]]
Sent: Wednesday, March 25, 2009 5:41 PM
To: Dale Worley
Cc: Hadriel Kaplan; IETF SIP List
Subject: Re: [Sip] comments on draft-kaplan-sip-session-id-01

Venkatesh

           --->

                           --->

                                           --->

                                           <---
                                           SIP/2.0 200 OK
                                           Call-Id: zxcvbn@bb

                           <---
                           SIP/2.0 200 OK
                           Call-Id: asdfgh@transit

           <---
           SIP/2.0 200 OK
           Call-Id: qwerty@aa

Dale

---

From: <[email-masked]>
Date: Thu, 26 Mar 2009 18:53:02 +0100

Hadriel,
 
My company operates a SIP service with B2BUAs. We are very interested in
the progress of this draftt because without it trubleshooting is in many
cases not possible. Every SIP service provider which uses B2BUAs runs
sooner or later into this problem. From my point of view, the current
version is quite mature and coud become soon a WG item. 
 
Laura Liess
Deutsche Telekom

---

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Thu, 26 Mar 2009 14:06:20 -0400

We support this draft as well

From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, March 26, 2009 1:53 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Sip] draft-kaplan-sip-session-id-02

Hadriel,

Laura Liess

Deutsche Telekom

---

From: Venkatesh <[email-masked]>
Date: Thu, 26 Mar 2009 14:32:46 -0700

Thought per the 3GPP spec, this header got added at the first ingress point
into the network and removed at the last egress point from the network? So,
essentially you can trace the call using this header within your network?
Venkatesh

On Wed, Mar 25, 2009 at 3:32 PM, DRAGE, Keith (Keith) <
[email-masked]> wrote:

>  This only works if essentially your insertion and deletion requirements
> of the header are the same as those required by your accounting system.
>
> Keith
>
>  ------------------------------
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *
> Venkatesh
> *Sent:* Wednesday, March 25, 2009 9:41 PM
> *To:* Dale Worley
> *Cc:* IETF SIP List
> *Subject:* Re: [Sip] comments on draft-kaplan-sip-session-id-01
>
> A crazy thought occurred to me while I was reading this draft. If the
> intent is for debugging and such, I am wondering if there is any value in

---

From: Theo Zourzouvillys <[email-masked]>
Date: Sun, 29 Mar 2009 12:42:10 +0100

> We support this draft as well

I also support this draft.

 ~ Theo

Sent from: Bicester Oxfordshire United Kingdom.