Paul, I have changes the subject as this is getting too far from 199.
There are issues in this area relating to how the request containing the dialog reference header is routed. If there are multiple B2BUA in the message path of the original dialog then the new request which refers to this dialog must be routed to each of these B2BUA in the correct order to ensure that the dialog identity parameters can be correctly mapped. To ensure that this routing is performed in the correct order then there are two options: 1. have each B2BUA map the contact header and when a new request is created use the received contact header used as the Request URI for the new request. This results in an end-to-end gruu being meaningless as it must be mapped out by each B2BUA 2. have the UA which creates the request or response includes itself in the Record-Route header so that the route will specify the UAC/UAS of the B2BUA. This would allow the contact to be not mapped by the B2BUA as all routing would be from the Route header. There are other issues involved with the IMS as the initial routing of an initial or standalone request uses a preset route towards the P-CSCF which will then invoke the S-CSCF which use the iFC to find the appropriate Application Servers. It is only after this initial preset routing has occurred can the routing to the B2BUAs which have mapped the dialog identifying parameters from the original dialog. This effectively rules out the second option above as there is no means of passing the route set as defined buy the original dialog. My examination of this area has concluded the following: 1. The Call-Id must be mapped by B2BUA as this is required to be unique for each dialog (RFC 3261). If this is not mapped then the handling element is not a B2BUA as currently defined in RFC 3261, a concatenation of a UAC and UAS. 2. As the Call-Id must be mapped across the B2BUA there are separate dialogs on each side of the B2BUA and when a dialog reference header is used it must be mapped by the same B2BUAs as mapped the dialogs in the original dialog and in the same order. If this mapping does not happen correctly then the dialog will not be recognized. 3. The Contact header must be mapped by the B2BUA so that a request which uses the dialog reference headers can be correctly routed to each mapping B2BUA in turn to ensure that dialog identity in the dialog reference header and the Contact are correctly mapped. 4. The Request containing the dialog reference header must use the Contact received in the reference dialog as the R-URI in the new dialog. While the use of an end-to-end gruu may appear to be of benefit any Requests using this as the R-URI and containing a target dialog header will fail where the referenced identity was mapped by a B2BUA as the mapped dialog identity will not be recognized at the far end. Even if the original dialog identity was also passed from end-to-end in the original dialog and used in the subsequent dialog then from an IMS perspective this may result in the new Request being passed completely outside the scope of the IMS which may then bypass the whole IMS and its security mechanisms. There may be ways to redefine the B2BUA in sip so that mapping of any of the dialog identifying parameters, Call-Id, to and from tags, but this may leave a large number of legacy B2BUA which will not comply to the new definitions. I have just checked 3GPP TS24.229 v8.4.1 (latest version) and while it specifies mapping of the Replaces header in the AS there is no requirement to also map the Contact to the Contact received in the dialog being replaced. There is no mention of Target-Dialog in the specification at all so there is no way to remove multiple dialog usages. Replaces and Join are listed in the Profiles but there is no specific routing to indicate how initial requests using these headers are routed to the AS so that the mapping can occur. While Join is mentioned in the Profiles there is no requirement to map the Join parameter across a routing B2BUA. Ian Elz System Manager DUCI LDC UK (Lucid Duck) Office: + 44 24 764 35256 gsm: +44 7801723668 [EMAIL PROTECTED] -----Original Message----- From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: 18 August 2008 16:02 To: Ian Elz Cc: Robert Sparks; SIP IETF; Christer Holmberg Subject: Re: [Sip] Comments on draft-ietf-sip-199-00.txt Ian Elz wrote: > As my major focus is IMS the use of B2BUA is pretty much a given. The > issue with routing when the dialog reference headers are used needs to > be resolved before it is possible to send requests on new dialog. In the > current situation there is no option except to use multiple dialogs with > all the issues that these create. Ian, I think much of the responsibility here belongs with IMS rather than IETF. The B2BUAs specified by IMS *could* manage contacts so as to preserve the gruu property. I have helped write language for IMS that does so. I don't know whether that was adopted or not. But if not, then the ball is clearly in the IMS court. Thanks, Paul _______________________________________________ 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
