idnits 2.17.1 draft-holmberg-dispatch-iotl-03.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 (December 16, 2014) is 3413 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 391, 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: June 19, 2015 R. Jesske 6 Deutsche Telekom 7 M. Dolly 8 ATT 9 December 16, 2014 11 3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic 12 Leg parameter 13 draft-holmberg-dispatch-iotl-03.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'. The parameter 29 can be used in a SIP URI to indicate that the entity associated with 30 the address, or an entity responsible for the host part of the 31 address, represents the end of a specific traffic leg (or multiple 32 traffic legs). 34 The SIP URI 'iotl' parameter defined in this document is only 35 applicable to 3GPP networks. The usage of the parameter within other 36 types of networks is undefined. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on June 19, 2015. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 73 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3.2. Originating roaming call . . . . . . . . . . . . . . . . 5 77 3.3. Terminating roaming call . . . . . . . . . . . . . . . . 5 78 3.4. Originating home to terminating home call . . . . . . . . 5 79 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 5. iotl SIP URI parameter . . . . . . . . . . . . . . . . . . . 5 81 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 82 5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 7 83 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 7 84 5.2.2. homeA-homeB . . . . . . . . . . . . . . . . . . . . . 7 85 5.2.3. homeB-visitedB . . . . . . . . . . . . . . . . . . . 7 86 5.2.4. visitedA-homeA . . . . . . . . . . . . . . . . . . . 7 87 5.2.5. homeA-visitedA . . . . . . . . . . . . . . . . . . . 7 88 5.2.6. visitedA-homeB . . . . . . . . . . . . . . . . . . . 8 89 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 90 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 91 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 94 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 95 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 96 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 97 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 98 11.2. Informative References . . . . . . . . . . . . . . . . . 11 99 Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 11 100 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 101 A.2. The UE registers via P-CSCF . . . . . . . . . . . . . . . 11 102 A.3. Originating IMS call . . . . . . . . . . . . . . . . . . 12 103 A.4. Terminating IMS call . . . . . . . . . . . . . . . . . . 13 104 A.5. Call between originating home and terminating home 105 network . . . . . . . . . . . . . . . . . . . . . . . . . 14 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 108 1. Introduction 110 In a 3rd-Generation Partnership Project (3GPP) network, an end user 111 device can be attached (e.g. using a radio access network) to its own 112 operator network (home network) [TS.3GPP.24.229], or to another 113 operator's network (visited network) [TS.3GPP.24.229]. In the latter 114 case the user is referred to as a roaming user. 116 3GPP operator networks are often not connected directly to each 117 other. Instead, there might be intermediate networks, referred to as 118 3GPP transit networks, between them. Such transit network act on SIP 119 level or on IP level. 121 In 3GPP networks, the signalling path between a calling user and a 122 called user can be partioned into segments, referred to as traffic 123 legs. Each traffic leg may span networks belonging to different 124 operators, and will have its own characteristics that can be 125 different from other traffic legs in the same call. The 126 directionality in traffic legs relates to a SIP request creating a 127 dialogue and stand-alone SIP request. A traffic leg might be 128 associated with multiple SIP dialogs, e.g. in case a B2BUA which 129 modifies the SIP dialog identifier is located within the traffic leg. 131 The traffic leg information can be used by intermediary entities to 132 make policy decisions, related to e.g. media anchoring, signalling 133 policy, insertion of media functions (e.g. transcoder) and charging. 135 The figure below shows two users (Alice and Bob) and the different 136 type of networks that the signaling might traverse. The signalling 137 path can be divided into multiple traffic legs, and the type of 138 traffic legs depends on how the signalling is routed. 140 Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob 141 Home + + + + + Home 142 + ++++++++++++++++++ + + 143 + + + 144 + + + 145 + +++++++++++++++++++++++ + 146 + + + + 147 Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob 148 Visited Visited 150 Figure 1: 3GPP operator network roaming roles 152 ORIG HNW = Originating 3GPP Home Network 154 TERM HNW = Terminating 3GPP Home Network 156 ORIG VNW = Originating 3GPP Visited Network 158 TERM VNW = Terminating 3GPP Visited Network 160 TRANSIT NW = 3GPP Transit Network 162 In Figure 1 Alice is a user initiating communication with Bob, and: 164 Alice is attached to an originating network, which is either the home 165 network of Alice, or a visited network (in case Alice is roaming). 166 In both cases any originating service is provided by the home network 167 of Alice. 169 Bob is attached to a terminating network, which is either the home 170 network of Bob, or a visited network (in case Bob is roaming). In 171 both cases any terminating service is provided by the home network of 172 Bob. 174 A transit network, providing transit functions (e.g. translation of 175 free phone numbers), may be included between the originating and 176 terminating networks and between visited and home networks. 178 This document defines a new SIP URI parameter [RFC3261], 'iotl'. The 179 parameter can be used in a SIP URI to indicate that the entity 180 associated with the address, or an entity responsible for the host 181 part of the address, represents the end of a specific traffic leg (or 182 multiple traffic legs). 184 The SIP URI 'iotl' parameter defined in this document is only 185 applicable to 3GPP networks. The usage of the parameter within other 186 types of networks is undefined. 188 2. Applicability 190 The SIP URI 'iotl' parameter defined in this document is only 191 applicable to 3GPP networks. The usage of the parameter within other 192 types of networks is undefined. 194 3. Use-cases 196 3.1. General 198 This section describes examples of different types of traffic legs in 199 3GPP networks. 201 3.2. Originating roaming call 203 In this case, Alice is located in a visited network. When Alice 204 sends the initial SIP INVITE request for a call, one traffic leg 205 (referred to as the 'visitedA-homeA' traffic leg) represents the 206 signalling path between the UA of Alice and the home S-CSCF of Alice. 208 3.3. Terminating roaming call 210 In this case, Bob is located in a visited network. When the home 211 S-CSCF of Bob forwards the initial SIP INVITE request for a call 212 towards Bob, one traffic leg (referred to as the 'homeB-visitedB' 213 traffic leg) represents the signalling path between the home S-CSCF 214 of Bob and the UA of Bob. 216 3.4. Originating home to terminating home call 218 In this case, the home S-CSCF of Alice forwards the initial SIP 219 INVITE request towards the home S-CSCF of Bob. The signalling path 220 between the S-CSCFs represents one traffic leg (referred to as the 221 'homeA-homeB' traffic leg). 223 4. Conventions 225 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 226 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 227 document are to be interpreted as described in [RFC2119]. 229 5. iotl SIP URI parameter 231 5.1. Usage 233 As specified in [RFC3261], when a SIP entity inserts a SIP URI in an 234 initial request for a dialog, or in a stand-alone request, the SIP 235 URI will be used to route the request to another SIP entity, 236 addressed by the SIP URI, or to a SIP entity responsible for the host 237 part of the SIP URI (e.g. a SIP registrar). If such entity 238 represents the end of one or more traffic legs, the SIP entity 239 inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP 240 URI, to indicate the type(s) of traffic leg. Each parameter value 241 indicates a type of traffic leg. 243 For routing of a SIP request, a SIP entity can add the 'iotl' 244 parameter to the SIP URI of the Request-URI [RFC3261], or to the SIP 245 URI of a Route header field [RFC3261], of an initial request for a 246 dialog, or of an stand-alone request. 248 When a SIP entity receives an initial request for a dialog, or a 249 stand-alone request, which contains one or more SIP URI 'iotl' 250 parameters, it identifies the type of traffic leg in the following 251 way: 253 o If the SIP request contains a single Route header field containing 254 a SIP URI with an 'iotl' parameter, that parameter identifies the 255 type of traffic leg; 257 o If the SIP request contains multiple Route header fields 258 containing a SIP URI with an 'iotl' parameter, the 'iotl' 259 parameter associated with the SIP URI of the topmost Route header 260 field (or, if the SIP URI of the topmost Route header field does 261 not contain an 'iotl' parameter, the SIP URI of the Route header 262 field closest to the topmost) identifies the type of traffic leg; 263 or 265 o If a SIP request contains an 'iotl' parameter only in the Request- 266 URI SIP URI, the 'iotl' parameter identifies the type of traffic 267 leg. 269 During SIP registration [RFC3261], entities can add the 'iotl' 270 parameter to the SIP URI of a Path or Service-Route header field, if 271 the entity is aware that SIP URI will be used to indicate the end of 272 a specific traffic leg for initial requests for dialogs, or stand- 273 alone requests, sent on the registration path. 275 An entity that understands the 'iotl' parameter MUST NOT, from a SIP 276 request, remove 'iotl' parameters from SIP URIs associated with other 277 entities, unless the entity has means to determine that the 'iotl' 278 parameter does not represent a valid traffic leg. 280 This document does not specify the usage of the 'iotl' parameter 281 within a SIP URI of a Record-Route header field [RFC3261]. 283 5.2. Parameter Values 285 5.2.1. General 287 This section describes the SIP URI 'iotl' parameter values defined in 288 this specification. 290 5.2.2. homeA-homeB 292 This value indicates that a SIP entity responsible for the host part 293 of the SIP URI associated with the parameter represents the end of a 294 traffic leg between the home network (originating) of the calling 295 user and the home network (terminating) of the called user. 297 In 3GPP, this traffic leg is between two S-CSCFs. 299 5.2.3. homeB-visitedB 301 This value indicates that the SIP entity addressed by the SIP URI 302 associated with the parameter represents the end of a traffic leg 303 between the home network (terminating) of the called user and the 304 visited network (terminating) in which the called user is located. 306 In 3GPP, this traffic leg is between the home S-CSCF and the UE of 307 the called user, or between the Service Centralization and Continuity 308 Application Server (SCC AS) in the home network of the called user 309 and Access Transfer Control Function (ATCF) in the visited network of 310 the called user. 312 5.2.4. visitedA-homeA 314 This value indicates that a SIP entity responsible for the host part 315 of the SIP URI associated with the parameter represents the end of a 316 traffic leg between the visited network (originating) in which the 317 calling user is located and the home network (originating) of the 318 calling user. 320 In 3GPP, this traffic leg is between the UE and the home S-CSCF of 321 the calling user, or between the P-CSCF in the visited network, 322 serving the calling user, and the home S-CSCF of the calling user. 324 5.2.5. homeA-visitedA 326 This value indicates that the SIP entity addressed by the SIP URI 327 associated with the parameter represents the end of a traffic leg 328 between the home network (originating) and the visited network 329 (originating) in which the calling user is located. 331 In 3GPP, this traffic leg is between the home S-CSCF of the calling 332 user and the Transit and Roaming Function (TRF) [3GPP TS 24.229] 333 serving the calling user, and exists in scenarios where the home 334 S-CSCF of the calling user forwards a request back to the visited 335 network where the UE of the calling user is located. An example of 336 this is when the Roaming Architecture for Voice over IMS with Local 337 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 339 5.2.6. visitedA-homeB 341 This value indicates that a SIP entity responsible for the host part 342 of the SIP URI associated with the parameter represents the end of a 343 traffic leg between the visited network (originating) of the calling 344 user and the home network (terminating) of the called user. 346 In 3GPP, this traffic leg is between the Transit and Roaming Function 347 (TRF) [3GPP TS 24.229] serving the calling user and the home S-CSCF 348 of the called user, and exists in scenarios where a request is 349 forwarded from the visited network where the calling user is located 350 directly to the home S-CSCF of the called user. An example of this 351 is when the Roaming Architecture for Voice over IMS with Local 352 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 354 6. Syntax 356 6.1. General 358 This section defines the ABNF for the 'iotl' SIP URI parameter. The 359 ABNF defined in this specification is conformant to RFC 5234 360 [RFC5234]. 362 6.2. ABNF 364 The ABNF [RFC5234] grammar for the role SIP URI parameter is: 366 uri-parameter =/ iotl-param 367 iotl-param = iotl-tag "=" iotl-value ["." iotl-value] 368 iotl-tag = "iotl" 369 iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" 370 / "homeA-visitedA" /" visitedA-homeB" / other-iotl 371 other-iotl = 1*iotl-char 372 iotl-char = alphanum / "-" 373 ;; alphanum defined in RFC 3261 375 7. Security Considerations 377 The information SHOULD only be used for making policy decisions based 378 on the role by nodes within the same trust domain [RFC3325]. In 379 addition, there MUST exist an agreement between the operators for 380 usage of the roaming role information. 382 8. IANA Considerations 384 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 385 document.] This specification adds one new value to the IANA 386 registration in the "SIP/SIPS URI Parameters" registry as defined in 387 [RFC3969]. 389 Parameter Name Predefined Values Reference 390 ____________________________________________ 391 iotl Yes [This RFC] 393 9. Acknowledgments 395 The authors wish to thank everyone in the 3GPP community that gave 396 comments on the initial version of this document. 398 10. Change Log 400 [RFC EDITOR NOTE: Please remove this section when publishing] 402 draft-holmberg-dispatch-iotl-02 404 o Change based on comments from Richard Barnes: 406 o - 3GPP scope text modified. 408 o - Reference to 3GPP TS 24.229 added. 410 o - Reference to RFC 3325 added, and incorporated into the Security 411 Considerations. 413 o - 'iotl' selection procedure made into a bullet list. 415 draft-holmberg-dispatch-iotl-01 417 o Scope the SIP URI 'iotl' parameter to 3GPP, based on decision at 418 IETF#90: 420 o - Document name changed. 422 o - Clarified that usage of the parameter is only defined within 423 3GPP networks. 425 draft-holmberg-dispatch-iotl-00 427 o Added text on how to identify the traffic leg type when SIP-URIs 428 of multiple Route header fields and/or the Request-URI contain an 429 'iotl' parameter. 431 o Clarify that a traffic leg might span over multiple SIP dialogs. 433 o Added text saying that entities supporting the 'iotl' parameter 434 must not remove a parameter from a request, if the parameter is 435 associated with a SIP URI belonging to another entity. 437 o Modified ABNF, in order to allow multiple iotl values for a single 438 URI. 440 o In IANA section, changed indication that predefined values exist. 442 o Example call flows added. 444 11. References 446 11.1. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 452 A., Peterson, J., Sparks, R., Handley, M., and E. 453 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 454 June 2002. 456 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 457 (IANA) Uniform Resource Identifier (URI) Parameter 458 Registry for the Session Initiation Protocol (SIP)", BCP 459 99, RFC 3969, December 2004. 461 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 462 Specifications: ABNF", STD 68, RFC 5234, January 2008. 464 [TS.3GPP.24.229] 465 3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229 466 12.6.0, September 2014. 468 11.2. Informative References 470 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 471 Extensions to the Session Initiation Protocol (SIP) for 472 Asserted Identity within Trusted Networks", RFC 3325, 473 November 2002. 475 Appendix A. 3GPP Examples 477 A.1. General 479 This section contains example call flows based on 3GPP usage of the 480 SIP URI 'iotl' parameter. 482 A.2. The UE registers via P-CSCF 484 The Visited Proxy (P-CSCF) adds the iotl value 'homeB-visitedB' to 485 the Path header field of the REGISTER request, to be used for 486 terminating routing towards Alice. The Home Proxy (S-CSCF) adds the 487 iotl value 'visitedA-homeA' to the Service-Route header field, to be 488 used for originating initial/stand-alone requests from Alice. 490 Visited Proxy Visited Proxy Home Proxy Home Proxy 491 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 492 | | | | | 493 | REGISTER F1 | | | | 494 |--------------->| REGISTER F2 | | | 495 | |--------------->| REGISTER F3 | | 496 | | |--------------->| REGISTER F4 | 497 | | | |--------------->| 498 | | | | | 499 | | | | 200 (OK) F5 | 500 | | | |<---------------| 501 | | | 200 (OK) F6 | | 502 | | |<---------------| | 503 | | 200 (OK) F7 | | | 504 | |<---------------| | | 505 | 200 (OK) F8 | | | | 506 |<---------------| | | | 508 F1 REGISTER Alice -> P-CSCF 509 REGISTER sip:registrar.home1.net SIP/2.0 511 F2 REGISTER P-CSCF -> IBCF-V 512 REGISTER sip:registrar.home1.net SIP/2.0 513 Path: 514 F3 REGISTER IBCF-V -> IBCF-H 515 REGISTER sip:registrar.home1.net SIP/2.0 516 Path: 518 F4 REGISTER IBCF-H -> S-CSCF 519 REGISTER sip:registrar.home1.net SIP/2.0 520 Path: 522 F5 200 OK S-CSCF -> IBCF-H 523 200 OK 524 Path: 525 Service-Route: 527 F6 200 OK IBCF-H -> IBCF-V 528 200 OK 529 Path: 530 Service-Route: 532 F7 200 OK IBCF-V -> P-CSCF 533 200 OK 534 Path: 535 Service-Route: 537 F8 200 OK P-CSCF -> Alice 538 200 OK 539 Path: 540 Service-Route: 542 Figure 2: The UE registers via P-CSCF 544 A.3. Originating IMS call 546 In the originating INVITE request from Alice, the iotl value 547 'visitedA-homeA', received in the Service-Route header field during 548 registration, is added to the Route header field representing the 549 Home Proxy S-CSCF, to indicate the traffic leg type between the 550 Visited Proxy P-CSCF and the Home Proxy S-CSCF. 552 Visited Proxy Visited Proxy Home Proxy Home Proxy 553 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 554 | | | | | 555 | INVITE F1 | | | | 556 |--------------->| INVITE F2 | | | 557 | |--------------->| INVITE F3 | | 558 | | |--------------->| INVITE F4 | 559 | | | |--------------->| 560 | | | | | 561 | | | | 180 F5 | 562 | | | 180 F6 |<---------------| 563 | | 180 F7 |<---------------| | 564 | 180 F8 |<---------------| | | 565 |<---------------| | | | 566 | | | | | 568 F1 INVITE Alice -> P-CSCF 569 INVITE sip:Bob@homeB.net SIP/2.0 570 Route: , 572 F2 INVITE P-CSCF -> IBCF-V 573 INVITE sip:Bob@homeB.net SIP/2.0 574 Route: , 576 F3 INVITE IBCF-V -> IBCF-H 577 INVITE sip:Bob@homeB.net SIP/2.0 578 Route: , 580 F4 INVITE IBCF-H -> S-CSCF 581 INVITE sip:Bob@homeB.net SIP/2.0 582 Route: 584 Figure 3: Originating IMS call 586 A.4. Terminating IMS call 588 In the terminating INVITE request towards Alice, the iotl value 589 'homeB-visitedB', provided to the Home Proxy S-CSCF during 590 registration, is added to the Route header field representing the 591 Visited Proxy P-CSCF, to indicate the traffic leg type between the 592 Home Proxy S-CSCF and the Visited Proxy P-CSCF. 594 Home Proxy Home Proxy Visited Proxy Visited Proxy 595 S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob 596 | | | | | 597 | INVITE F1 | | | | 598 |--------------->| INVITE F2 | | | 599 | |--------------->| INVITE F3 | | 600 | | |--------------->| INVITE F4 | 601 | | | |--------------->| 602 | | | | | 603 | | | | 180 F5 | 604 | | | 180 F6 |<---------------| 605 | | 180 F7 |<---------------| | 606 | 180 F8 |<---------------| | | 607 |<---------------| | | | 608 | | | | | 610 F1 INVITE S-CSCF -> IBCF-H 611 INVITE sip:Bob@visitedB.net SIP/2.0 612 Route: , IBCF-V 615 INVITE sip:Bob@visitedB.net SIP/2.0 616 Route: , P-CSCF 619 INVITE sip:Bob@visitedB.net SIP/2.0 620 Route: Bob 623 INVITE sip:Bob@visitedB.net SIP/2.0 625 Figure 4: Terminating IMS call 627 A.5. Call between originating home and terminating home network 629 The S-CSCF of the originating home network adds the iotl value 630 'homeA-homeB' in the Request-URI of the INVITE, sent towards the 631 S-CSCF of the terminating network, to indicate the traffic leg type 632 between the S-CSCFs. 634 Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy 635 S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B 636 | | | | | 637 | INVITE F1 | | | | 638 |--------------->| INVITE F2 | | | 639 | |--------------->| INVITE F3 | | 640 | | |--------------->| INVITE F4 | 641 | | | |--------------->| 642 | | | | | 643 | | | | 180 F5 | 644 | | | 180 F6 |<---------------| 645 | | 180 F7 |<---------------| | 646 | 180 F8 |<---------------| | | 647 |<---------------| | | | 648 | | | | | 650 F1 INVITE S-CSCF-A -> IBCF-A 651 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 653 F2 INVITE IBCF-a -> IBCF-B 654 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 656 F3 INVITE IBCF-B -> I-CSCF-B 657 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 659 F4 INVITE I-CSCF-B -> S-CSCF-B 660 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 662 Figure 5: Call between originating home and terminating home network 664 Authors' Addresses 666 Christer Holmberg 667 Ericsson 668 Hirsalantie 11 669 Jorvas 02420 670 Finland 672 Email: christer.holmberg@ericsson.com 673 Jan Holm 674 Ericsson 675 Kistavagen 25 676 Stockholm16480 677 Sweden 679 Email: jan.holm@ericsson.com 681 Roland Jesske 682 Deutsche Telekom 683 Heinrich-Hertz-Strasse 3-7 684 Darmstadt 64307 685 Germany 687 Phone: +4961515812766 688 Email: r.jesske@telekom.de 690 Martin Dolly 691 ATT 692 718 Clairmore Ave 693 Lanoka Harbor 08734 694 USA 696 Email: md3135@att.com