idnits 2.17.1 draft-holmberg-dispatch-iotl-04.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 (January 8, 2015) is 3367 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: July 12, 2015 R. Jesske 6 Deutsche Telekom 7 M. Dolly 8 ATT 9 January 8, 2015 11 3rd-Generation Partnership Project (3GPP) SIP URI Inter Operator Traffic 12 Leg parameter 13 draft-holmberg-dispatch-iotl-04.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 July 12, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 90 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 91 10. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 94 11.2. Informative References . . . . . . . . . . . . . . . . . 12 95 Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 12 96 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12 97 A.2. The UE registers via P-CSCF . . . . . . . . . . . . . . . 12 98 A.3. Originating IMS call . . . . . . . . . . . . . . . . . . 13 99 A.4. Terminating IMS call . . . . . . . . . . . . . . . . . . 14 100 A.5. Call between originating home and terminating home 101 network . . . . . . . . . . . . . . . . . . . . . . . . . 15 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 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'. The 174 parameter can be used in a SIP URI to indicate that the entity 175 associated with the address, or an entity responsible for the host 176 part of the address, represents the end of a specific traffic leg (or 177 multiple traffic legs). 179 SIP entities that do not support the SIP URI 'iotl' parameter will 180 simply ignore it, if received, as defined in [RFC3261]. 182 The SIP URI 'iotl' parameter defined in this document has known uses 183 in 3GPP networks. Usage in other networks is also possible. 185 2. Applicability 187 The SIP URI 'iotl' parameter defined in this document has known uses 188 in 3GPP networks. Usage in other networks is also possible. 190 3. Use-cases 192 3.1. General 194 This section describes examples of different types of traffic legs in 195 3GPP networks. 197 3.2. Originating roaming call 199 In this case, Alice is located in a visited network. When Alice 200 sends the initial SIP INVITE request for a call, one traffic leg 201 (referred to as the 'visitedA-homeA' traffic leg) represents the 202 signalling path between the UA of Alice and the home S-CSCF [3GPP TS 203 24.229] 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. SIP entities can add the 244 'iotl' parameter to the SIP URI of a Path header field [RFC3327] or a 245 Service-Route header field [RFC3608], in order for the parameter to 246 later occur in a Route header field. 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 As defined in [RFC3261], a SIP entity must not modify remove uri 276 parameters from SIP URIs associated with other entities. This also 277 applies to the 'iotl' parameter. 279 5.2. Parameter Values 281 5.2.1. General 283 This section describes the SIP URI 'iotl' parameter values defined in 284 this specification. 286 5.2.2. homeA-homeB 288 This value indicates that a SIP entity responsible for the host part 289 of the SIP URI associated with the parameter represents the end of a 290 traffic leg between the home network (originating) of the calling 291 user and the home network (terminating) of the called user. 293 In 3GPP, this traffic leg is between two S-CSCFs. 295 5.2.3. homeB-visitedB 297 This value indicates that the SIP entity addressed by the SIP URI 298 associated with the parameter represents the end of a traffic leg 299 between the home network (terminating) of the called user and the 300 visited network (terminating) in which the called user is located. 302 In 3GPP, this traffic leg is between the home S-CSCF and the UE of 303 the called user, or between the Service Centralization and Continuity 304 Application Server (SCC AS) in the home network of the called user 305 and Access Transfer Control Function (ATCF) in the visited network of 306 the called user. 308 5.2.4. visitedA-homeA 310 This value indicates that a SIP entity responsible for the host part 311 of the SIP URI associated with the parameter represents the end of a 312 traffic leg between the visited network (originating) in which the 313 calling user is located and the home network (originating) of the 314 calling user. 316 In 3GPP, this traffic leg is between the UE and the home S-CSCF of 317 the calling user, or between the P-CSCF in the visited network, 318 serving the calling user, and the home S-CSCF of the calling user. 320 5.2.5. homeA-visitedA 322 This value indicates that the SIP entity addressed by the SIP URI 323 associated with the parameter represents the end of a traffic leg 324 between the home network (originating) and the visited network 325 (originating) in which the calling user is located. 327 In 3GPP, this traffic leg is between the home S-CSCF of the calling 328 user and the Transit and Roaming Function (TRF) [3GPP TS 24.229] 329 serving the calling user, and exists in scenarios where the home 330 S-CSCF of the calling user forwards a request back to the visited 331 network where the UE of the calling user is located. An example of 332 this is when the Roaming Architecture for Voice over IMS with Local 333 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 335 5.2.6. visitedA-homeB 337 This value indicates that a SIP entity responsible for the host part 338 of the SIP URI associated with the parameter represents the end of a 339 traffic leg between the visited network (originating) of the calling 340 user and the home network (terminating) of the called user. 342 In 3GPP, this traffic leg is between the Transit and Roaming Function 343 (TRF) [3GPP TS 24.229] serving the calling user and the home S-CSCF 344 of the called user, and exists in scenarios where a request is 345 forwarded from the visited network where the calling user is located 346 directly to the home S-CSCF of the called user. An example of this 347 is when the Roaming Architecture for Voice over IMS with Local 348 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 350 6. Syntax 352 6.1. General 354 This section defines the ABNF for the 'iotl' SIP URI parameter. The 355 ABNF defined in this specification is conformant to RFC 5234 356 [RFC5234]. 358 This specification does not create an IANA registry for 'iotl' 359 parameter values. A registry should be considered if new parameter 360 values are defined in the future. 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, and contributed 397 with comments and suggestion during the work. A special thanks to 398 Paul Kyziwat, Dale Worley and Michael Hammer. Robert Sparks 399 performed the Gen-ARTreview of the draft. 401 10. Change Log 403 [RFC EDITOR NOTE: Please remove this section when publishing] 405 draft-holmberg-dispatch-iotl-03 407 o Change based on Gen-ART review from Robert Sparks: 409 o - Removed text saying that the mechanism is scoped for 3GPP 410 networks only. 412 o - Clarify that entities that do not support the parameter will 413 ignore it. 415 o - Clarify that the draft does not create an IANA registry for 416 parameter values. 418 o - Remove sentence regarding directionality. 420 o - Reference to RFC 3327 added. 422 o - Reference to RFC 3608 added. 424 o - 'dialogue' -> 'dialog'. 426 o Change based on Ops-ART review from Nevil Brownlee: 428 o - Reference to RFC 3261 added to 'B2BUA'. 430 o - Reference to 3GPP TS 24.229 added for 'S-CSCF'. 432 draft-holmberg-dispatch-iotl-02 434 o Change based on comments from Richard Barnes: 436 o - 3GPP scope text modified. 438 o - Reference to 3GPP TS 24.229 added. 440 o - Reference to RFC 3325 added, and incorporated into the Security 441 Considerations. 443 o - 'iotl' selection procedure made into a bullet list. 445 draft-holmberg-dispatch-iotl-01 447 o Scope the SIP URI 'iotl' parameter to 3GPP, based on decision at 448 IETF#90: 450 o - Document name changed. 452 o - Clarified that usage of the parameter is only defined within 453 3GPP networks. 455 draft-holmberg-dispatch-iotl-00 457 o Added text on how to identify the traffic leg type when SIP-URIs 458 of multiple Route header fields and/or the Request-URI contain an 459 'iotl' parameter. 461 o Clarify that a traffic leg might span over multiple SIP dialogs. 463 o Added text saying that entities supporting the 'iotl' parameter 464 must not remove a parameter from a request, if the parameter is 465 associated with a SIP URI belonging to another entity. 467 o Modified ABNF, in order to allow multiple iotl values for a single 468 URI. 470 o In IANA section, changed indication that predefined values exist. 472 o Example call flows added. 474 11. References 476 11.1. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, March 1997. 481 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 482 A., Peterson, J., Sparks, R., Handley, M., and E. 483 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 484 June 2002. 486 [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 487 (SIP) Extension Header Field for Registering Non-Adjacent 488 Contacts", RFC 3327, December 2002. 490 [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol 491 (SIP) Extension Header Field for Service Route Discovery 492 During Registration", RFC 3608, October 2003. 494 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 495 (IANA) Uniform Resource Identifier (URI) Parameter 496 Registry for the Session Initiation Protocol (SIP)", BCP 497 99, RFC 3969, December 2004. 499 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 500 Specifications: ABNF", STD 68, RFC 5234, January 2008. 502 [TS.3GPP.24.229] 503 3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229 504 12.6.0, September 2014. 506 11.2. Informative References 508 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 509 Extensions to the Session Initiation Protocol (SIP) for 510 Asserted Identity within Trusted Networks", RFC 3325, 511 November 2002. 513 Appendix A. 3GPP Examples 515 A.1. General 517 This section contains example call flows based on 3GPP usage of the 518 SIP URI 'iotl' parameter. 520 A.2. The UE registers via P-CSCF 522 The Visited Proxy (P-CSCF) adds the iotl value 'homeB-visitedB' to 523 the Path header field of the REGISTER request, to be used for 524 terminating routing towards Alice. The Home Proxy (S-CSCF) adds the 525 iotl value 'visitedA-homeA' to the Service-Route header field, to be 526 used for originating initial/stand-alone requests from Alice. 528 Visited Proxy Visited Proxy Home Proxy Home Proxy 529 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 530 | | | | | 531 | REGISTER F1 | | | | 532 |--------------->| REGISTER F2 | | | 533 | |--------------->| REGISTER F3 | | 534 | | |--------------->| REGISTER F4 | 535 | | | |--------------->| 536 | | | | | 537 | | | | 200 (OK) F5 | 538 | | | |<---------------| 539 | | | 200 (OK) F6 | | 540 | | |<---------------| | 541 | | 200 (OK) F7 | | | 542 | |<---------------| | | 543 | 200 (OK) F8 | | | | 544 |<---------------| | | | 546 F1 REGISTER Alice -> P-CSCF 547 REGISTER sip:registrar.home1.net SIP/2.0 549 F2 REGISTER P-CSCF -> IBCF-V 550 REGISTER sip:registrar.home1.net SIP/2.0 551 Path: 552 F3 REGISTER IBCF-V -> IBCF-H 553 REGISTER sip:registrar.home1.net SIP/2.0 554 Path: 556 F4 REGISTER IBCF-H -> S-CSCF 557 REGISTER sip:registrar.home1.net SIP/2.0 558 Path: 560 F5 200 OK S-CSCF -> IBCF-H 561 200 OK 562 Path: 563 Service-Route: 565 F6 200 OK IBCF-H -> IBCF-V 566 200 OK 567 Path: 568 Service-Route: 570 F7 200 OK IBCF-V -> P-CSCF 571 200 OK 572 Path: 573 Service-Route: 575 F8 200 OK P-CSCF -> Alice 576 200 OK 577 Path: 578 Service-Route: 580 Figure 2: The UE registers via P-CSCF 582 A.3. Originating IMS call 584 In the originating INVITE request from Alice, the iotl value 585 'visitedA-homeA', received in the Service-Route header field during 586 registration, is added to the Route header field representing the 587 Home Proxy S-CSCF, to indicate the traffic leg type between the 588 Visited Proxy P-CSCF and the Home Proxy S-CSCF. 590 Visited Proxy Visited Proxy Home Proxy Home Proxy 591 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 592 | | | | | 593 | INVITE F1 | | | | 594 |--------------->| INVITE F2 | | | 595 | |--------------->| INVITE F3 | | 596 | | |--------------->| INVITE F4 | 597 | | | |--------------->| 598 | | | | | 599 | | | | 180 F5 | 600 | | | 180 F6 |<---------------| 601 | | 180 F7 |<---------------| | 602 | 180 F8 |<---------------| | | 603 |<---------------| | | | 604 | | | | | 606 F1 INVITE Alice -> P-CSCF 607 INVITE sip:Bob@homeB.net SIP/2.0 608 Route: , 610 F2 INVITE P-CSCF -> IBCF-V 611 INVITE sip:Bob@homeB.net SIP/2.0 612 Route: , 614 F3 INVITE IBCF-V -> IBCF-H 615 INVITE sip:Bob@homeB.net SIP/2.0 616 Route: , 618 F4 INVITE IBCF-H -> S-CSCF 619 INVITE sip:Bob@homeB.net SIP/2.0 620 Route: 622 Figure 3: Originating IMS call 624 A.4. Terminating IMS call 626 In the terminating INVITE request towards Alice, the iotl value 627 'homeB-visitedB', provided to the Home Proxy S-CSCF during 628 registration, is added to the Route header field representing the 629 Visited Proxy P-CSCF, to indicate the traffic leg type between the 630 Home Proxy S-CSCF and the Visited Proxy P-CSCF. 632 Home Proxy Home Proxy Visited Proxy Visited Proxy 633 S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob 634 | | | | | 635 | INVITE F1 | | | | 636 |--------------->| INVITE F2 | | | 637 | |--------------->| INVITE F3 | | 638 | | |--------------->| INVITE F4 | 639 | | | |--------------->| 640 | | | | | 641 | | | | 180 F5 | 642 | | | 180 F6 |<---------------| 643 | | 180 F7 |<---------------| | 644 | 180 F8 |<---------------| | | 645 |<---------------| | | | 646 | | | | | 648 F1 INVITE S-CSCF -> IBCF-H 649 INVITE sip:Bob@visitedB.net SIP/2.0 650 Route: , IBCF-V 653 INVITE sip:Bob@visitedB.net SIP/2.0 654 Route: , P-CSCF 657 INVITE sip:Bob@visitedB.net SIP/2.0 658 Route: Bob 661 INVITE sip:Bob@visitedB.net SIP/2.0 663 Figure 4: Terminating IMS call 665 A.5. Call between originating home and terminating home network 667 The S-CSCF of the originating home network adds the iotl value 668 'homeA-homeB' in the Request-URI of the INVITE, sent towards the 669 S-CSCF of the terminating network, to indicate the traffic leg type 670 between the S-CSCFs. 672 Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy 673 S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B 674 | | | | | 675 | INVITE F1 | | | | 676 |--------------->| INVITE F2 | | | 677 | |--------------->| INVITE F3 | | 678 | | |--------------->| INVITE F4 | 679 | | | |--------------->| 680 | | | | | 681 | | | | 180 F5 | 682 | | | 180 F6 |<---------------| 683 | | 180 F7 |<---------------| | 684 | 180 F8 |<---------------| | | 685 |<---------------| | | | 686 | | | | | 688 F1 INVITE S-CSCF-A -> IBCF-A 689 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 691 F2 INVITE IBCF-a -> IBCF-B 692 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 694 F3 INVITE IBCF-B -> I-CSCF-B 695 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 697 F4 INVITE I-CSCF-B -> S-CSCF-B 698 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 700 Figure 5: Call between originating home and terminating home network 702 Authors' Addresses 704 Christer Holmberg 705 Ericsson 706 Hirsalantie 11 707 Jorvas 02420 708 Finland 710 Email: christer.holmberg@ericsson.com 711 Jan Holm 712 Ericsson 713 Kistavagen 25 714 Stockholm16480 715 Sweden 717 Email: jan.holm@ericsson.com 719 Roland Jesske 720 Deutsche Telekom 721 Heinrich-Hertz-Strasse 3-7 722 Darmstadt 64307 723 Germany 725 Phone: +4961515812766 726 Email: r.jesske@telekom.de 728 Martin Dolly 729 ATT 730 718 Clairmore Ave 731 Lanoka Harbor 08734 732 USA 734 Email: md3135@att.com