comments on draft-kaplan-sip-session-id-01

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 protected]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email protected] for questions on current sip
Use [email protected] for new developments on the application of sip