idnits 2.17.1 draft-holmberg-dispatch-iotl-02.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 (August 21, 2014) is 3536 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 387, 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: February 22, 2015 R. Jesske 6 Deutsche Telekom 7 M. Dolly 8 ATT 9 August 21, 2014 11 3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic 12 Leg parameter 13 draft-holmberg-dispatch-iotl-02.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. The directionality in traffic legs relates to a SIP 23 request creating a dialogue and stand-alone SIP request. A traffic 24 leg might be associated with multiple SIP dialogs, e.g. in case a 25 B2BUA which modifies the SIP dialog identifier is located within the 26 traffic leg. 28 This document defines a new SIP URI parameter, 'iotl', which can be 29 used in a SIP URI to indicate that the entity associated with the 30 address, or an entity responsible for the host part of the address, 31 represents the end of a specific traffic leg (or multiple traffic 32 legs). 34 The 'iotl' parameter is defined in order to fulfil requirements from 35 the 3GPP. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on February 22, 2015. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.2. Originating roaming call . . . . . . . . . . . . . . . . 5 76 3.3. Terminating roaming call . . . . . . . . . . . . . . . . 5 77 3.4. Originating home to terminating home call . . . . . . . . 5 78 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 5. iotl SIP URI parameter . . . . . . . . . . . . . . . . . . . 5 80 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 81 5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 7 82 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 83 5.2.2. homeA-homeB . . . . . . . . . . . . . . . . . . . . . 7 84 5.2.3. homeB-visitedB . . . . . . . . . . . . . . . . . . . 7 85 5.2.4. visitedA-homeA . . . . . . . . . . . . . . . . . . . 7 86 5.2.5. homeA-visitedA . . . . . . . . . . . . . . . . . . . 7 87 5.2.6. visitedA-homeB . . . . . . . . . . . . . . . . . . . 8 88 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 93 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 94 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 95 11. Normative References . . . . . . . . . . . . . . . . . . . . 10 96 Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 10 97 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 98 A.2. The UE registers via P-CSCF . . . . . . . . . . . . . . . 10 99 A.3. Originating IMS call . . . . . . . . . . . . . . . . . . 12 100 A.4. Terminating IMS call . . . . . . . . . . . . . . . . . . 13 101 A.5. Call between originating home and terminating home 102 network . . . . . . . . . . . . . . . . . . . . . . . . . 13 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 105 1. Introduction 107 In a 3rd-Generation Partnership Project (3GPP) network, an end user 108 can be attached (e.g. using a radio access network) to its own 109 operator network (home network), or to another operator's network 110 (visited network). In the latter case the user is referred to as a 111 roaming user. 113 3GPP operator networks are often not connected directly to each 114 other. Instead, there might be intermediate networks, referred to as 115 3GPP transit networks, between them. Such transit network act on SIP 116 level or on IP level. 118 In 3GPP networks, the signalling path between a calling user and a 119 called user can be partioned into segments, referred to as traffic 120 legs. Each traffic leg may span networks belonging to different 121 operators, and will have its own characteristics that can be 122 different from other traffic legs in the same call. The 123 directionality in traffic legs relates to a SIP request creating a 124 dialogue and stand-alone SIP request. A traffic leg might be 125 associated with multiple SIP dialogs, e.g. in case a B2BUA which 126 modifies the SIP dialog identifier is located within the traffic leg. 128 The traffic leg information can be used by intermediary entities to 129 make policy decisions, related to e.g. media anchoring, signalling 130 policy, insertion of media functions (e.g. transcoder) and charging. 132 The figure below shows two users (Alice and Bob) and the different 133 type of networks that the signaling might traverse. The signalling 134 path can be divided into multiple traffic legs, and the type of 135 traffic legs depends on how the signalling is routed. 137 Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob 138 Home + + + + + Home 139 + ++++++++++++++++++ + + 140 + + + 141 + + + 142 + +++++++++++++++++++++++ + 143 + + + + 144 Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob 145 Visited Visited 147 Figure 1: 3GPP operator network roaming roles 149 ORIG HNW = Originating 3GPP Home Network 151 TERM HNW = Terminating 3GPP Home Network 153 ORIG VNW = Originating 3GPP Visited Network 155 TERM VNW = Terminating 3GPP Visited Network 157 TRANSIT NW = 3GPP Transit Network 159 In Figure 1 Alice is a user initiating communication with Bob, and: 161 Alice is attached to an originating network, which is either the home 162 network of Alice, or a visited network (in case Alice is roaming). 163 In both cases any originating service is provided by the home network 164 of Alice. 166 Bob is attached to a terminating network, which is either the home 167 network of Bob, or a visited network (in case Bob is roaming). In 168 both cases any terminating service is provided by the home network of 169 Bob. 171 A transit network, providing transit functions (e.g. translation of 172 free phone numbers), may be included between the originating and 173 terminating networks and between visited and home networks. 175 This document defines a new SIP URI parameter [RFC3261], 'iotl', 176 which can be used in a SIP URI to indicate that the entity associated 177 with the address, or an entity responsible for the host part of the 178 address, represents the end of a specific traffic leg (or multiple 179 traffic legs). 181 The 'iotl' parameter is defined in order to fulfil requirements from 182 the 3rd-Generation Partnership Project (3GPP), but it can also be 183 used in other network environments. 185 2. Applicability 187 The SIP URI 'iotl' parameter defined in this document is only 188 applicable to 3GPP networks. The usage of the parameter within other 189 types of networks is undefined. 191 3. Use-cases 193 3.1. General 195 This section describes examples of different types of traffic legs in 196 3GPP networks. 198 3.2. Originating roaming call 200 In this case, Alice is located in a visited network. When Alice 201 sends the initial SIP INVITE request for a call, one traffic leg 202 (referred to as the 'visitedA-homeA' traffic leg) represents the 203 signalling path between the UA of Alice and the home S-CSCF of Alice. 205 3.3. Terminating roaming call 207 In this case, Bob is located in a visited network. When the home 208 S-CSCF of Bob forwards the initial SIP INVITE request for a call 209 towards Bob, one traffic leg (referred to as the 'homeB-visitedB' 210 traffic leg) represents the signalling path between the home S-CSCF 211 of Bob and the UA of Bob. 213 3.4. Originating home to terminating home call 215 In this case, the home S-CSCF of Alice forwards the initial SIP 216 INVITE request towards the home S-CSCF of Bob. The signalling path 217 between the S-CSCFs represents one traffic leg (referred to as the 218 'homeA-homeB' traffic leg). 220 4. Conventions 222 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 223 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 224 document are to be interpreted as described in [RFC2119]. 226 5. iotl SIP URI parameter 228 5.1. Usage 230 As specified in [RFC3261], when a SIP entity inserts a SIP URI in an 231 initial request for a dialog, or in a stand-alone request, the SIP 232 URI will be used to route the request to another SIP entity, 233 addressed by the SIP URI, or to a SIP entity responsible for the host 234 part of the SIP URI (e.g. a SIP registrar). If such entity 235 represents the end of one or more traffic legs, the SIP entity 236 inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP 237 URI, to indicate the type(s) of traffic leg. Each parameter value 238 indicates a type of traffic leg. 240 For routing of a SIP request, a SIP entity can add the 'iotl' 241 parameter to the SIP URI of the Request-URI [RFC3261], or to the SIP 242 URI of a Route header field [RFC3261], of an initial request for a 243 dialog, or of an stand-alone request. 245 If, within an initial request for a dialog, or within a stand-alone 246 request, multiple Route header fields contain a SIP URI with a 'iotl' 247 parameter, the 'iotl' parameter associated with the SIP URI of the 248 topmost Route header field (or, if the SIP URI of the topmost Route 249 header field does not contain an 'iotl' parameter, the SIP URI of the 250 Route header field closest to the topmost) identifies the type of 251 traffic leg. 253 If a SIP request contains an 'iotl' parameter both in the Request-URI 254 SIP URI, and in one or more SIP-URIs of the Route header fields, the 255 'iotl' parameter associated with the SIP URI of the topmost Route 256 header field (or, if the SIP URI of the topmost Route header field 257 does not contain an 'iotl' parameter, the SIP URI of the Route header 258 field closest to the topmost) identifies the type of traffic leg. 260 If a SIP request contains an 'iotl' parameter only in the Request-URI 261 SIP URI, the 'iotl' parameter identifies the type of traffic leg. 263 During SIP registration [RFC3261], entities can add the 'iotl' 264 parameter to the SIP URI of a Path or Service-Route header field, if 265 the entity is aware that SIP URI will be used to indicate the end of 266 a specific traffic leg for initial requests for dialogs, or stand- 267 alone requests, sent on the registration path. 269 An entity that understands the 'iotl' parameter MUST NOT, from a SIP 270 request, remove 'iotl' parameters from SIP URIs associated with other 271 entities, unless the entity has means to determine that the 'iotl' 272 parameter does not represent a valid traffic leg. 274 This document does not specify the usage of the 'iotl' parameter 275 within a SIP URI of a Record-Route header field [RFC3261]. 277 5.2. Parameter Values 279 5.2.1. General 281 This section describes the SIP URI 'iotl' parameter values defined in 282 this specification. 284 5.2.2. homeA-homeB 286 This value indicates that a SIP entity responsible for the host part 287 of the SIP URI associated with the parameter represents the end of a 288 traffic leg between the home network (originating) of the calling 289 user and the home network (terminating) of the called user. 291 In 3GPP, this traffic leg is between two S-CSCFs. 293 5.2.3. homeB-visitedB 295 This value indicates that the SIP entity addressed by the SIP URI 296 associated with the parameter represents the end of a traffic leg 297 between the home network (terminating) of the called user and the 298 visited network (terminating) in which the called user is located. 300 In 3GPP, this traffic leg is between the home S-CSCF and the UE of 301 the called user, or between the Service Centralization and Continuity 302 Application Server (SCC AS) in the home network of the called user 303 and Access Transfer Control Function (ATCF) in the visited network of 304 the called user. 306 5.2.4. visitedA-homeA 308 This value indicates that a SIP entity responsible for the host part 309 of the SIP URI associated with the parameter represents the end of a 310 traffic leg between the visited network (originating) in which the 311 calling user is located and the home network (originating) of the 312 calling user. 314 In 3GPP, this traffic leg is between the UE and the home S-CSCF of 315 the calling user, or between the P-CSCF in the visited network, 316 serving the calling user, and the home S-CSCF of the calling user. 318 5.2.5. homeA-visitedA 320 This value indicates that the SIP entity addressed by the SIP URI 321 associated with the parameter represents the end of a traffic leg 322 between the home network (originating) and the visited network 323 (originating) in which the calling user is located. 325 In 3GPP, this traffic leg is between the home S-CSCF of the calling 326 user and the Transit and Roaming Function (TRF) [3GPP TS 24.229] 327 serving the calling user, and exists in scenarios where the home 328 S-CSCF of the calling user forwards a request back to the visited 329 network where the UE of the calling user is located. An example of 330 this is when the Roaming Architecture for Voice over IMS with Local 331 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 333 5.2.6. visitedA-homeB 335 This value indicates that a SIP entity responsible for the host part 336 of the SIP URI associated with the parameter represents the end of a 337 traffic leg between the visited network (originating) of the calling 338 user and the home network (terminating) of the called user. 340 In 3GPP, this traffic leg is between the Transit and Roaming Function 341 (TRF) [3GPP TS 24.229] serving the calling user and the home S-CSCF 342 of the called user, and exists in scenarios where a request is 343 forwarded from the visited network where the calling user is located 344 directly to the home S-CSCF of the called user. An example of this 345 is when the Roaming Architecture for Voice over IMS with Local 346 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 348 6. Syntax 350 6.1. General 352 This section defines the ABNF for the 'iotl' SIP URI parameter. The 353 ABNF defined in this specification is conformant to RFC 5234 354 [RFC5234]. 356 6.2. ABNF 358 The ABNF [RFC5234] grammar for the role SIP URI parameter is: 360 uri-parameter = transport-param / user-param / method-param / ttl-param 361 / maddr-param / lr-param / iotl-param / other-param 362 iotl-param = iotl-tag "=" iotl-value ["." iotl-value] 363 iotl-tag = "iotl" 364 iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" 365 / "homeA-visitedA" /" visitedA-homeB" / other-iotl 366 other-iotl = 1*iotl-char 367 iotl-char = alphanum / "-" 368 ;; alphanum defined in RFC 3261 370 7. Security Considerations 372 There SHOULD exis a trust relationship between the networks that 373 provide the roaming role and the networks that use the information 374 for making policy decisions based on the role. In addition, there 375 MUST exist an agreement between the operators for usage of the 376 roaming role information. 378 8. IANA Considerations 380 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 381 document.] This specification adds one new value to the IANA 382 registration in the "SIP/SIPS URI Parameters" registry as defined in 383 [RFC3969]. 385 Parameter Name Predefined Values Reference 386 ____________________________________________ 387 iotl Yes [This RFC] 389 9. Acknowledgments 391 The authors wish to thank everyone in the 3GPP community that gave 392 comments on the initial version of this document. 394 10. Change Log 396 [RFC EDITOR NOTE: Please remove this section when publishing] 398 draft-holmberg-dispatch-iotl-01 400 o Scope the SIP URI 'iotl' parameter to 3GPP, based on decision at 401 IETF#90: 403 o - Document name changed. 405 o - Clarified that usage of the parameter is only defined within 406 3GPP networks. 408 draft-holmberg-dispatch-iotl-00 410 o Added text on how to identify the traffic leg type when SIP-URIs 411 of multiple Route header fields and/or the Request-URI contain an 412 'iotl' parameter. 414 o Clarify that a traffic leg might span over multiple SIP dialogs. 416 o Added text saying that entities supporting the 'iotl' parameter 417 must not remove a parameter from a request, if the parameter is 418 associated with a SIP URI beloning to another entity. 420 o Modified ABNF, in order to allow multiple iotl values for a single 421 URI. 423 o In IANA section, changed indication that predefined values exist. 425 o Example call flows added. 427 11. Normative References 429 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 430 Requirement Levels", BCP 14, RFC 2119, March 1997. 432 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 433 A., Peterson, J., Sparks, R., Handley, M., and E. 434 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 435 June 2002. 437 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 438 (IANA) Uniform Resource Identifier (URI) Parameter 439 Registry for the Session Initiation Protocol (SIP)", BCP 440 99, RFC 3969, December 2004. 442 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 443 Specifications: ABNF", STD 68, RFC 5234, January 2008. 445 Appendix A. 3GPP Examples 447 A.1. General 449 This section contains example call flows based on 3GPP usage of the 450 SIP URI 'iotl' parameter. 452 A.2. The UE registers via P-CSCF 454 The Visited Proxy (P-CSCF) adds the iotl value 'homeB-visitedB' to 455 the Path header field of the REGISTER request, to be used for 456 terminating routing towards Alice. The Home Proxy (S-CSCF) adds the 457 iotl value 'visitedA-homeA' to the Service-Route header field, to be 458 used for originating initial/stand-alone requests from Alice. 460 Visited Proxy Visited Proxy Home Proxy Home Proxy 461 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 462 | | | | | 463 | REGISTER F1 | | | | 464 |--------------->| REGISTER F2 | | | 465 | |--------------->| REGISTER F3 | | 466 | | |--------------->| REGISTER F4 | 467 | | | |--------------->| 468 | | | | | 469 | | | | 200 (OK) F5 | 470 | | | |<---------------| 471 | | | 200 (OK) F6 | | 472 | | |<---------------| | 473 | | 200 (OK) F7 | | | 474 | |<---------------| | | 475 | 200 (OK) F8 | | | | 476 |<---------------| | | | 478 F1 REGISTER Alice -> P-CSCF 479 REGISTER sip:registrar.home1.net SIP/2.0 481 F2 REGISTER P-CSCF -> IBCF-V 482 REGISTER sip:registrar.home1.net SIP/2.0 483 Path: 485 F3 REGISTER IBCF-V -> IBCF-H 486 REGISTER sip:registrar.home1.net SIP/2.0 487 Path: 489 F4 REGISTER IBCF-H -> S-CSCF 490 REGISTER sip:registrar.home1.net SIP/2.0 491 Path: 493 F5 200 OK S-CSCF -> IBCF-H 494 200 OK 495 Path: 496 Service-Route: 498 F6 200 OK IBCF-H -> IBCF-V 499 200 OK 500 Path: 501 Service-Route: 503 F7 200 OK IBCF-V -> P-CSCF 504 200 OK 505 Path: 506 Service-Route: 508 F8 200 OK P-CSCF -> Alice 509 200 OK 510 Path: 511 Service-Route: 513 Figure 2: The UE registers via P-CSCF 515 A.3. Originating IMS call 517 In the originating INVITE request from Alice, the iotl value 518 'visitedA-homeA', received in the Service-Route header field during 519 registration, is added to the Route header field representing the 520 Home Proxy S-CSCF, to indicate the traffic leg type between the 521 Visited Proxy P-CSCF and the Home Proxy S-CSCF. 523 Visited Proxy Visited Proxy Home Proxy Home Proxy 524 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 525 | | | | | 526 | INVITE F1 | | | | 527 |--------------->| INVITE F2 | | | 528 | |--------------->| INVITE F3 | | 529 | | |--------------->| INVITE F4 | 530 | | | |--------------->| 531 | | | | | 532 | | | | 180 F5 | 533 | | | 180 F6 |<---------------| 534 | | 180 F7 |<---------------| | 535 | 180 F8 |<---------------| | | 536 |<---------------| | | | 537 | | | | | 539 F1 INVITE Alice -> P-CSCF 540 INVITE sip:Bob@homeB.net SIP/2.0 541 Route: , 543 F2 INVITE P-CSCF -> IBCF-V 544 INVITE sip:Bob@homeB.net SIP/2.0 545 Route: , 547 F3 INVITE IBCF-V -> IBCF-H 548 INVITE sip:Bob@homeB.net SIP/2.0 549 Route: , 551 F4 INVITE IBCF-H -> S-CSCF 552 INVITE sip:Bob@homeB.net SIP/2.0 553 Route: 555 Figure 3: Originating IMS call 557 A.4. Terminating IMS call 559 In the terminating INVITE request towards Alice, the iotl value 560 'homeB-visitedB', provided to the Home Proxy S-CSCF during 561 registration, is added to the Route header field representing the 562 Visited Proxy P-CSCF, to indicate the traffic leg type between the 563 Home Proxy S-CSCF and the Visited Proxy P-CSCF. 565 Home Proxy Home Proxy Visited Proxy Visited Proxy 566 S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob 567 | | | | | 568 | INVITE F1 | | | | 569 |--------------->| INVITE F2 | | | 570 | |--------------->| INVITE F3 | | 571 | | |--------------->| INVITE F4 | 572 | | | |--------------->| 573 | | | | | 574 | | | | 180 F5 | 575 | | | 180 F6 |<---------------| 576 | | 180 F7 |<---------------| | 577 | 180 F8 |<---------------| | | 578 |<---------------| | | | 579 | | | | | 581 F1 INVITE S-CSCF -> IBCF-H 582 INVITE sip:Bob@visitedB.net SIP/2.0 583 Route: , IBCF-V 586 INVITE sip:Bob@visitedB.net SIP/2.0 587 Route: , P-CSCF 590 INVITE sip:Bob@visitedB.net SIP/2.0 591 Route: Bob 594 INVITE sip:Bob@visitedB.net SIP/2.0 596 Figure 4: Terminating IMS call 598 A.5. Call between originating home and terminating home network 600 The S-CSCF of the originating home network adds the iotl value 601 'homeA-homeB' in the Request-URI of the INVITE, sent towards the 602 S-CSCF of the terminating network, to indicate the traffic leg type 603 between the S-CSCFs. 605 Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy 606 S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B 607 | | | | | 608 | INVITE F1 | | | | 609 |--------------->| INVITE F2 | | | 610 | |--------------->| INVITE F3 | | 611 | | |--------------->| INVITE F4 | 612 | | | |--------------->| 613 | | | | | 614 | | | | 180 F5 | 615 | | | 180 F6 |<---------------| 616 | | 180 F7 |<---------------| | 617 | 180 F8 |<---------------| | | 618 |<---------------| | | | 619 | | | | | 621 F1 INVITE S-CSCF-A -> IBCF-A 622 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 624 F2 INVITE IBCF-a -> IBCF-B 625 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 627 F3 INVITE IBCF-B -> I-CSCF-B 628 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 630 F4 INVITE I-CSCF-B -> S-CSCF-B 631 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 633 Figure 5: Call between originating home and terminating home network 635 Authors' Addresses 637 Christer Holmberg 638 Ericsson 639 Hirsalantie 11 640 Jorvas 02420 641 Finland 643 Email: christer.holmberg@ericsson.com 644 Jan Holm 645 Ericsson 646 Kistavagen 25 647 Stockholm16480 648 Sweden 650 Email: jan.holm@ericsson.com 652 Roland Jesske 653 Deutsche Telekom 654 Heinrich-Hertz-Strasse 3-7 655 Darmstadt 64307 656 Germany 658 Phone: +4961515812766 659 Email: r.jesske@telekom.de 661 Martin Dolly 662 ATT 663 718 Clairmore Ave 664 Lanoka Harbor 08734 665 USA 667 Email: md3135@att.com