> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Hadriel Kaplan > Sent: 02 December 2008 21:36 > To: Ian Elz > Cc: SIP List > Subject: Re: [Sip] FW: I-D Action:draft-kaplan-sip-session-id-00.txt > > Hi Ian, comments inline... > > > -----Original Message----- > > From: Ian Elz [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, December 02, 2008 6:22 AM > > > > My main comment on your draft at present is the proposal to allow a > > proxy to insert the session-id header if it has not been > inserted by the > > UA. I think that this introduces additional problems of how > to ensure > > that the proxy in included in the message path of a new request that > > uses the session-id that it inserted as a reference to the original > > dialog. > > You mean that a "Proxy" in particular could do this, right? > (not that a B2BUA could do this?) > > Right now the draft is written to make the matching mechanics > basically optional for a node. The Session-ID header has > uses beyond dialog matching ones, and I prefer to keep the > bar low for implementations to at least pass it through, or > even generate it. You're right that a Proxy implementing the > matching function would need to keep itself in the path - > good catch - I will add it if we decide Proxies should be > able to do the matching function. (and yes, it could only > keep itself in the path in certain scenarios, so we may just > not want to let Proxies do a matching function period to make > the draft easier to comprehend) > > > > This requires 2 things: > > (1) that every B2BUA constantly be upgraded to handle whatever new > > mechanism's syntax is for the identifiers, every time a new one is > > defined. (e.g., new XML schema or new header) I realize that's the > > nature of "you break it, you fix it", but if people want to > have their > > new thing work without needing B2BUA's to be upgraded or > re-configured, > > then there needs to be some generic way of handling this. > > (2) that the mechanism using the call-id+tags gets sent to the B2BUA > > that changed them. Often it will. Sometimes it can't. > For example, > > the mediactrl-framework model. Stick a b2bua between the UA and the > > Media-Control-Client, and the application doesn't work - or wouldn't > > have, except they changed it to use a new identifier different from > > call-id to avoid this problem. > > > > [Ian Elz ] (1) is an issue with B2BUAs. Xavier's b2bua draft was an > > attempt to give some guidance on how B2BUAs should behave > to make them > > as proxy like as possible. > > Yes, and my own product does that as well by default (dialog > transparency). Many/most operators turn that off when they > install it, fwiw. But this isn't really about SBC's. If it > were only about SBC's, there would be other ways to skin this > cat. The problem is all B2BUA's. The number of B2BUA > vendors/products/types is scary. Most of them seem to change > Call-ID+tag's all the time, for reasons only they know. I > know it's not due to the security issues. I know some of > them change them to handle spirals correctly. I know some of > them change them for internal architecture reasons. But I > don't know all the reasons. I can't speak for them. [JRE] One reason is 3PCC behaviour. Suppose the B2BUA does 3PCC attended call transfer, i.e., it wants to join together two existing calls, each with its own call-ID. The resulting call will have different call-IDs on either side of the B2BUA, even if the original calls had only a single call-ID each.
John _______________________________________________ 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
