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. > [Ian Elz ] I have seen some of the 3gpp CRs which have suggested making > this change. My present view is that this should not be changed. The > solution may be that a B2BUA inserted contact should always be globally > routable That is technically and practically impossible. If 3GPP thinks it's possible, I suggest they talk to people who actually deploy their technology - i.e., the operators. :) SBC's have been able to generate the equivalent of GRUU's long before GRUU was invented, and it only works in certain cases. [and I don't mean that as a slam against 3gpp - it's hard to get the operators' views in the IETF too; and yes I know operators attend 3gpp, but either their voices aren't heard, or they're not aware of the nuances - none of us are aware of the nuances across all sip-related uses, imho] -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
