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
