idnits 2.17.1 draft-henrikson-sip-original-dialog-id-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 241: '...l-Dialog-ID header, it MAY insert a P-...' RFC 2119 keyword, line 243: '...om-tag parameter MUST be populated wit...' RFC 2119 keyword, line 244: '...to-tag parameter MUST be populated wit...' RFC 2119 keyword, line 246: '...all-id parameter MUST be populated wit...' RFC 2119 keyword, line 250: '...-Dialog-ID header, it MAY retrieve the...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 219 has weird spacing: '... where prox...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2002) is 7988 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) -- Obsolete informational reference (is this intentional?): RFC 3265 (ref. '8') (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 2976 (ref. '9') (Obsoleted by RFC 6086) == Outdated reference: A later version (-07) exists of draft-ietf-sip-message-04 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft E. Henrikson 3 Document: draft-henrikson-sip-original-dialog-id-02 Lucent 4 Expires: November 2002 Technologies 5 Category: Informational 6 May 2002 8 Private SIP Extension for Original Dialog Identifier 9 draft-henrikson-sip-original-dialog-id-02 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet-Drafts 24 as reference material or to cite them other than as "work in 25 progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This memo describes a private extension to SIP in the form of a 35 P-Original-Dialog-ID header. The header is used to correlate two 36 different dialogs across a B2BUA that is non-transparent to 37 dialogs. The contents of the header identify the original dialog 38 (Call-id, From tag, To tag) associated with the SIP entity that 39 inserted the header into a request. When the same instance of the 40 header is received at that SIP entity in a different request, then 41 it is used to correlate the two different dialogs. 43 Table of Contents 45 1. Background....................................................2 46 2. Discussion of Mechanism.......................................3 47 3. Applicability Statement.......................................4 48 4. P-Original-Dialog-ID syntax and definition....................4 49 5. Usage.........................................................5 50 5.1 Procedures at the UA......................................5 51 5.2 Procedures at the Proxy...................................5 52 5.3 Procedures at the Back to Back UA.........................6 53 5.4 Examples of Usage.........................................6 54 6. Security Considerations.......................................8 55 7. IANA Considerations...........................................8 56 8. Normative References..........................................8 57 9. Non-Normative References......................................8 58 Author's Addresses...............................................9 60 1. Background 62 Third Generation Partnership Project (3GPP) has selected SIP [1] as 63 the protocol to establish and tear down multimedia sessions in the 64 IP Multimedia Subsystem (IMS). A description of the IMS can be 65 found in 3GPP TS 23.228 [5] and 3GPP TS 24.229 [7]. 67 3GPP has defined a mechanism by which a stateful proxy (which has 68 additional functions) needs to associate an INVITE request 69 processed earlier with the INVITE request that is being currently 70 processed. The association is needed by the Serving Call Session 71 Control Function (S-CSCF) from the 3GPP architecture to ensure 72 proper routing of an INVITE request with 3GPP Application Servers 73 (AS). A S-CSCF may be required to route an INVITE request to 74 multiple AS in a particular order, as indicated by subscriber 75 profile data, and each AS may be a B2BUA. The S-CSCF needs to keep 76 track of each AS contacted and know that an incoming INVITE request 77 is related to a previous outgoing INVITE request such that each AS 78 may receive the INVITE request before it is sent on towards the 79 intended destination. Also, there is a need for the S-CSCF to 80 associated the different but related dialogs for charging purposes. 81 When a B2BUA AS is involved, there is currently not a way to 82 associate the incoming INVITE request with the previously sent 83 INVITE request at the S-CSCF. 85 The S-CSCF is a SIP proxy with additional functionality as defined 86 in draft-garcia-sipping-3gpp-reqs [3], 3GPP TS 23.218 [6] and 3GPP 87 TS 24.229 [7]. The S-CSCF contacts multiple Application Servers 88 (AS) in a particular order when certain SIP events occur, e.g. 89 receiving an INVITE request. These events are also known as Service 90 Points of Interest (SPI). The HSS (database entity) provides the S- 91 CSCF with the list of events and relative priorities of the 92 Application Servers to contact per event (and other information). 93 The data from the HSS is also known as Filter Criteria. 95 When an event occurs that matches an SPI from the Filter Criteria, 96 the SIP serving proxy needs to contact each AS that is matched 97 before sending the message on towards the final destination. Each 98 AS may alter the message in some way before returning the message 99 to the SIP serving proxy. Since the message may have been changed 100 by the AS, including the components of the dialog identifier, the 101 SIP serving proxy needs some way to determine that the received 102 message is related to the original message that it sent to the AS. 103 This will always be needed when an AS is acting as a B2BUA, which 104 starts a new dialog. 106 Consider the following example: 108 UA---P---I---S---AS---S---AS---S---AS---S---AS---S---I---P2---UA2 110 Every AS hop creates a new dialog -- so the above example actually 111 has 5 seperate dialogs. 113 One may consider using the Route header as a mechanism to get the 114 request sent back to the S-CSCF. However, Route headers don't 115 automatically transit an AS acting as a B2BUA. This could be 116 overcome by using loose-routing and application logic in the B2BUA. 117 But that is not the full problem to be solved. A strong correlation 118 of dialogs is also needed for accounting purposes to treat the 119 sequence of dialogs as a concatenated single dialog. A common 120 identification tag needs to be carried in each related dialog so 121 that the charging functions can associate all the dialogs. 123 The solution provided is to include the original dialog id in the 124 message sent to the AS and to have the AS return the same original 125 dialog id in the message sent back to the SIP serving proxy. Then 126 the SIP serving proxy can make the association between the two 127 messages and know that the incoming message is related to the 128 previous outgoing message, which is part of the sequence to contact 129 each AS that matched the Filter Criteria. 131 2. Discussion of Mechanism 133 The provided mechanism uses a private header "P-Original-Dialog-ID" 134 in an INVITE request forwarded from a proxy. The same mechanism may 135 be applied to other methods that initiate dialogs. The mechanism 136 only makes sense for stateful proxies that also employ some 137 application specific logic. 139 When a stateful proxy receives an INVITE that does not contain a P- 140 Original-Dialog-ID header, then it may choose to insert a P- 141 Original-Dialog-ID header into an INVITE request prior to 142 forwarding the request. If so, it will populate the contents with 143 the dialog identification fields from the received request: Call- 144 ID, From tag and To tag. If there was no To tag in the received 145 request, then a value of zero will be used for the To parameter in 146 the P-Original-Dialog-ID header. 148 When a stateful proxy receives an INVITE that already contains a P- 149 Original-Dialog-ID header, then it may use this information to look 150 for a match with a previously handled dialog. If no match is found, 151 then the message is simply forwarded to the next destination. If a 152 match is found, then depending on the application specific logic 153 that may reside with the proxy, the P-Original-Dialog-ID header may 154 be removed from the outbound message. 156 3. Applicability Statement 158 This mechanism is suitable when a proxy forwards an initial request 159 for a dialog, or a standalone transaction, to an AS that may act as 160 a B2BUA, and the request is expected to return to the proxy with a 161 need to correlate the original request and the forwarded request 162 for the transaction or the dialog. 164 The P-Original-Dialog-ID header is applicable whenever the 165 following circumstances are met: 167 1. A UAC sends a REGISTER or dialog initiating request (e.g., 168 INVITE) or a standalone transaction request to a proxy in 169 a private network. 170 2. The proxy in the private network that receives the request 171 needs to forward the request to one or more Application 172 Servers (AS) in a particular order. 173 3. One or more AS is a B2BUA and will return the modified 174 request back to the proxy. 175 4. The proxy in the private network needs to recognize that a 176 received, modified request is related to a previous 177 request. 178 5. Optionally, the proxy in the private network needs to 179 associate the different dialogs that are all related to 180 the original dialog for charging purposes. 182 4. P-Original-Dialog-ID syntax and definition 184 All of the mechanisms specified in this document are described in 185 both prose and an augmented Backus-Naur Form (BNF) defined in RFC 186 2234 [2]. Further, the BNF definitions from RFC 3261 [1] are 187 inherited for the P-Original-Dialog-ID header and are not repeated 188 here. Implementers need to be familiar with the notation and 189 content of RFC 3261 [1] and RFC 2234 [2] to understand this 190 document. 192 The syntax for the P-Original-Dialog-ID header is as follows: 194 p-original-dialog-id = "P-Original-Dialog-ID" HCOLON 195 dialog-params *(SEMI dialog-params) 196 dialog-params = call-id / to-tag / from-tag / generic-param 197 call-id = "call-id" EQUAL callid 198 to-tag = "to-tag" EQUAL token 199 from-tag = "from-tag" EQUAL token 201 Example: 202 P-Original-Dialog-ID: call-id=123@abc;to-tag=456;from-tag=789 204 A P-Original-Dialog-ID header may be inserted into an INVITE or 205 other standalone or dialog initiating request by any SIP node 206 traversed by that message. However, there may only be one instance 207 of a P-Original-Dialog-ID in a SIP message. Further, a particular 208 instance of P-Original-Dialog-ID shall contain exactly one of each 209 of the parameters: call-id, to-tag and from-tag. 211 The allowable usage of headers is described in Table 2 of SIP [1]. 212 Addition of P-Original-Dialog-ID to the Table 2 in SIP [1], section 213 4.1 of the SIP-specific event notification [8], tables 1 and 2 in 214 the SIP INFO method [9], tables 1 and 2 in Reliability of 215 provisional responses in SIP [10], tables 1 and 2 in the SIP UPDATE 216 method [11], tables 1 and 2 in the SIP extension for Instant 217 Messaging [12] and table 1 in the SIP REFER method [13]: 219 Header field where proxy ACK BYE CAN INV OPT REG 220 ___________________________________________________________ 221 P-Original-Dialog-ID R ard - - - o o o 223 Header field SUB NOT PRA INF UPD MES REF 224 _______________________________________________________________ 225 P-Original-Dialog-ID o - - - - o - 227 5. Usage 228 5.1 Procedures at the UA 230 The UAC and UAS (originating and terminating UA) behave as usual. 231 They are not required to understand the P-Original-Dialog-ID 232 header, but may retrieve the information if received. 234 5.2 Procedures at the Proxy 236 The P-Original-Dialog-ID header is treated like any other unknown 237 header by intermediate proxies. They simply forward it on towards 238 the destination. 240 If a proxy that supports this extension receives a dialog request 241 without the P-Original-Dialog-ID header, it MAY insert a P- 242 Original-Dialog-ID header prior to forwarding the message. The 243 from-tag parameter MUST be populated with the received From tag 244 value. The to-tag parameter MUST be populated with the received To 245 tag value or the value of zero if there was no To tag present. The 246 call-id parameter MUST be populated with the received Call-ID 247 value. 249 If a proxy that supports this extension receives a dialog request 250 with the P-Original-Dialog-ID header, it MAY retrieve the 251 information from the header to use with application specific logic. 252 The proxy SHOULD retain the P-Original-Dialog-ID header in the 253 outbound message. If the next hop for the message is outside the 254 network of the proxy, then the proxy MAY remove the P-Original- 255 Dialog-ID header from the message. 257 The P-Original-Dialog-ID header carries only tag information, and 258 therefore does not reveal information that may affect the privacy 259 of the remote users; however the information contained is of no 260 relevance to the end UAs and therefore MAY be removed as defined 261 above for reasons of protocol efficiency which may be of concern in 262 a radio environment. 264 5.3 Procedures at the Back to Back UA 266 If a B2BUA that understands the P-Original-Dialog-ID header 267 receives a dialog request with the P-Original-Dialog-ID header, the 268 B2BUA SHOULD copy it from the receiving side UA to the sending side 269 UA. 271 5.4 Examples of Usage 273 We present example in the context of the scenario presented in the 274 Background section earlier in this document. The network diagram 275 is replicated below: 277 Scenario 279 UA1----P1-----AS-----P1-----P3-----UA2 281 This example shows the message sequence for an INVITE transaction 282 originating from UA1 eventually arriving at UA2. P1 is an outbound 283 proxy for UA1 which routes the request to an Application Server 284 (AS). In this case the Application Server acts as a B2BUA 285 independent of any knowledge of P1. AS routes the request back to 286 P1 using SIP routeing mechanisms that are not detailed in this 287 example. P1 correlates the original request with the returned 288 request. P1 then routes the call via P3 to UA2. 290 Message sequence for INVITE using P-Original-Dialog-ID: 292 F1 INVITE UA1 -> P1 293 INVITE sip:joe SIP/2.0 294 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 295 To: Joe 296 From: UA@HOMEDOMAIN ;tag=456248 297 Call-ID: 843817637684230@998sdasdh09 298 CSeq: 18 INVITE 299 Contact: 300 . . . 302 F2 INVITE P1 -> AS 303 INVITE sip:joe SIP/2.0 304 Via: SIP/2.0/UDP P1:5060;branch=z9hG4bK34ghi7ab04 305 Via: SIP/2.0/UDP 192.0.2.4:5060;branch=z9hG4bKnashds7 306 To: Joe 307 From: UA@HOMEDOMAIN ;tag=456248 308 Call-ID: 843817637684230@998sdasdh09 309 CSeq: 18 INVITE 310 Contact: 311 P-Original-Dialog-ID: call-id=843817637684230@998sdasdh09; 312 to-tag=0;from-tag=456248 313 . . . 315 F3 INVITE AS -> P1 316 INVITE sip:joe SIP/2.0 317 Via: SIP/2.0/UDP AS:5060;branch=z9hG4bKiokioukju908 318 To: Joe 319 From: AS@HOMEDOMAIN ;tag=934871 320 Call-ID: 383749274837591@567ahjk8321 321 CSeq: 4 INVITE 322 Contact: 323 P-Original-Dialog-ID: call-id=843817637684230@998sdasdh09; 324 to-tag=0;from-tag=456248 325 . . . 327 P1 removes the P-Original-Dialog-ID header 329 F5 INVITE P1 -> P3 330 INVITE sip:joe@UA2 331 Via: SIP/2.0/USP P1:5060;branch=z9hG4bKHSP10120323 332 Via: SIP/2.0/UDP AS:5060;branch=z9hG4bKiokioukju908 333 To: Joe 334 From: AS@HOMEDOMAIN ;tag=934871 335 Call-ID: 383749274837591@567ahjk8321 336 CSeq: 4 INVITE 337 Contact: 338 . . . 340 INVITE propagates toward UA2 as usual. 342 6. Security Considerations 344 It is possible for proxies between the originating UA and the 345 terminating UA to modify the value of P-Original-Dialog-ID or to 346 insert a P-Original-Dialog-ID into a request for a dialog, e.g. 347 INVITE request. Therefore, an integrity protection mechanism such 348 as IPsec or other available mechanisms SHOULD be applied in order 349 to prevent such attacks. 351 The information contained is tag information from the original 352 request, and therefore knowledge of the contents of this header 353 does not compromise the privacy of the UA or any of the involved 354 proxies. 356 7. IANA Considerations 358 This document defines the SIP extension header "P-Original-Dialog- 359 ID" which should be included in the registry of SIP headers defined 360 in SIP [1]. As required by the SIP change process draft-tsvarea- 361 sipchange [4] the SIP extension header name "Original-Dialog-ID" 362 should also be registered in association with this extension. 364 8. Normative References 366 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 367 Peterson, J., Sparks, R., Handley, M., Schooler, E., "SIP: Session 368 Initiation Protocol, RFC 3261", March 2002. 370 [2] D. Crocker, Ed., and P. Overell, "Augmented BNF for syntax 371 specifications: ABNF," RFC 2234, Internet Engineering Task Force, 372 November 1997. 374 9. Non-Normative References 376 [3] Garcia, M., et al, "3GPP requirements on SIP, draft-garcia- 377 sipping-3gpp-reqs-03.txt", March 2002. 379 [4] Mankin, A., "SIP Change Process draft-tsvarea-sipchange", 380 March 2002. 382 [5] 3GPP TS 23.228 "IP Multimedia Subsystem (IMS) (Stage 2) - 383 Release 5". 385 [6] 3GPP TS 23.218 " IP Multimedia (IM) Session Handling; IM call 386 model - Release 5". 388 [7] 3GPP TS 24.229 "IP Multimedia Subsystem (IMS) (Stage 3) - 389 Release 5". 391 [8] A. Roach, SIP-Specific Event Notification, RFC 3265, March 392 2002. 394 [9] S. Donovan, The SIP INFO method, RFC 2976, October 2000. 396 [10] J. Rosenberg, H. Schulzrinne, Reliability of Provisional 397 Responses in SIP, RFC 3262, March 2002. 399 [11] J. Rosenberg, The Session Initiation Protocol UPDATE Method, 400 draft-ietf-sip-update-02.txt, April 2002, work in progress. 402 [12] B. Campbell, J. Rosenberg, H. Schulzrinne, C. Huitema, D. 403 Gurle, Session Initiation Protocol Extension for Instant Messaging, 404 draft-ietf-sip-message-04, May 2002, work in progress. 406 [13] R. Sparks, The REFER method, draft-sparks-sip-refer-split- 407 00.txt, April 2002, work in progress. 409 Author's Addresses 411 Eric Henrikson 412 Lucent Technologies 413 11601 Willows Rd 414 Suite 100 415 Redmond, WA 98052 416 US 418 Phone: +1 425 497 2442 419 EMail: ehenrikson@lucent.com 420 URI: http://www.lucent.com/