Hadriel, Lets get the discussion back to your draft. While we could debate the merits of B2BUAs for a long time they exist and do some 'interesting' things.
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. I have included a few comments below. 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: 01 December 2008 19:01 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 Hi Ian, Comments inline... > -----Original Message----- > From: Ian Elz [mailto:[EMAIL PROTECTED] > Sent: Monday, December 01, 2008 4:35 AM > > 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. 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. (2) I am not familiar with the mediactrl-framework issues when using the call-id. I will look into this further. > 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. Actually that's debatable. I don't think we'd want to say B2BUA's MUST change the Call-ID. 3261 did say a B2BUA is the logical concatenation of a UAS and UAC, but clearly not much text in 3261 was given to how a B2BUA should operate. [Ian Elz ] It is debatable but section 8.1.1.4 of RFC 3261 does specify: " In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA." Thus as the B2BUA is a concatenation of a UAS and a UAC the UAC when it creates the ongoing out-of-dialog request must create a call-id which is globally unique which precludes using the call-id which was received by the UAS part of the B2BUA. This is pedantic view of the RFC but those are the words which are included, agreed and published. > 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. Some folks (from 3gpp) have asked that B2BAU's not change the contact-uri if it's a GRUU, though I'm not exactly sure why. There are also some cases in which having a B2BUA change the contact to be its specific instance doesn't work, because that address is not globally reachable; so leaving it as a GRUU (or something like a GRUU), is necessary but means out-of-dialog requests don't always reach the same B2BUA instance. This has been found in REFER transfer cases, where the referred party can't reach the same B2BUA as the referrer can. [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 or if the received Contact is a gruu then the inserted Contact should also be a gruu. There is work to be done in this area. -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
