Hadriel, I am not expecting all problems to be solved, just to not introduce new ones.
I believe that allowing a proxy to include a session-id header will introduce more problems than it solves. I know that we have to work with B2BUAs, and I understand the sentiment behind getting rid of them all together. The ietf work tends to preclude handling by B2BUAs but based upon the RFC3261 definition of a B2BUA as a concatenation of the UAC and UAS then all the ietf specifications have to ensure is that each Request can be routed to the correct B2BUA and then it is up to the B2BUA to ensure that it performs the correct actions for the end-to-end service. Based upon RFC3261 a B2BUA MUST map the call-id as a Call-id MUST be globally unique. As a B2BUA is a UAS/UAC the dialogs on either side of the B2BUA are different dialogs and must have different Call-ids. The major issue which currently occurs is that a PUI is used to try and route a request which should be directed to specific UA, e.g. when referencing an extant dialog. To reach the specific UA the Contact should be used and if a B2BUA maps the Contact as well as the Call-id then the new Request should route to the B2BUA which can perform its 'magic' to provide the end-to-end service. The problem at present is that B2BUA behavior is not defined and many implemented B2BUAs will not perform the correct actions to provide the end-to-end service. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 [EMAIL PROTECTED] -----Original Message----- From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] Sent: 28 November 2008 18:22 To: Ian Elz; Dan Wing; James M. Polk Cc: SIP List Subject: RE: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt I appreciate wanting to solve all possible scenarios (who doesn't! :), but I am fairly confident there is no possible solution to solve all possible scenarios. I am also fairly certain we can't even anticipate or document all possible scenarios. ISTM the only way to solve all possible scenarios is to have all B2BUA's stop changing call-id's and tags - in fact, to not have B2BUA's at all. Because that is the assumption all RFC uses of callid+tags have made so far. At this most recent IETF there appeared to be consensus that the real world has B2BUA's... LOTS of B2BUA's, of various flavors/roles/behaviors, from many vendors. And there appeared to be consensus that we should try to make things work with them, as much as pragmatically possible. > -----Original Message----- > Having something incomplete may be worse than nothing. We may have a > scenario where the partial solution gets implemented and then it will be > impossible to implement a final solution as you are required to be > backward compatible to the partial solution. I can't argue that some future mechanism can't be better than the session-id mechanism, obviously. But I would point out the session-id mechanism would not prevent future mechanisms, any more than current call-id+tag usage prevents the session-id mechanism. It would be a "if session-id match fails, then try this new thing if you understand it", or it could even be a "try this new thing first, and only if that fails or you don't understand it then try this session-id thing". Every extension to SIP can have those properties as far as I know. It just may need a parameter or new header to accomplish it. But I also don't want to spend 4 years trying to come up with and standardize a perfect solution, and have the problem last for those 4 years plus whatever time it takes to actually deploy the new solution. I'd rather have running code in weeks or months, and deployment as soon as possible - even if it means only some of the scenarios are covered but not all scenarios. (and that's not a comment against your comments - I'm just noting that's how long things take when they're anything more than really simple) -hadriel _______________________________________________ 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
