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 > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Jonathan Rosenberg > Sent: Saturday, March 21, 2009 4:29 Pm > 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
