idnits 2.17.1 draft-holmberg-dispatch-iotl-01.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 (June 13, 2014) is 3604 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 377, 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: December 15, 2014 R. Jesske 6 Deutsche Telekom 7 M. Dolly 8 ATT 9 June 13, 2014 11 SIP URI Inter Operator Traffic Leg parameter 12 draft-holmberg-dispatch-iotl-01.txt 14 Abstract 16 In telecommunication networks, the signalling path between a calling 17 user and a called user can be partioned into segments, referred to as 18 traffic legs. Each traffic leg may span networks belonging to 19 different operators, and will have its own characteristics that can 20 be different from other traffic legs in the same call. The 21 directionality in traffic legs relates to a SIP request creating a 22 dialogue and stand-alone SIP request. A traffic leg might be 23 associated with multiple SIP dialogs, e.g. in case a B2BUA which 24 modifies the SIP dialog identifier is located within the traffic leg. 26 This document defines a new SIP URI parameter, 'iotl', which can be 27 used in a SIP URI to indicate that the entity associated with the 28 address, or an entity responsible for the host part of the address, 29 represents the end of a specific traffic leg (or multiple traffic 30 legs). 32 The 'iotl' parameter is defined in order to fulfil requirements from 33 the 3rd-Generation Partnership Project (3GPP), but it can also be 34 used in other network environments. 36 Status of This Memo 38 This Internet-Draft is submitted in full conformance with the 39 provisions of BCP 78 and BCP 79. 41 Internet-Drafts are working documents of the Internet Engineering 42 Task Force (IETF). Note that other groups may also distribute 43 working documents as Internet-Drafts. The list of current Internet- 44 Drafts is at http://datatracker.ietf.org/drafts/current/. 46 Internet-Drafts are draft documents valid for a maximum of six months 47 and may be updated, replaced, or obsoleted by other documents at any 48 time. It is inappropriate to use Internet-Drafts as reference 49 material or to cite them other than as "work in progress." 51 This Internet-Draft will expire on December 15, 2014. 53 Copyright Notice 55 Copyright (c) 2014 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 71 2. Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 2.2. Originating roaming call . . . . . . . . . . . . . . . . 5 74 2.3. Terminating roaming call . . . . . . . . . . . . . . . . 5 75 2.4. Originating home to terminating home call . . . . . . . . 5 76 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 4. iotl SIP URI parameter . . . . . . . . . . . . . . . . . . . 5 78 4.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 4.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 6 80 4.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 6 81 4.2.2. homeA-homeB . . . . . . . . . . . . . . . . . . . . . 7 82 4.2.3. homeB-visitedB . . . . . . . . . . . . . . . . . . . 7 83 4.2.4. visitedA-homeA . . . . . . . . . . . . . . . . . . . 7 84 4.2.5. homeA-visitedA . . . . . . . . . . . . . . . . . . . 7 85 4.2.6. visitedA-homeB . . . . . . . . . . . . . . . . . . . 8 86 5. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8 88 5.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 8 89 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 90 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 91 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 92 9. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 9 93 10. Normative References . . . . . . . . . . . . . . . . . . . . 9 94 Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 10 95 A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10 96 A.2. The UE registers via P-CSCF . . . . . . . . . . . . . . . 10 97 A.3. Originating IMS call . . . . . . . . . . . . . . . . . . 11 98 A.4. Terminating IMS call . . . . . . . . . . . . . . . . . . 12 99 A.5. Call between originating home and terminating home 100 network . . . . . . . . . . . . . . . . . . . . . . . . . 13 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 103 1. Introduction 105 In a telecommunication network, an end user can be attached (e.g. 106 using a radio access network) to its own operator network (home 107 network), or to another operator's network (visited network). In the 108 latter case the user is referred to as a roaming user. 110 Telecommunication operator networks are often not connected directly 111 to each other. Instead, there might be intermediate networks, 112 referred to as transit networks, between them. A transit network 113 might act on a SIP level or on IP level. 115 In telecommunication networks, the signalling path between a calling 116 user and a called user can be partioned into segments, referred to as 117 traffic legs. Each traffic leg may span networks belonging to 118 different operators, and will have its own characteristics that can 119 be different from other traffic legs in the same call. The 120 directionality in traffic legs relates to a SIP request creating a 121 dialogue and stand-alone SIP request. A traffic leg might be 122 associated with multiple SIP dialogs, e.g. in case a B2BUA which 123 modifies the SIP dialog identifier is located within the traffic leg. 125 The traffic leg information can be used by intermediary entities to 126 make policy decisions, related to e.g. media anchoring, signalling 127 policy, insertion of media functions (e.g. transcoder) and charging. 129 The figure below shows two users (Alice and Bob) and the different 130 type of networks that the signaling might traverse. The signalling 131 path can be divided into multiple traffic legs, and the type of 132 traffic legs depends on how the signalling is routed. 134 Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob 135 Home + + + + + Home 136 + ++++++++++++++++++ + + 137 + + + 138 + + + 139 + +++++++++++++++++++++++ + 140 + + + + 141 Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob 142 Visited Visited 144 Figure 1: Telecommunication operator network roaming roles 146 ORIG HNW = Originating Home Network 148 TERM HNW = Terminating Home Network 150 ORIG VNW = Originating Visited Network 152 TERM VNW = Terminating Visited Network 154 In Figure 1 Alice is a user initiating communication with Bob, and: 156 Alice is attached to an originating network, which is either the home 157 network of Alice, or a visited network (in case Alice is roaming). 158 In both cases any originating service is provided by the home network 159 of Alice. 161 Bob is attached to a terminating network, which is either the home 162 network of Bob, or a visited network (in case Bob is roaming). In 163 both cases any terminating service is provided by the home network of 164 Bob. 166 A transit network, providing transit functions (e.g. translation of 167 free phone numbers), may be included between the originating and 168 terminating networks and between visited and home networks. 170 This document defines a new SIP URI parameter [RFC3261], 'iotl', 171 which can be used in a SIP URI to indicate that the entity associated 172 with the address, or an entity responsible for the host part of the 173 address, represents the end of a specific traffic leg (or multiple 174 traffic legs). 176 The 'iotl' parameter is defined in order to fulfil requirements from 177 the 3rd-Generation Partnership Project (3GPP), but it can also be 178 used in other network environments. 180 2. Use-cases 182 2.1. General 184 This section describes examples of different types of traffic legs in 185 3GPP networks. 187 2.2. Originating roaming call 189 In this case, Alice is located in a visited network. When Alice 190 sends the initial SIP INVITE request for a call, one traffic leg 191 (referred to as the 'visitedA-homeA' traffic leg) represents the 192 signalling path between the UA of Alice and the home S-CSCF of Alice. 194 2.3. Terminating roaming call 196 In this case, Bob is located in a visited network. When the home 197 S-CSCF of Bob forwards the initial SIP INVITE request for a call 198 towards Bob, one traffic leg (referred to as the 'homeB-visitedB' 199 traffic leg) represents the signalling path between the home S-CSCF 200 of Bob and the UA of Bob. 202 2.4. Originating home to terminating home call 204 In this case, the home S-CSCF of Alice forwards the initial SIP 205 INVITE request towards the home S-CSCF of Bob. The signalling path 206 between the S-CSCFs represents one traffic leg (referred to as the 207 'homeA-homeB' traffic leg). 209 3. Conventions 211 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 212 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 213 document are to be interpreted as described in [RFC2119]. 215 4. iotl SIP URI parameter 217 4.1. Usage 219 As specified in [RFC3261], when a SIP entity inserts a SIP URI in an 220 initial request for a dialog, or in a stand-alone request, the SIP 221 URI will be used to route the request to another SIP entity, 222 addressed by the SIP URI, or to a SIP entity responsible for the host 223 part of the SIP URI (e.g. a SIP registrar). If such entity 224 represents the end of one or more traffic legs, the SIP entity 225 inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP 226 URI, to indicate the type(s) of traffic leg. Each parameter value 227 indicates a type of traffic leg. 229 For routing of a SIP request, a SIP entity can add the 'iotl' 230 parameter to the SIP URI of the Request-URI [RFC3261], or to the SIP 231 URI of a Route header field [RFC3261], of an initial request for a 232 dialog, or of an stand-alone request. 234 If, within an initial request for a dialog, or within a stand-alone 235 request, multiple Route header fields contain a SIP URI with a 'iotl' 236 parameter, the 'iotl' parameter associated with the SIP URI of the 237 topmost Route header field (or, if the SIP URI of the topmost Route 238 header field does not contain an 'iotl' parameter, the SIP URI of the 239 Route header field closest to the topmost) identifies the type of 240 traffic leg. 242 If a SIP request contains an 'iotl' parameter both in the Request-URI 243 SIP URI, and in one or more SIP-URIs of the Route header fields, the 244 'iotl' parameter associated with the SIP URI of the topmost Route 245 header field (or, if the SIP URI of the topmost Route header field 246 does not contain an 'iotl' parameter, the SIP URI of the Route header 247 field closest to the topmost) identifies the type of traffic leg. 249 If a SIP request contains an 'iotl' parameter only in the Request-URI 250 SIP URI, the 'iotl' parameter identifies the type of traffic leg. 252 During SIP registration [RFC3261], entities can add the 'iotl' 253 parameter to the SIP URI of a Path or Service-Route header field, if 254 the entity is aware that SIP URI will be used to indicate the end of 255 a specific traffic leg for initial requests for dialogs, or stand- 256 alone requests, sent on the registration path. 258 An entity that understands the 'iotl' parameter MUST NOT, from a SIP 259 request, remove 'iotl' parameters from SIP URIs associated with other 260 entities, unless the entity has means to determine that the 'iotl' 261 parameter does not represent a valid traffic leg. 263 This document does not specify the usage of the 'iotl' parameter 264 within a SIP URI of a Record-Route header field [RFC3261]. 266 4.2. Parameter Values 268 4.2.1. General 270 This section describes the SIP URI 'iotl' parameter values defined in 271 this specification. 273 4.2.2. homeA-homeB 275 This value indicates that a SIP entity responsible for the host part 276 of the SIP URI associated with the parameter represents the end of a 277 traffic leg between the home network (originating) of the calling 278 user and the home network (terminating) of the called user. 280 In 3GPP, this traffic leg is between two S-CSCFs. 282 4.2.3. homeB-visitedB 284 This value indicates that the SIP entity addressed by the SIP URI 285 associated with the parameter represents the end of a traffic leg 286 between the home network (terminating) of the called user and the 287 visited network (terminating) in which the called user is located. 289 In 3GPP, this traffic leg is between the home S-CSCF and the UE of 290 the called user, or between the Service Centralization and Continuity 291 Application Server (SCC AS) in the home network of the called user 292 and Access Transfer Control Function (ATCF) in the visited network of 293 the called user. 295 4.2.4. visitedA-homeA 297 This value indicates that a SIP entity responsible for the host part 298 of the SIP URI associated with the parameter represents the end of a 299 traffic leg between the visited network (originating) in which the 300 calling user is located and the home network (originating) of the 301 calling user. 303 In 3GPP, this traffic leg is between the UE and the home S-CSCF of 304 the calling user, or between the P-CSCF in the visited network, 305 serving the calling user, and the home S-CSCF of the calling user. 307 4.2.5. homeA-visitedA 309 This value indicates that the SIP entity addressed by the SIP URI 310 associated with the parameter represents the end of a traffic leg 311 between the home network (originating) and the visited network 312 (originating) in which the calling user is located. 314 In 3GPP, this traffic leg is between the home S-CSCF of the calling 315 user and the Transit and Roaming Function (TRF) [3GPP TS 24.229] 316 serving the calling user, and exists in scenarios where the home 317 S-CSCF of the calling user forwards a request back to the visited 318 network where the UE of the calling user is located. An example of 319 this is when the Roaming Architecture for Voice over IMS with Local 320 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 322 4.2.6. visitedA-homeB 324 This value indicates that a SIP entity responsible for the host part 325 of the SIP URI associated with the parameter represents represents 326 the end of a traffic leg between the visited network (originating) of 327 the calling user and the home network (terminating) of the called 328 user. 330 In 3GPP, this traffic leg is between the Transit and Roaming Function 331 (TRF) [3GPP TS 24.229] serving the calling user and the home S-CSCF 332 of the called user, and exists in scenarios where a request is 333 forwarded from the visited network where the calling user is located 334 directly to the home S-CSCF of the called user. An example of this 335 is when the Roaming Architecture for Voice over IMS with Local 336 breakout (RAVEL) [3GPP TS 24.229] feature is enabled. 338 5. Syntax 340 5.1. General 342 This section defines the ABNF for the 'iotl' SIP URI parameter. The 343 ABNF defined in this specification is conformant to RFC 5234 344 [RFC5234]. 346 5.2. ABNF 348 The ABNF [RFC5234] grammar for the role SIP URI parameter is: 350 uri-parameter = transport-param / user-param / method-param / ttl-param 351 / maddr-param / lr-param / iotl-param / other-param 352 iotl-param = iotl-tag "=" iotl-value ["." iotl-value] 353 iotl-tag = "iotl" 354 iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" 355 / "homeA-visitedA" /" visitedA-homeB" / other-iotl 356 other-iotl = 1*iotl-char 357 iotl-char = alphanum / "-" 358 ;; alphanum defined in RFC 3261 360 6. Security Considerations 362 There SHOULD exis a trust relationship between the networks that 363 provide the roaming role and the networks that use the information 364 for making policy decisions based on the role. In addition, there 365 MUST exist an agreement between the operators for usage of the 366 roaming role information. 368 7. IANA Considerations 370 [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this 371 document.] This specification adds one new value to the IANA 372 registration in the "SIP/SIPS URI Parameters" registry as defined in 373 [RFC3969]. 375 Parameter Name Predefined Values Reference 376 ____________________________________________ 377 iotl Yes [This RFC] 379 8. Acknowledgments 381 The authors wish to thank everyone in the 3GPP community that gave 382 comments on the initial version of this document. 384 9. Change Log 386 [RFC EDITOR NOTE: Please remove this section when publishing] 388 draft-holmberg-dispatch-iotl-00 390 o Added text on how to identify the traffic leg type when SIP-URIs 391 of multiple Route header fields and/or the Request-URI contain an 392 'iotl' parameter. 394 o Clarify that a traffic leg might span over multiple SIP dialogs. 396 o Added text saying that entities supporting the 'iotl' parameter 397 must not remove a parameter from a request, if the parameter is 398 associated with a SIP URI beloning to another entity. 400 o Modified ABNF, in order to allow multiple iotl values for a single 401 URI. 403 o In IANA section, changed indication that predefined values exist. 405 o Example call flows added. 407 10. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 413 A., Peterson, J., Sparks, R., Handley, M., and E. 414 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 415 June 2002. 417 [RFC3969] Camarillo, G., "The Internet Assigned Number Authority 418 (IANA) Uniform Resource Identifier (URI) Parameter 419 Registry for the Session Initiation Protocol (SIP)", BCP 420 99, RFC 3969, December 2004. 422 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 423 Specifications: ABNF", STD 68, RFC 5234, January 2008. 425 Appendix A. 3GPP Examples 427 A.1. General 429 This section contains example call flows based on 3GPP usage of the 430 SIP URI 'iotl' parameter. 432 A.2. The UE registers via P-CSCF 434 The Visited Proxy (P-CSCF) adds the iotl value 'homeB-visitedB' to 435 the Path header field of the REGISTER request, to be used for 436 terminating routing towards Alice. The Home Proxy (S-CSCF) adds the 437 iotl value 'visitedA-homeA' to the Service-Route header field, to be 438 used for originating initial/stand-alone requests from Alice. 440 Visited Proxy Visited Proxy Home Proxy Home Proxy 441 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 442 | | | | | 443 | REGISTER F1 | | | | 444 |--------------->| REGISTER F2 | | | 445 | |--------------->| REGISTER F3 | | 446 | | |--------------->| REGISTER F4 | 447 | | | |--------------->| 448 | | | | | 449 | | | | 200 (OK) F5 | 450 | | | |<---------------| 451 | | | 200 (OK) F6 | | 452 | | |<---------------| | 453 | | 200 (OK) F7 | | | 454 | |<---------------| | | 455 | 200 (OK) F8 | | | | 456 |<---------------| | | | 458 F1 REGISTER Alice -> P-CSCF 459 REGISTER sip:registrar.home1.net SIP/2.0 461 F2 REGISTER P-CSCF -> IBCF-V 462 REGISTER sip:registrar.home1.net SIP/2.0 463 Path: 465 F3 REGISTER IBCF-V -> IBCF-H 466 REGISTER sip:registrar.home1.net SIP/2.0 467 Path: 469 F4 REGISTER IBCF-H -> S-CSCF 470 REGISTER sip:registrar.home1.net SIP/2.0 471 Path: 473 F5 200 OK S-CSCF -> IBCF-H 474 200 OK 475 Path: 476 Service-Route: 478 F6 200 OK IBCF-H -> IBCF-V 479 200 OK 480 Path: 481 Service-Route: 483 F7 200 OK IBCF-V -> P-CSCF 484 200 OK 485 Path: 486 Service-Route: 488 F8 200 OK P-CSCF -> Alice 489 200 OK 490 Path: 491 Service-Route: 493 Figure 2: The UE registers via P-CSCF 495 A.3. Originating IMS call 497 In the originating INVITE request from Alice, the iotl value 498 'visitedA-homeA', received in the Service-Route header field during 499 registration, is added to the Route header field representing the 500 Home Proxy S-CSCF, to indicate the traffic leg type between the 501 Visited Proxy P-CSCF and the Home Proxy S-CSCF. 503 Visited Proxy Visited Proxy Home Proxy Home Proxy 504 Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF 505 | | | | | 506 | INVITE F1 | | | | 507 |--------------->| INVITE F2 | | | 508 | |--------------->| INVITE F3 | | 509 | | |--------------->| INVITE F4 | 510 | | | |--------------->| 511 | | | | | 512 | | | | 180 F5 | 513 | | | 180 F6 |<---------------| 514 | | 180 F7 |<---------------| | 515 | 180 F8 |<---------------| | | 516 |<---------------| | | | 517 | | | | | 519 F1 INVITE Alice -> P-CSCF 520 INVITE sip:Bob@homeB.net SIP/2.0 521 Route: , 523 F2 INVITE P-CSCF -> IBCF-V 524 INVITE sip:Bob@homeB.net SIP/2.0 525 Route: , 527 F3 INVITE IBCF-V -> IBCF-H 528 INVITE sip:Bob@homeB.net SIP/2.0 529 Route: , 531 F4 INVITE IBCF-H -> S-CSCF 532 INVITE sip:Bob@homeB.net SIP/2.0 533 Route: 535 Figure 3: Originating IMS call 537 A.4. Terminating IMS call 539 In the terminating INVITE request towards Alice, the iotl value 540 'homeB-visitedB', provided to the Home Proxy S-CSCF during 541 registration, is added to the Route header field representing the 542 Visited Proxy P-CSCF, to indicate the traffic leg type between the 543 Home Proxy S-CSCF and the Visited Proxy P-CSCF. 545 Home Proxy Home Proxy Visited Proxy Visited Proxy 546 S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob 547 | | | | | 548 | INVITE F1 | | | | 549 |--------------->| INVITE F2 | | | 550 | |--------------->| INVITE F3 | | 551 | | |--------------->| INVITE F4 | 552 | | | |--------------->| 553 | | | | | 554 | | | | 180 F5 | 555 | | | 180 F6 |<---------------| 556 | | 180 F7 |<---------------| | 557 | 180 F8 |<---------------| | | 558 |<---------------| | | | 559 | | | | | 561 F1 INVITE S-CSCF -> IBCF-H 562 INVITE sip:Bob@visitedB.net SIP/2.0 563 Route: , IBCF-V 566 INVITE sip:Bob@visitedB.net SIP/2.0 567 Route: , P-CSCF 570 INVITE sip:Bob@visitedB.net SIP/2.0 571 Route: Bob 574 INVITE sip:Bob@visitedB.net SIP/2.0 576 Figure 4: Terminating IMS call 578 A.5. Call between originating home and terminating home network 580 The S-CSCF of the originating home network adds the iotl value 581 'homeA-homeB' in the Request-URI of the INVITE, sent towards the 582 S-CSCF of the terminating network, to indicate the traffic leg type 583 between the S-CSCFs. 585 Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy 586 S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B 587 | | | | | 588 | INVITE F1 | | | | 589 |--------------->| INVITE F2 | | | 590 | |--------------->| INVITE F3 | | 591 | | |--------------->| INVITE F4 | 592 | | | |--------------->| 593 | | | | | 594 | | | | 180 F5 | 595 | | | 180 F6 |<---------------| 596 | | 180 F7 |<---------------| | 597 | 180 F8 |<---------------| | | 598 |<---------------| | | | 599 | | | | | 601 F1 INVITE S-CSCF-A -> IBCF-A 602 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 604 F2 INVITE IBCF-a -> IBCF-B 605 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 607 F3 INVITE IBCF-B -> I-CSCF-B 608 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 610 F4 INVITE I-CSCF-B -> S-CSCF-B 611 INVITE sip:Bob@visitedB.net;iotl=homeA-homeB SIP/2.0 613 Figure 5: Call between originating home and terminating home network 615 Authors' Addresses 617 Christer Holmberg 618 Ericsson 619 Hirsalantie 11 620 Jorvas 02420 621 Finland 623 Email: christer.holmberg@ericsson.com 624 Jan Holm 625 Ericsson 626 Kistavagen 25 627 Stockholm16480 628 Sweden 630 Email: jan.holm@ericsson.com 632 Roland Jesske 633 Deutsche Telekom 634 Heinrich-Hertz-Strasse 3-7 635 Darmstadt 64307 636 Germany 638 Phone: +4961515812766 639 Email: r.jesske@telekom.de 641 Martin Dolly 642 ATT 643 718 Clairmore Ave 644 Lanoka Harbor 08734 645 USA 647 Email: md3135@att.com