idnits 2.17.1 draft-holmberg-dispatch-iotl-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 12, 2015) is 3355 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This RFC' is mentioned on line 408, but not defined Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Holmberg 3 Internet-Draft J. Holm 4 Intended status: Standards Track Ericsson 5 Expires: August 16, 2015 R. Jesske 6 Deutsche Telekom 7 M. Dolly 8 ATT 9 February 12, 2015 11 3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic 12 Leg parameter 13 draft-holmberg-dispatch-iotl-05.txt 15 Abstract 17 In 3rd-Generation Partnership Project (3GPP) networks, the signalling 18 path between a calling user and a called user can be partioned into 19 segments, referred to as traffic legs. Each traffic leg may span 20 networks belonging to different operators, and will have its own 21 characteristics that can be different from other traffic legs in the 22 same call. A traffic leg might be associated with multiple SIP 23 dialogs, e.g. in case a B2BUA which modifies the SIP dialog 24 identifier is located within the traffic leg. 26 This document defines a new SIP URI parameter, 'iotl'. The parameter 27 can be used in a SIP URI to indicate that the entity associated with 28 the address, or an entity responsible for the host part of the 29 address, represents the end of a specific traffic leg (or multiple 30 traffic legs). 32 The SIP URI 'iotl' parameter defined in this document has known uses 33 in 3GPP networks. Usage in other networks is also possible. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on August 16, 2015. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.2. Originating roaming call . . . . . . . . . . . . . . . . 5 73 3.3. Terminating roaming call . . . . . . . . . . . . . . . . 5 74 3.4. Originating home to terminating home call . . . . . . . . 5 75 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6 76 5. iotl SIP URI parameter . . . . . . . . . . . . . . . . . . . 6 77 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 7 79 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 80 5.2.2. homea-homeb . . . . . . . . . . . . . . . . . . . . . 7 81 5.2.3. homeb-visitedb . . . . . . . . . . . . . . . . . . . 7 82 5.2.4. visiteda-homea . . . . . . . . . . . . . . . . . . . 7 83 5.2.5. homea-visiteda . . . . . . . . . . . . . . . . . . . 8 84 5.2.6. visiteda-homeb . . . . . . . . . . . . . . . . . . . 8 85 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 86 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 91 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 94 11.2. Informative References . . . . . . . . . . . . . . . . . 12 95 Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 13 96 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 13 97 A.2. The UE registers via P-CSCF . . . . . . . . . . . . . . . 13 98 A.3. Originating IMS call . . . . . . . . . . . . . . . . . . 14 99 A.4. Terminating IMS call . . . . . . . . . . . . . . . . . . 15 100 A.5. Call between originating home and terminating home 101 network . . . . . . . . . . . . . . . . . . . . . . . . . 16 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 104 1. Introduction 106 In a 3rd-Generation Partnership Project (3GPP) network, an end user 107 device can be attached (e.g. using a radio access network) to its own 108 operator network (home network) [TS.3GPP.24.229], or to another 109 operator's network (visited network) [TS.3GPP.24.229]. In the latter 110 case the user is referred to as a roaming user. 112 3GPP operator networks are often not connected directly to each 113 other. Instead, there might be intermediate networks, referred to as 114 3GPP transit networks, between them. Such transit network act on SIP 115 level or on IP level. 117 In 3GPP networks, the signalling path between a calling user and a 118 called user can be partioned into segments, referred to as traffic 119 legs. Each traffic leg may span networks belonging to different 120 operators, and will have its own characteristics that can be 121 different from other traffic legs in the same call. A traffic leg 122 might be associated with multiple SIP dialogs, e.g. in case a Back- 123 To-Back User Agent (B2BUA) [RFC3261] which modifies the SIP dialog 124 identifier is located within the traffic leg. 126 The traffic leg information can be used by intermediary entities to 127 make policy decisions, related to e.g. media anchoring, signalling 128 policy, insertion of media functions (e.g. transcoder) and charging. 130 The figure below shows two users (Alice and Bob) and the different 131 type of networks that the signaling might traverse. The signalling 132 path can be divided into multiple traffic legs, and the type of 133 traffic legs depends on how the signalling is routed. 135 Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob 136 Home + + + + + Home 137 + ++++++++++++++++++ + + 138 + + + 139 + + + 140 + +++++++++++++++++++++++ + 141 + + + + 142 Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob 143 Visited Visited 145 Figure 1: 3GPP operator network roaming roles 147 ORIG HNW = Originating 3GPP Home Network 149 TERM HNW = Terminating 3GPP Home Network 151 ORIG VNW = Originating 3GPP Visited Network 153 TERM VNW = Terminating 3GPP Visited Network 155 TRANSIT NW = 3GPP Transit Network 157 In Figure 1 Alice is a user initiating communication with Bob, and: 159 Alice is attached to an originating network, which is either the home 160 network of Alice, or a visited network (in case Alice is roaming). 161 In both cases any originating service is provided by the home network 162 of Alice. 164 Bob is attached to a terminating network, which is either the home 165 network of Bob, or a visited network (in case Bob is roaming). In 166 both cases any terminating service is provided by the home network of 167 Bob. 169 A transit network, providing transit functions (e.g. translation of 170 free phone numbers), may be included between the originating and 171 terminating networks and between visited and home networks. 173 This document defines a new SIP URI parameter [RFC3261], 'iotl' (an 174 abbreviation of Inter Operator Traffic Leg). The parameter can be 175 used in a SIP URI to indicate that the entity associated with the 176 address, or an entity responsible for the host part of the address, 177 represents the end of a specific traffic leg (or multiple traffic 178 legs). 180 This document defines the following 'iotl' parameter values: 182 o homea-homeb 184 o homeb-visitedb 186 o visiteda-homea 188 o homea-visiteda 190 o visiteda-homeb 192 SIP entities that do not support the SIP URI 'iotl' parameter will 193 simply ignore it, if received, as defined in [RFC3261]. 195 2. Applicability 197 The SIP URI 'iotl' parameter defined in this document has known uses 198 in 3GPP networks. Usage in other networks is also possible. 200 3. Use-cases 202 3.1. General 204 This section describes examples of different types of traffic legs in 205 3GPP networks. 207 3.2. Originating roaming call 209 In this case, Alice is located in a visited network. When Alice 210 sends the initial SIP INVITE request for a call, one traffic leg 211 (referred to as the 'visiteda-homea' traffic leg) represents the 212 signalling path between the UA of Alice and the home S-CSCF [3GPP TS 213 24.229] of Alice. 215 3.3. Terminating roaming call 217 In this case, Bob is located in a visited network. When the home 218 S-CSCF of Bob forwards the initial SIP INVITE request for a call 219 towards Bob, one traffic leg (referred to as the 'homeb-visitedb' 220 traffic leg) represents the signalling path between the home S-CSCF 221 of Bob and the UA of Bob. 223 3.4. Originating home to terminating home call 225 In this case, the home S-CSCF of Alice forwards the initial SIP 226 INVITE request towards the home S-CSCF of Bob. The signalling path 227 between the S-CSCFs represents one traffic leg (referred to as the 228 'homea-homeb' traffic leg). 230 4. Conventions 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in [RFC2119]. 236 5. iotl SIP URI parameter 238 5.1. Usage 240 As specified in [RFC3261], when a SIP entity inserts a SIP URI in an 241 initial request for a dialog, or in a stand-alone request, the SIP 242 URI will be used to route the request to another SIP entity, 243 addressed by the SIP URI, or to a SIP entity responsible for the host 244 part of the SIP URI (e.g. a SIP registrar). If such entity 245 represents the end of one or more traffic legs, the SIP entity 246 inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP 247 URI, to indicate the type(s) of traffic leg. Each parameter value 248 indicates a type of traffic leg. 250 For routing of a SIP request, a SIP entity can add the 'iotl' 251 parameter to the SIP URI of the Request-URI [RFC3261], or to the SIP 252 URI of a Route header field [RFC3261], of an initial request for a 253 dialog, or of an stand-alone request. SIP entities can add the 254 'iotl' parameter to the SIP URI of a Path header field [RFC3327] or a 255 Service-Route header field [RFC3608], in order for the parameter to 256 later occur in a Route header field. 258 When a SIP entity receives an initial request for a dialog, or a 259 stand-alone request, which contains one or more SIP URI 'iotl' 260 parameters, it identifies the type of traffic leg in the following 261 way: 263 o If the SIP request contains a single Route header field containing 264 a SIP URI with an 'iotl' parameter, that parameter identifies the 265 type of traffic leg; 267 o If the SIP request contains multiple Route header fields 268 containing a SIP URI with an 'iotl' parameter, the 'iotl' 269 parameter associated with the SIP URI of the topmost Route header 270 field (or, if the SIP URI of the topmost Route header field does 271 not contain an 'iotl' parameter, the SIP URI of the Route header 272 field closest to the topmost) identifies the type of traffic leg; 273 or 275 o If a SIP request contains an 'iotl' parameter only in the Request- 276 URI SIP URI, the 'iotl' parameter identifies the type of traffic 277 leg. 279 During SIP registration [RFC3261], entities can add the 'iotl' 280 parameter to the SIP URI of a Path or Service-Route header field, if 281 the entity is aware that SIP URI will be used to indicate the end of 282 a specific traffic leg for initial requests for dialogs, or stand- 283 alone requests, sent on the registration path. 285 As defined in [RFC3261], a SIP entity must not modify or remove uri 286 parameters from SIP URIs associated with other entities. This also 287 applies to the 'iotl' parameter. 289 5.2. Parameter Values 291 5.2.1. General 293 This section describes the SIP URI 'iotl' parameter values defined in 294 this specification. 296 5.2.2. homea-homeb 298 This value indicates that a SIP entity responsible for the host part 299 of the SIP URI associated with the parameter represents the end of a 300 traffic leg between the home network (originating) of the calling 301 user and the home network (terminating) of the called user. 303 In 3GPP, this traffic leg is between two S-CSCFs. 305 5.2.3. homeb-visitedb 307 This value indicates that the SIP entity addressed by the SIP URI 308 associated with the parameter represents the end of a traffic leg 309 between the home network (terminating) of the called user and the 310 visited network (terminating) in which the called user is located. 312 In 3GPP, this traffic leg is between the home S-CSCF and the UE of 313 the called user, or between the Service Centralization and Continuity 314 Application Server (SCC AS) in the home network of the called user 315 and Access Transfer Control Function (ATCF) in the visited network of 316 the called user. 318 5.2.4. visiteda-homea 320 This value indicates that a SIP entity responsible for the host part 321 of the SIP URI associated with the parameter represents the end of a 322 traffic leg between the visited network (originating) in which the 323 calling user is located and the home network (originating) of the 324 calling user. 326 In 3GPP, this traffic leg is between the UE and the home S-CSCF of 327 the calling user, or between the P-CSCF in the visited network, 328 serving the calling user, and the home S-CSCF of the calling user. 330 5.2.5. homea-visiteda 332 This value indicates that the SIP entity addressed by the SIP URI 333 associated with the parameter represents the end of a traffic leg 334 between the home network (originating) and the visited network 335 (originating) in which the calling user is located. 337 In 3GPP, this traffic leg is between the home S-CSCF of the calling 338 user and the Transit and Roaming Function (TRF) [3GPP TS 24.229] 339 serving the calling user, and exists in scenarios where the home 340 S-CSCF of the calling user forwards a request back to the visited 341 network where the UE of the calling user is located. An example of 342 this is when the Roaming Architecture for Voice over IMS with Local 343 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 345 5.2.6. visiteda-homeb 347 This value indicates that a SIP entity responsible for the host part 348 of the SIP URI associated with the parameter represents the end of a 349 traffic leg between the visited network (originating) of the calling 350 user and the home network (terminating) of the called user. 352 In 3GPP, this traffic leg is between the Transit and Roaming Function 353 (TRF) [3GPP TS 24.229] serving the calling user and the home S-CSCF 354 of the called user, and exists in scenarios where a request is 355 forwarded from the visited network where the calling user is located 356 directly to the home S-CSCF of the called user. An example of this 357 is when the Roaming Architecture for Voice over IMS with Local 358 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 360 6. Syntax 362 6.1. General 364 This section defines the ABNF for the 'iotl' SIP URI parameter. The 365 ABNF defined in this specification is conformant to RFC 5234 366 [RFC5234]. 368 This specification does not create an IANA registry for 'iotl' 369 parameter values. A registry should be considered if new parameter 370 values are defined in the future. 372 6.2. ABNF 374 The ABNF [RFC5234] grammar for the role SIP URI parameter is: 376 uri-parameter =/ iotl-param 377 iotl-param = iotl-tag "=" iotl-value ["." iotl-value] 378 iotl-tag = "iotl" 379 iotl-value = "homea-homeb" / "homeb-visitedb" / "visiteda-homea" 380 / "homea-visiteda" / "visiteda-homeb" / other-iotl 381 other-iotl = 1*iotl-char 382 iotl-char = alphanum / "-" 383 ;; alphanum defined in RFC 3261 385 7. Security Considerations 387 The information in the 'iotl' parameter is used for making policy 388 decisions. Such policies can be related to charging and triggering 389 of services. In order to prevent abuse, which could cause user 390 billing, or service failure, the parameter SHOULD only be used for 391 making policy decisions based on the role by nodes within the same 392 trust domain [RFC3325], and network boundary entities MUST NOT 393 forward information received from untrusted entities. In addition, 394 there MUST exist an agreement between the operators for usage of the 395 roaming role information. 397 General security considerations for SIP are defined in [RFC3261] 399 8. IANA Considerations 401 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 402 document.] This specification adds one new value to the IANA 403 registration in the "SIP/SIPS URI Parameters" registry as defined in 404 [RFC3969]. 406 Parameter Name Predefined Values Reference 407 ____________________________________________ 408 iotl Yes [This RFC] 410 9. Acknowledgments 412 The authors wish to thank everyone in the 3GPP community that gave 413 comments on the initial version of this document, and contributed 414 with comments and suggestion during the work. A special thanks to 415 Paul Kyziwat, Dale Worley and Michael Hammer. Robert Sparks 416 performed the Gen-ARTreview of the draft. 418 10. Change Log 420 [RFC EDITOR NOTE: Please remove this section when publishing] 422 draft-holmberg-dispatch-iotl-04 424 o Change based on IESG review from Spencer Dawkins: 426 o - List of defined iotl parameter values listed in the 427 Introduction. 429 o - ABNF editorial fix. 431 o Change based on IESG review from Barry Leiba: 433 o - Only use lowercase when writing the iotl parameter values. 435 o Change based on IESG review from Alissa Cooper: 437 o - Sentence about usage in non-3GPP networks removed from the 438 Introduction. 440 o - Editorial correction in the Security Considerations. 442 o Change based on IESG review from Benoit Claise: 444 o - 'iotl' parameter name abbreviation extented in the Introduction. 446 o Change based on IESG review from Kathleen Moriarty: 448 o - Reference to RFC 3261 added to the Security Considerations. 450 o Change based on IESG review from Stephen Farrell: 452 o - Additional text and explanation added to the Security 453 Considerations. 455 draft-holmberg-dispatch-iotl-03 457 o Change based on Gen-ART review from Robert Sparks: 459 o - Removed text saying that the mechanism is scoped for 3GPP 460 networks only. 462 o - Clarify that entities that do not support the parameter will 463 ignore it. 465 o - Clarify that the draft does not create an IANA registry for 466 parameter values. 468 o - Remove sentence regarding directionality. 470 o - Reference to RFC 3327 added. 472 o - Reference to RFC 3608 added. 474 o - 'dialogue' -> 'dialog'. 476 o Change based on Ops-ART review from Nevil Brownlee: 478 o - Reference to RFC 3261 added to 'B2BUA'. 480 o - Reference to 3GPP TS 24.229 added for 'S-CSCF'. 482 draft-holmberg-dispatch-iotl-02 484 o Change based on comments from Richard Barnes: 486 o - 3GPP scope text modified. 488 o - Reference to 3GPP TS 24.229 added. 490 o - Reference to RFC 3325 added, and incorporated into the Security 491 Considerations. 493 o - 'iotl' selection procedure made into a bullet list. 495 draft-holmberg-dispatch-iotl-01 497 o Scope the SIP URI 'iotl' parameter to 3GPP, based on decision at 498 IETF#90: 500 o - Document name changed. 502 o - Clarified that usage of the parameter is only defined within 503 3GPP networks. 505 draft-holmberg-dispatch-iotl-00 507 o Added text on how to identify the traffic leg type when SIP-URIs 508 of multiple Route header fields and/or the Request-URI contain an 509 'iotl' parameter. 511 o Clarify that a traffic leg might span over multiple SIP dialogs. 513 o Added text saying that entities supporting the 'iotl' parameter 514 must not remove a parameter from a request, if the parameter is 515 associated with a SIP URI belonging to another entity. 517 o Modified ABNF, in order to allow multiple iotl values for a single 518 URI. 520 o In IANA section, changed indication that predefined values exist. 522 o Example call flows added. 524 11. References 526 11.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, March 1997. 531 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 532 A., Peterson, J., Sparks, R., Handley, M., and E. 533 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 534 June 2002. 536 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 537 (SIP) Extension Header Field for Registering Non-Adjacent 538 Contacts", RFC 3327, December 2002. 540 [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 541 (SIP) Extension Header Field for Service Route Discovery 542 During Registration", RFC 3608, October 2003. 544 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 545 (IANA) Uniform Resource Identifier (URI) Parameter 546 Registry for the Session Initiation Protocol (SIP)", BCP 547 99, RFC 3969, December 2004. 549 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 550 Specifications: ABNF", STD 68, RFC 5234, January 2008. 552 [TS.3GPP.24.229] 553 3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229 554 12.6.0, September 2014. 556 11.2. Informative References 558 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 559 Extensions to the Session Initiation Protocol (SIP) for 560 Asserted Identity within Trusted Networks", RFC 3325, 561 November 2002. 563 Appendix A. 3GPP Examples 565 A.1. General 567 This section contains example call flows based on 3GPP usage of the 568 SIP URI 'iotl' parameter. 570 A.2. The UE registers via P-CSCF 572 The Visited Proxy (P-CSCF) adds the iotl value 'homeb-visitedb' to 573 the Path header field of the REGISTER request, to be used for 574 terminating routing towards Alice. The Home Proxy (S-CSCF) adds the 575 iotl value 'visiteda-homea' to the Service-Route header field, to be 576 used for originating initial/stand-alone requests from Alice. 578 Visited Proxy Visited Proxy Home Proxy Home Proxy 579 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 580 | | | | | 581 | REGISTER F1 | | | | 582 |--------------->| REGISTER F2 | | | 583 | |--------------->| REGISTER F3 | | 584 | | |--------------->| REGISTER F4 | 585 | | | |--------------->| 586 | | | | | 587 | | | | 200 (OK) F5 | 588 | | | |<---------------| 589 | | | 200 (OK) F6 | | 590 | | |<---------------| | 591 | | 200 (OK) F7 | | | 592 | |<---------------| | | 593 | 200 (OK) F8 | | | | 594 |<---------------| | | | 596 F1 REGISTER Alice -> P-CSCF 597 REGISTER sip:registrar.home1.net SIP/2.0 599 F2 REGISTER P-CSCF -> IBCF-V 600 REGISTER sip:registrar.home1.net SIP/2.0 601 Path: 603 F3 REGISTER IBCF-V -> IBCF-H 604 REGISTER sip:registrar.home1.net SIP/2.0 605 Path: 607 F4 REGISTER IBCF-H -> S-CSCF 608 REGISTER sip:registrar.home1.net SIP/2.0 609 Path: 611 F5 200 OK S-CSCF -> IBCF-H 612 200 OK 613 Path: 614 Service-Route: 616 F6 200 OK IBCF-H -> IBCF-V 617 200 OK 618 Path: 619 Service-Route: 621 F7 200 OK IBCF-V -> P-CSCF 622 200 OK 623 Path: 624 Service-Route: 626 F8 200 OK P-CSCF -> Alice 627 200 OK 628 Path: 629 Service-Route: 631 Figure 2: The UE registers via P-CSCF 633 A.3. Originating IMS call 635 In the originating INVITE request from Alice, the iotl value 636 'visiteda-homea', received in the Service-Route header field during 637 registration, is added to the Route header field representing the 638 Home Proxy S-CSCF, to indicate the traffic leg type between the 639 Visited Proxy P-CSCF and the Home Proxy S-CSCF. 641 Visited Proxy Visited Proxy Home Proxy Home Proxy 642 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 643 | | | | | 644 | INVITE F1 | | | | 645 |--------------->| INVITE F2 | | | 646 | |--------------->| INVITE F3 | | 647 | | |--------------->| INVITE F4 | 648 | | | |--------------->| 649 | | | | | 650 | | | | 180 F5 | 651 | | | 180 F6 |<---------------| 652 | | 180 F7 |<---------------| | 653 | 180 F8 |<---------------| | | 654 |<---------------| | | | 655 | | | | | 657 F1 INVITE Alice -> P-CSCF 658 INVITE sip:Bob@homeb.net SIP/2.0 659 Route: , 661 F2 INVITE P-CSCF -> IBCF-V 662 INVITE sip:Bob@homeb.net SIP/2.0 663 Route: , 665 F3 INVITE IBCF-V -> IBCF-H 666 INVITE sip:Bob@homeb.net SIP/2.0 667 Route: , 669 F4 INVITE IBCF-H -> S-CSCF 670 INVITE sip:Bob@homeb.net SIP/2.0 671 Route: 673 Figure 3: Originating IMS call 675 A.4. Terminating IMS call 677 In the terminating INVITE request towards Alice, the iotl value 678 'homeb-visitedb', provided to the Home Proxy S-CSCF during 679 registration, is added to the Route header field representing the 680 Visited Proxy P-CSCF, to indicate the traffic leg type between the 681 Home Proxy S-CSCF and the Visited Proxy P-CSCF. 683 Home Proxy Home Proxy Visited Proxy Visited Proxy 684 S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob 685 | | | | | 686 | INVITE F1 | | | | 687 |--------------->| INVITE F2 | | | 688 | |--------------->| INVITE F3 | | 689 | | |--------------->| INVITE F4 | 690 | | | |--------------->| 691 | | | | | 692 | | | | 180 F5 | 693 | | | 180 F6 |<---------------| 694 | | 180 F7 |<---------------| | 695 | 180 F8 |<---------------| | | 696 |<---------------| | | | 697 | | | | | 699 F1 INVITE S-CSCF -> IBCF-H 700 INVITE sip:Bob@visitedb.net SIP/2.0 701 Route: , IBCF-V 704 INVITE sip:Bob@visitedb.net SIP/2.0 705 Route: , P-CSCF 708 INVITE sip:Bob@visitedb.net SIP/2.0 709 Route: Bob 712 INVITE sip:Bob@visitedb.net SIP/2.0 714 Figure 4: Terminating IMS call 716 A.5. Call between originating home and terminating home network 718 The S-CSCF of the originating home network adds the iotl value 719 'homea-homeb' in the Request-URI of the INVITE, sent towards the 720 S-CSCF of the terminating network, to indicate the traffic leg type 721 between the S-CSCFs. 723 Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy 724 S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B 725 | | | | | 726 | INVITE F1 | | | | 727 |--------------->| INVITE F2 | | | 728 | |--------------->| INVITE F3 | | 729 | | |--------------->| INVITE F4 | 730 | | | |--------------->| 731 | | | | | 732 | | | | 180 F5 | 733 | | | 180 F6 |<---------------| 734 | | 180 F7 |<---------------| | 735 | 180 F8 |<---------------| | | 736 |<---------------| | | | 737 | | | | | 739 F1 INVITE S-CSCF-A -> IBCF-A 740 INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 742 F2 INVITE IBCF-a -> IBCF-B 743 INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 745 F3 INVITE IBCF-B -> I-CSCF-B 746 INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 748 F4 INVITE I-CSCF-B -> S-CSCF-B 749 INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 751 Figure 5: Call between originating home and terminating home network 753 Authors' Addresses 755 Christer Holmberg 756 Ericsson 757 Hirsalantie 11 758 Jorvas 02420 759 Finland 761 Email: christer.holmberg@ericsson.com 762 Jan Holm 763 Ericsson 764 Kistavagen 25 765 Stockholm16480 766 Sweden 768 Email: jan.holm@ericsson.com 770 Roland Jesske 771 Deutsche Telekom 772 Heinrich-Hertz-Strasse 3-7 773 Darmstadt 64307 774 Germany 776 Phone: +4961515812766 777 Email: r.jesske@telekom.de 779 Martin Dolly 780 ATT 781 718 Clairmore Ave 782 Lanoka Harbor 08734 783 USA 785 Email: md3135@att.com