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

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 protected] [mailto:[email protected]] 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
> 
> 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
_______________________________________________
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