Network Working GroupInternet Engineering Task Force (IETF) C. HolmbergInternet-DraftRequest for Comments: 7549 J. HolmIntended status:Category: Standards Track EricssonExpires: August 23, 2015ISSN: 2070-1721 R. Jesske Deutsche Telekom M. DollyATT February 19,AT&T May 20153rd-Generation Partnership Project (3GPP)3GPP SIP URIInter OperatorInter-Operator Traffic Legparameter draft-holmberg-dispatch-iotl-06.txtParameter Abstract In3rd-Generation Partnership Project (3GPP)3GPP networks, thesignallingsignaling path between a calling user and a called user can bepartionedpartitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to differentoperators,operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs,e.g.e.g., in case aB2BUA whichBack-to-Back User Agent (B2BUA) that modifies the SIP dialog identifier is located within the traffic leg. This document defines a new SIP URI parameter,'iotl'.'iotl' (an abbreviation for Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible. Status of This Memo ThisInternet-Draftissubmitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documentsan Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF).Note that other groups may also distribute working documents as Internet-Drafts. The listIt represents the consensus ofcurrent Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents validthe IETF community. It has received public review and has been approved fora maximumpublication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status ofsix monthsthis document, any errata, and how to provide feedback on it may beupdated, replaced, or obsoleted by other documentsobtained atany time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 23, 2015.http://www.rfc-editor.org/info/rfc7549. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . .34 2.Applicability . . .Conventions . . . . . . . . . . . . . . . . . . . . .5 3. Traffic leg examples. . . . 6 3. Applicability . . . . . . . . . . . . . . . .5 3.1. General. . . . . . . . 6 4. Traffic Leg Examples . . . . . . . . . . . . . . . . .5 3.2. Originating roaming call. . . 6 4.1. General . . . . . . . . . . . . .5 3.3. Terminating roaming call. . . . . . . . . . . . 6 4.2. Originating Roaming Call . . . .5 3.4. Originating home to terminating home call. . . . . . . .5 4. Conventions. . . . 6 4.3. Terminating Roaming Call . . . . . . . . . . . . . . . . 7 4.4. Call from Originating Home to Terminating Home . . . . .67 5.iotl'iotl' SIP URIparameter .Parameter . . . . . . . . . . . . . . . . . .67 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . .67 5.2. Parameter Values . . . . . . . . . . . . . . . . . . . .78 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . .78 5.2.2. homea-homeb . . . . . . . . . . . . . . . . . . . . .78 5.2.3. homeb-visitedb . . . . . . . . . . . . . . . . . . .78 5.2.4. visiteda-homea . . . . . . . . . . . . . . . . . . .79 5.2.5. homea-visiteda . . . . . . . . . . . . . . . . . . .89 5.2.6. visiteda-homeb . . . . . . . . . . . . . . . . . . .89 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . .810 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . .810 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . .910 7. Security Considerations . . . . . . . . . . . . . . . . . . .910 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . .910 9.Acknowledgments . . . . .References . . . . . . . . . . . . . . . . . .9 10. Change Log. . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . .10 11.11 9.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. 3GPP Examples . . . . . . . .12 11.1. Normative References . . .. . . . . . . . . . . 12 A.1. General . . . .12 11.2. Informative References. . . . . . . . . . . . . . . . .13 Appendix A. 3GPP Examples. . . . 12 A.2. The UE Registers via P-CSCF . . . . . . . . . . . . . . .13 A.1. General12 A.3. Originating IMS Call . . . . . . . . . . . . . . . . . . 14 A.4. Terminating IMS Call . . . . . . .13 A.2. The UE registers via P-CSCF. . . . . . . . . . .. . . . 13 A.3.15 A.5. Call between OriginatingIMS call . . . . . . . . . . . .Home and Terminating Home Network . . . . . .14 A.4. Terminating IMS call. . . . . . . . . . . . . . . . . .15 A.5. Call between originating home and terminating home network. 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .1617 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction In a3rd-Generation Partnership Project (3GPP)3GPP network, anend userend-user device can be attached(e.g.(e.g., using a radio access network) to its own operator network (home network)[TS.3GPP.24.229],[TS.3GPP.24.229] or to another operator's network (visited network) [TS.3GPP.24.229]. In the lattercasecase, the user is referred to as a roaming user. 3GPP operator networks are often not connected directly to each other. Instead, there might be intermediate networks, referred to as 3GPP transit networks, between them. Such transitnetworknetworks act on the SIP level oronthe IP level. In 3GPP networks, thesignallingsignaling path between a calling user and a called user can bepartionedpartitioned into segments, referred to as traffic legs. Each traffic leg may span networks belonging to differentoperators,operators and will have its own characteristics that can be different from other traffic legs in the same call. A traffic leg might be associated with multiple SIP dialogs,e.g.e.g., in case aBack- To-Back User Agent (B2BUA)B2BUA [RFC3261]whichthat modifies the SIP dialog identifier is located within the traffic leg. The traffic leg information can be used by intermediary entities to make policydecisions,decisions relatedto e.g.to, e.g., media anchoring,signallingsignaling policy, insertion of media functions(e.g. transcoder)(e.g., transcoder), and charging. The figure below shows two users (Alice and Bob) and the different type of networks that the signaling might traverse. Thesignallingsignaling path can be divided into multiple traffic legs, and the type of traffic legs depends on how thesignallingsignaling is routed. Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob Home + + + + + Home + ++++++++++++++++++ + + + + + + + + + +++++++++++++++++++++++ + + + + + Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob Visited VisitedFigure 1: 3GPP operator network roaming rolesORIG HNW = Originating 3GPP Home Network TERM HNW = Terminating 3GPP Home Network ORIG VNW = Originating 3GPP Visited Network TERM VNW = Terminating 3GPP Visited Network TRANSIT NW = 3GPP Transit Network Figure 1: 3GPP Operator Network Roaming Roles In Figure11, Alice is a user initiating communication withBob, and:Bob. Also, consider the following information: Alice is attached to an originating network, which is either the home network ofAlice,Alice or a visited network (in case Alice is roaming). In bothcasescases, any originating service is provided by the home network of Alice. Bob is attached to a terminating network, which is either the home network ofBob,Bob or a visited network (in case Bob is roaming). In bothcasescases, any terminating service is provided by the home network of Bob. A transitnetwork,network providing transit functions(e.g.(e.g., translation of free phonenumbers),numbers) may be included between the originating and terminating networks and between visited and home networks. This document defines a new SIP URI parameter [RFC3261], 'iotl' (an abbreviationof Inter Operatorfor Inter-Operator Traffic Leg). The parameter can be used in a SIP URI to indicate that the entity associated with the address, or an entity responsible for the host part of the address, represents the end of a specific traffic leg (or multiple traffic legs). This document defines the following 'iotl' parameter values: o homea-homeb o homeb-visitedb o visiteda-homea o homea-visiteda o visiteda-homeb SIP entities that do not support the SIP URI 'iotl' parameter will simply ignore it, if received, as defined in [RFC3261]. 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Applicability The SIP URI 'iotl' parameter defined in this document has known uses in 3GPP networks. Usage in other networks is also possible.3.4. Trafficleg examples 3.1.Leg Examples 4.1. General This section describes examples of different types of traffic legs in 3GPP networks.3.2.4.2. Originatingroaming callRoaming Call In this case, Alice is located in a visited network. When Alice sends the initial SIP INVITE request for a call, one traffic leg (referred to as the 'visiteda-homea' traffic leg) represents thesignallingsignaling path between theUAUser Agent (UA) of Alice and the homeS-CSCF [3GPP TS 24.229]Serving Call Session Control Function (S-CSCF) [TS.3GPP.24.229] of Alice.3.3.4.3. Terminatingroaming callRoaming Call In this case, Bob is located in a visited network. When the home S-CSCF of Bob forwards the initial SIP INVITE request for a call towards Bob, one traffic leg (referred to as the 'homeb-visitedb' traffic leg) represents thesignallingsignaling path between the home S-CSCF of Bob and the UA of Bob.3.4.4.4. Call from OriginatinghomeHome toterminating home callTerminating Home In this case, the home S-CSCF of Alice forwards the initial SIP INVITE request towards the home S-CSCF of Bob. Thesignallingsignaling path between the S-CSCFs represents one traffic leg (referred to as the 'homea-homeb' traffic leg).4. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].5.iotl'iotl' SIP URIparameterParameter 5.1. Usage As specified in [RFC3261], when a SIP entity inserts a SIP URI in an initial request for a dialog, or in a stand-alone request, the SIP URI will be used to route the request to another SIP entity, addressed by the SIP URI, or to a SIP entity responsible for the host part of the SIP URI(e.g.(e.g., a SIP registrar). If such an entity represents the end of one or more traffic legs, the SIP entity inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIPURI,URI to indicate the type(s) of traffic leg. Each parameter value indicates a type of traffic leg. For routing of an initial SIP request for a dialog, or a stand-alone SIP request, a SIP entity can add the 'iotl' parameter to (a) the SIP URI of the Request-URI[RFC3261],[RFC3261] orto(b) the SIP URI of a Route header field[RFC3261], of an initial request for a dialog, or[RFC3261] ofan stand-alonethe SIP request. SIP entities can add the 'iotl' parameter to the SIP URI of a Path header field [RFC3327] or a Service-Route header field[RFC3608],[RFC3608] in order for the parameter to later occur in a Route header field. When a SIP entity receives an initial request for adialog,dialog or a stand-alone request, which contains one or more SIP URI 'iotl' parameters, it identifies the type of traffic leg in the following way: oIfif the SIP request contains a single Route header field containing a SIP URI with an 'iotl' parameter, that parameter identifies the type of traffic leg; oIfif the SIP request contains multiple Route header fields containing a SIP URI with an 'iotl' parameter, the 'iotl' parameter associated with the SIP URI of the topmost Route header field (or, if the SIP URI of the topmost Route header field does not contain an 'iotl' parameter, the SIP URI of the Route header field closest to the topmost) identifies the type of traffic leg; or oIfif a SIP request contains an 'iotl' parameter only in the Request- URI SIP URI, the 'iotl' parameter identifies the type of traffic leg. During SIP registration [RFC3261], entities can add the 'iotl' parameter to the SIP URI of a Path or Service-Route headerfield,field if the entity is aware that the SIP URI will be used to indicate the end of a specific traffic leg for initial requests fordialogs,dialogs or stand- alonerequests,requests sent on the registration path. As defined in [RFC3261], a SIP proxy must not modify or removeuriURI parameters from SIP URIs associated with other entities. This also applies to the 'iotl' parameter. 5.2. Parameter Values 5.2.1. General This section describes the SIP URI 'iotl' parameter values defined in this specification.5.2.2. homea-homeb This value indicates thatNote that, when aSIP entity responsible forrequest is routed between different networks, the request might traverse one or more IBCFs (Interconnection Border Control Functions) acting as network border entities. 5.2.2. homea-homeb This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the home network (originating) of the calling user and the home network (terminating) of the called user. In 3GPP, this traffic leg is between two S-CSCFs. 5.2.3. homeb-visitedb This value indicates that the SIP entity addressed by the SIP URI associated with the parameter represents the end of a traffic leg between the home network (terminating) of the called user and the visited network (terminating) in which the called user is located. In 3GPP, this traffic leg is between the home S-CSCF and theUEUser Equipment (UE) of the calleduser,user or between the Service Centralization and Continuity Application Server (SCC AS) in the home network of the called user and Access Transfer Control Function (ATCF) in the visited network of the called user. 5.2.4. visiteda-homea This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the visited network (originating) in which the calling user is located and the home network (originating) of the calling user. In 3GPP, this traffic leg is between the UE and the home S-CSCF of the callinguser,user or between theP-CSCFProxy Call Session Control Function (P-CSCF) in the visited network, serving the callinguser,user and the home S-CSCF of the calling user. 5.2.5. homea-visiteda This value indicates that the SIP entity addressed by the SIP URI associated with the parameter represents the end of a traffic leg between the home network (originating) and the visited network (originating) in which the calling user is located. In 3GPP, this traffic leg is between the home S-CSCF of the calling user and the Transit and Roaming Function (TRF)[3GPP TS 24.229][TS.3GPP.24.229] serving the callinguser,user and exists in scenarios where the home S-CSCF of the calling user forwards a request back to the visited network where the UE of the calling user is located. An example of this is when the Roaming Architecture for Voice over IMS with LocalbreakoutBreakout (RAVEL)[3GPP TS 24.229][TS.3GPP.24.229] feature is enabled. 5.2.6. visiteda-homeb This value indicates that a SIP entity responsible for the host part of the SIP URI associated with the parameter represents the end of a traffic leg between the visited network (originating) of the calling user and the home network (terminating) of the called user. In 3GPP, this traffic leg is between theTransit and Roaming Function (TRF) [3GPP TS 24.229]TRF [TS.3GPP.24.229] serving the calling user and the home S-CSCF of the calleduser,user and exists in scenarios where a request is forwarded from the visited network where the calling user is located directly to the home S-CSCF of the called user. An example of this is when theRoaming Architecture for Voice over IMS with Local breakout (RAVEL) [3GPP TS 24.229]RAVEL [TS.3GPP.24.229] feature is enabled. 6. Syntax 6.1. General This section defines the ABNF for the 'iotl' SIP URI parameter. The ABNF defined in this specification is conformant to RFC 5234 [RFC5234]. This specification does not create an IANA registry for 'iotl' parameter values. A registry should be considered if new parameter values are defined in the future. 6.2. ABNF The ABNF [RFC5234] grammar forthe rolethis SIP URI parameter is: uri-parameter =/ iotl-param iotl-param = iotl-tag "=" iotl-value ["." iotl-value] iotl-tag = "iotl" iotl-value = "homea-homeb" / "homeb-visitedb" / "visiteda-homea" / "homea-visiteda" / "visiteda-homeb" / other-iotl other-iotl = 1*iotl-char iotl-char = alphanum / "-" ;; alphanum defined in RFC 3261 7. Security Considerations The information in the 'iotl' parameter is used for making policy decisions. Such policies can be related to charging and triggering of services. In order to prevent abuse, which couldcause user billing, or service failure, the parameter SHOULD only be used for making policy decisions based on the role by nodes within the same trust domain [RFC3325], and network boundary entities MUST NOT forward information received from untrusted entities. In addition, there MUST exist an agreement between the operators for usage of the roaming role information. General security considerations for SIP are defined in [RFC3261] 8. IANA Considerations [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] This specification adds one new value to the IANA registration in the "SIP/SIPS URI Parameters" registry as defined in [RFC3969]. Parameter Name Predefined Values Reference ____________________________________________ iotl Yes [This RFC] 9. Acknowledgments The authors wish to thank everyone in the 3GPP community that gave comments on the initial version of this document, and contributed with comments and suggestion during the work. A special thanks to Paul Kyziwat, Dale Worley and Michael Hammer. Robert Sparks performed the Gen-ARTreview of the draft. 10. Change Log [RFC EDITOR NOTE: Please remove this section when publishing] draft-holmberg-dispatch-iotl-04 o Change based on IESG review from Stephen Farrell: o - Editorial changes. draft-holmberg-dispatch-iotl-04 o Change based on IESG review from Spencer Dawkins: o - List of defined iotl parameter values listed in the Introduction. o - ABNF editorial fix. o Change based on IESG review from Barry Leiba: o - Only use lowercase when writing the iotl parameter values. o Change based on IESG review from Alissa Cooper: o - Sentence about usage in non-3GPP networks removed from the Introduction. o - Editorial correction in the Security Considerations. o Change based on IESG review from Benoit Claise: o - 'iotl' parameter name abbreviation extented in the Introduction. o Change based on IESG review from Kathleen Moriarty: o - Reference to RFC 3261 added to the Security Considerations. o Change based on IESG review from Stephen Farrell: o - Additional text and explanation added to the Security Considerations. draft-holmberg-dispatch-iotl-03 o Change based on Gen-ART review from Robert Sparks: o - Removed text saying that the mechanism is scoped for 3GPP networks only. o - Clarify that entities that do not support the parameter will ignore it. o - Clarify that the draft does not create an IANA registry for parameter values. o - Remove sentence regarding directionality. o - Reference to RFC 3327 added. o - Reference to RFC 3608 added. o - 'dialogue' -> 'dialog'. o Change based on Ops-ART review from Nevil Brownlee: o - Reference to RFC 3261 added to 'B2BUA'. o - Reference to 3GPP TS 24.229 added for 'S-CSCF'. draft-holmberg-dispatch-iotl-02 o Change based on comments from Richard Barnes: o - 3GPP scope text modified. o - Reference to 3GPP TS 24.229 added. o - Reference to RFC 3325 added, and incorporated into the Security Considerations. o - 'iotl' selection procedure made into a bullet list. draft-holmberg-dispatch-iotl-01 o Scope the SIP URI 'iotl' parameter to 3GPP, based on decision at IETF#90: o - Document name changed. o - Clarified that usage ofcause user billing or service failure, the parameterisSHOULD onlydefined within 3GPP networks. draft-holmberg-dispatch-iotl-00 o Added textbe used for making policy decisions based onhow to identifythetraffic leg type when SIP-URIs of multiple Route header fields and/orrole by nodes within theRequest-URI contain an 'iotl' parameter. o Clarify that a traffic leg might span over multiple SIP dialogs. o Added text saying thatsame trust domain [RFC3325], and network boundary entitiessupporting the 'iotl' parameter must not remove a parameterMUST NOT forward information received froma request, ifuntrusted entities. In addition, an agreement MUST exist between theparameter is associated with aoperators for usage of the roaming role information. General security considerations for SIPURI belonging to another entity. o Modified ABNF,are defined inorder[RFC3261] 8. IANA Considerations Per this specification, IANA has added one new value toallow multiplethe "SIP/SIPS URI Parameters" registry as defined in [RFC3969]. Parameter Name Predefined Values Reference ____________________________________________ iotlvalues for a single URI. o In IANA section, changed indication that predefined values exist. o Example call flows added. 11.Yes RFC 7549 9. References11.1.9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March1997.1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June2002.2002, <http://www.rfc-editor.org/info/rfc3261>. [RFC3327] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, DOI 10.17487/RFC3327, December2002.2002, <http://www.rfc-editor.org/info/rfc3327>. [RFC3608] Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, DOI 10.17487/RFC3608, October2003.2003, <http://www.rfc-editor.org/info/rfc3608>. [RFC3969] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, DOI 10.17487/RFC3969, December2004.2004, <http://www.rfc-editor.org/info/rfc3969>. [RFC5234] Crocker,D.D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January2008.2008, <http://www.rfc-editor.org/info/rfc5234>. [TS.3GPP.24.229] 3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229 12.6.0, September 2014.11.2.9.2. Informative References [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, DOI 10.17487/RFC3325, November2002.2002, <http://www.rfc-editor.org/info/rfc3325>. Appendix A. 3GPP Examples A.1. General This section contains example call flows based on 3GPP usage of the SIP URI 'iotl' parameter. A.2. The UEregistersRegisters via P-CSCF The Visited Proxy (P-CSCF) adds theiotl'iotl' value 'homeb-visitedb' to the Path header field of the REGISTERrequest,request to be used for terminating routing towards Alice. The Home Proxy (S-CSCF) adds theiotl'iotl' value 'visiteda-homea' to the Service-Route headerfield,field to be used for originating initial/stand-alone requests from Alice. Visited Proxy Visited Proxy Home Proxy Home Proxy Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF | | | | | | REGISTER F1 | | | | |--------------->| REGISTER F2 | | | | |--------------->| REGISTER F3 | | | | |--------------->| REGISTER F4 | | | | |--------------->| | | | | | | | | | 200 (OK) F5 | | | | |<---------------| | | | 200 (OK) F6 | | | | |<---------------| | | | 200 (OK) F7 | | | | |<---------------| | | | 200 (OK) F8 | | | | |<---------------| | | | F1 REGISTER Alice -> P-CSCF REGISTER sip:registrar.home1.net SIP/2.0 F2 REGISTER P-CSCF -> IBCF-V REGISTER sip:registrar.home1.net SIP/2.0 Path: <p-cscf URI;iotl=homeb-visitedb> F3 REGISTER IBCF-V -> IBCF-H REGISTER sip:registrar.home1.net SIP/2.0 Path: <p-cscf URI;iotl=homeb-visitedb> F4 REGISTER IBCF-H -> S-CSCF REGISTER sip:registrar.home1.net SIP/2.0 Path: <p-cscf URI;iotl=homeb-visitedb> F5 200 OK S-CSCF -> IBCF-H 200 OK Path: <p-cscf URI;iotl=homeb-visitedb> Service-Route: <s-cscf URI;iotl=visiteda-homea> F6 200 OK IBCF-H -> IBCF-V 200 OK Path: <p-cscf URI;iotl=homeb-visitedb> Service-Route: <s-cscf URI;iotl=visiteda-homea> F7 200 OK IBCF-V -> P-CSCF 200 OK Path: <p-cscf URI;iotl=homeb-visitedb> Service-Route: <s-cscf URI;iotl=visiteda-homea> F8 200 OK P-CSCF -> Alice 200 OK Path: <p-cscf URI;iotl=homeb-visitedb> Service-Route: <s-cscf URI;iotl=visiteda-homea> Figure 2: The UEregistersRegisters via P-CSCF A.3. Originating IMScallCall In the originating INVITE request from Alice, theiotl'iotl' value 'visiteda-homea', received in the Service-Route header field during registration, is added to the Route header field representing the Home ProxyS-CSCF,(S-CSCF) to indicate the traffic leg type between the Visited ProxyP-CSCF(P-CSCF) and the Home ProxyS-CSCF.(S-CSCF). Visited Proxy Visited Proxy Home Proxy Home Proxy Alice's . . . . P-CSCF . . . . . IBCF-V . . . . . IBCF-H . . . . S-CSCF | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |--------------->| INVITE F3 | | | | |--------------->| INVITE F4 | | | | |--------------->| | | | | | | | | | 180 F5 | | | | 180 F6 |<---------------| | | 180 F7 |<---------------| | | 180 F8 |<---------------| | | |<---------------| | | | | | | | | F1 INVITE Alice -> P-CSCF INVITE sip:Bob@homeb.net SIP/2.0 Route: <p-cscf URI>,<s-cscf URI;iotl=visiteda-homea> F2 INVITE P-CSCF -> IBCF-V INVITE sip:Bob@homeb.net SIP/2.0 Route: <ibcf-v URI>,<s-cscf URI;iotl=visiteda-homea> F3 INVITE IBCF-V -> IBCF-H INVITE sip:Bob@homeb.net SIP/2.0 Route: <ibcf-h URI>,<s-cscf URI;iotl=visiteda-homea> F4 INVITE IBCF-H -> S-CSCF INVITE sip:Bob@homeb.net SIP/2.0 Route: <s-cscf URI;iotl=visiteda-homea> Figure 3: OriginatingIMS callIP Multimedia Subsystem (IMS) Call A.4. Terminating IMScallCall In the terminating INVITE request towards Alice, theiotl'iotl' value'homeb-visitedb','homeb-visitedb' provided to the Home ProxyS-CSCF(S-CSCF) duringregistration,registration is added to the Route header field representing the Visited ProxyP-CSCF,(P-CSCF) to indicate the traffic leg type between the Home ProxyS-CSCF(S-CSCF) and the Visited ProxyP-CSCF.(P-CSCF). Home Proxy Home Proxy Visited Proxy Visited Proxy S-CSCF . . . . IBCF-H . . . . . IBCF-V . . . . . P-CSCF . . . . . Bob | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |--------------->| INVITE F3 | | | | |--------------->| INVITE F4 | | | | |--------------->| | | | | | | | | | 180 F5 | | | | 180 F6 |<---------------| | | 180 F7 |<---------------| | | 180 F8 |<---------------| | | |<---------------| | | | | | | | | F1 INVITE S-CSCF -> IBCF-H INVITE sip:Bob@visitedb.net SIP/2.0 Route: <ibcf-h URI>,<p-cscf-v URI;iotl=homeb-visitedb F2 INVITE IBCF-H -> IBCF-V INVITE sip:Bob@visitedb.net SIP/2.0 Route: <ibcf-v URI>,<p-cscf-v URI;iotl=homeb-visitedb F3 INVITE IBCF-V -> P-CSCF INVITE sip:Bob@visitedb.net SIP/2.0 Route: <p-cscf-v URI;iotl=homeb-visitedb F4 INVITE P-CSCF -> Bob INVITE sip:Bob@visitedb.net SIP/2.0 Figure 4: Terminating IMScallCall A.5. Call betweenoriginating homeOriginating Home andterminating home networkTerminating Home Network The S-CSCF of the originating home network adds theiotl'iotl' value 'homea-homeb' in the Request-URI of the INVITE, sent towards the S-CSCF of the terminatingnetwork,network to indicate the traffic leg type between the S-CSCFs. Home-A Proxy Home-A Proxy Home-B Proxy Home-B Proxy Home-B Proxy S-CSCF-A . . . . IBCF-A . . . . .IBCF-B . . . . .I-CSCF-B . . .S-CSCF-B | | | | | | INVITE F1 | | | | |--------------->| INVITE F2 | | | | |--------------->| INVITE F3 | | | | |--------------->| INVITE F4 | | | | |--------------->| | | | | | | | | | 180 F5 | | | | 180 F6 |<---------------| | | 180 F7 |<---------------| | | 180 F8 |<---------------| | | |<---------------| | | | | | | | | F1 INVITE S-CSCF-A -> IBCF-A INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 F2 INVITE IBCF-a -> IBCF-B INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 F3 INVITE IBCF-B -> I-CSCF-B INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 F4 INVITE I-CSCF-B -> S-CSCF-B INVITE sip:Bob@visitedb.net;iotl=homea-homeb SIP/2.0 Figure 5: Call betweenoriginating homeOriginating Home andterminating home networkTerminating Home Network Acknowledgements The authors wish to thank everyone in the 3GPP community that gave comments on the initial version of this document and contributed with comments and suggestions during the work. A special thanks to Paul Kyziwat, Dale Worley, and Michael Hammer. Robert Sparks performed the Gen-ART review of the document. Authors' Addresses Christer Holmberg Ericsson Hirsalantie 11 Jorvas 02420 FinlandEmail:EMail: christer.holmberg@ericsson.com Jan Holm Ericsson Kistavagen 25 Stockholm16480 SwedenEmail:EMail: jan.holm@ericsson.com Roland Jesske Deutsche Telekom Heinrich-Hertz-Strasse 3-7 Darmstadt 64307 Germany Phone: +4961515812766Email:EMail: r.jesske@telekom.de Martin DollyATTAT&T 718 Clairmore Ave Lanoka Harbor 08734USA Email:United States EMail: md3135@att.com