summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7549.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7549.txt')
-rw-r--r--doc/rfc/rfc7549.txt955
1 files changed, 955 insertions, 0 deletions
diff --git a/doc/rfc/rfc7549.txt b/doc/rfc/rfc7549.txt
new file mode 100644
index 0000000..1d4796e
--- /dev/null
+++ b/doc/rfc/rfc7549.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) C. Holmberg
+Request for Comments: 7549 J. Holm
+Category: Standards Track Ericsson
+ISSN: 2070-1721 R. Jesske
+ Deutsche Telekom
+ M. Dolly
+ AT&T
+ May 2015
+
+
+ 3GPP SIP URI Inter-Operator Traffic Leg Parameter
+
+Abstract
+
+ In 3GPP networks, the signaling path between a calling user and a
+ called user can be partitioned into segments, referred to as traffic
+ legs. Each traffic leg may span networks belonging to different
+ 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., in case a Back-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' (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
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication 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 of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc7549.
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 1]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 2]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
+ 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4. Traffic Leg Examples . . . . . . . . . . . . . . . . . . . . 6
+ 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 4.2. Originating Roaming Call . . . . . . . . . . . . . . . . 6
+ 4.3. Terminating Roaming Call . . . . . . . . . . . . . . . . 7
+ 4.4. Call from Originating Home to Terminating Home . . . . . 7
+ 5. 'iotl' SIP URI Parameter . . . . . . . . . . . . . . . . . . 7
+ 5.1. Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 7
+ 5.2. Parameter Values . . . . . . . . . . . . . . . . . . . . 8
+ 5.2.1. General . . . . . . . . . . . . . . . . . . . . . . . 8
+ 5.2.2. homea-homeb . . . . . . . . . . . . . . . . . . . . . 8
+ 5.2.3. homeb-visitedb . . . . . . . . . . . . . . . . . . . 8
+ 5.2.4. visiteda-homea . . . . . . . . . . . . . . . . . . . 9
+ 5.2.5. homea-visiteda . . . . . . . . . . . . . . . . . . . 9
+ 5.2.6. visiteda-homeb . . . . . . . . . . . . . . . . . . . 9
+ 6. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.2. ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
+ 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
+ 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
+ 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
+ 9.2. Informative References . . . . . . . . . . . . . . . . . 11
+ Appendix A. 3GPP Examples . . . . . . . . . . . . . . . . . . . 12
+ A.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 12
+ A.2. The UE Registers via P-CSCF . . . . . . . . . . . . . . . 12
+ A.3. Originating IMS Call . . . . . . . . . . . . . . . . . . 14
+ A.4. Terminating IMS Call . . . . . . . . . . . . . . . . . . 15
+ A.5. Call between Originating Home and Terminating Home
+ Network . . . . . . . . . . . . . . . . . . . . . . . . . 16
+ Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 3]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+1. Introduction
+
+ In a 3GPP network, an end-user device can be attached (e.g., using a
+ radio access network) to its own operator network (home network)
+ [TS.3GPP.24.229] or to another operator's network (visited network)
+ [TS.3GPP.24.229]. In the latter case, 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 transit networks act on
+ the SIP level or the IP level.
+
+ In 3GPP networks, the signaling path between a calling user and a
+ called user can be partitioned into segments, referred to as traffic
+ legs. Each traffic leg may span networks belonging to different
+ 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., in case a B2BUA [RFC3261]
+ that modifies the SIP dialog identifier is located within the traffic
+ leg.
+
+ The traffic leg information can be used by intermediary entities to
+ make policy decisions related to, e.g., media anchoring, signaling
+ policy, insertion of media functions (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. The signaling
+ path can be divided into multiple traffic legs, and the type of
+ traffic legs depends on how the signaling is routed.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 4]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+ Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob
+ Home + + + + + Home
+ + ++++++++++++++++++ + +
+ + + +
+ + + +
+ + +++++++++++++++++++++++ +
+ + + + +
+ Alice -- ORIG VNW +++++ TRANSIT NW ++ TERM VNW -- Bob
+ Visited Visited
+
+ ORIG 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 Figure 1, Alice is a user initiating communication with Bob. Also,
+ consider the following information:
+
+ Alice is attached to an originating network, which is either the home
+ network of Alice or a visited network (in case Alice is roaming). In
+ both cases, any originating service is provided by the home network
+ of Alice.
+
+ Bob is attached to a terminating network, which is either the home
+ network of Bob or a visited network (in case Bob is roaming). In
+ both cases, any terminating service is provided by the home network
+ of Bob.
+
+ A transit network providing transit functions (e.g., translation of
+ free phone 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
+ 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).
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 5]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+ 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.
+
+4. Traffic Leg Examples
+
+4.1. General
+
+ This section describes examples of different types of traffic legs in
+ 3GPP networks.
+
+4.2. Originating Roaming 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 the
+ signaling path between the User Agent (UA) of Alice and the home
+ Serving Call Session Control Function (S-CSCF) [TS.3GPP.24.229] of
+ Alice.
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 6]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+4.3. Terminating Roaming 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 the signaling path between the home S-CSCF of
+ Bob and the UA of Bob.
+
+4.4. Call from Originating Home to Terminating Home
+
+ In this case, the home S-CSCF of Alice forwards the initial SIP
+ INVITE request towards the home S-CSCF of Bob. The signaling path
+ between the S-CSCFs represents one traffic leg (referred to as the
+ 'homea-homeb' traffic leg).
+
+5. 'iotl' SIP URI Parameter
+
+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., 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 SIP
+ 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] or (b) the SIP URI of a Route header
+ field [RFC3261] of the 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] in order for the parameter to
+ later occur in a Route header field.
+
+ When a SIP entity receives an initial request for a 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:
+
+ o if 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;
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 7]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+ o if 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
+
+ o if 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 header 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 for dialogs or stand-
+ alone requests sent on the registration path.
+
+ As defined in [RFC3261], a SIP proxy must not modify or remove URI
+ 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.
+
+ Note that, when a request 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.
+
+
+
+Holmberg, et al. Standards Track [Page 8]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+ In 3GPP, this traffic leg is between the home S-CSCF and the User
+ Equipment (UE) of the called 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 calling user or between the Proxy Call Session Control Function
+ (P-CSCF) in the visited network, serving the calling 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) [TS.3GPP.24.229]
+ serving the calling 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 Local
+ Breakout (RAVEL) [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 the TRF [TS.3GPP.24.229] serving
+ the calling user and the home S-CSCF of the called 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 the RAVEL [TS.3GPP.24.229] feature
+ is enabled.
+
+
+
+
+Holmberg, et al. Standards Track [Page 9]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+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 for this 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 could cause 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,
+ an agreement MUST exist between the operators for usage of the
+ roaming role information.
+
+ General security considerations for SIP are defined in [RFC3261]
+
+8. IANA Considerations
+
+ Per this specification, IANA has added one new value to the "SIP/SIPS
+ URI Parameters" registry as defined in [RFC3969].
+
+ Parameter Name Predefined Values Reference
+ ____________________________________________
+ iotl Yes RFC 7549
+
+
+
+
+Holmberg, et al. Standards Track [Page 10]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+9. References
+
+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, March 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, June 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, December 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,
+ October 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, December 2004,
+ <http://www.rfc-editor.org/info/rfc3969>.
+
+ [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", STD 68, RFC 5234,
+ DOI 10.17487/RFC5234, January 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.
+
+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, November 2002,
+ <http://www.rfc-editor.org/info/rfc3325>.
+
+
+
+
+Holmberg, et al. Standards Track [Page 11]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+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 UE Registers via P-CSCF
+
+ The Visited Proxy (P-CSCF) adds the 'iotl' value 'homeb-visitedb' to
+ the Path header field of the REGISTER request to be used for
+ terminating routing towards Alice. The Home Proxy (S-CSCF) adds the
+ 'iotl' value 'visiteda-homea' to the Service-Route header 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>
+
+
+
+Holmberg, et al. Standards Track [Page 12]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+ 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 UE Registers via P-CSCF
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 13]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+A.3. Originating IMS Call
+
+ In the originating INVITE request from Alice, the 'iotl' value
+ 'visiteda-homea', received in the Service-Route header field during
+ registration, is added to the Route header field representing the
+ Home Proxy (S-CSCF) to indicate the traffic leg type between the
+ Visited Proxy (P-CSCF) and the Home Proxy (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: Originating IP Multimedia Subsystem (IMS) Call
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 14]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+A.4. Terminating IMS Call
+
+ In the terminating INVITE request towards Alice, the 'iotl' value
+ 'homeb-visitedb' provided to the Home Proxy (S-CSCF) during
+ registration is added to the Route header field representing the
+ Visited Proxy (P-CSCF) to indicate the traffic leg type between the
+ Home Proxy (S-CSCF) and the Visited Proxy (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 IMS Call
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 15]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+A.5. Call between Originating Home and Terminating Home Network
+
+ The S-CSCF of the originating home network adds the 'iotl' value
+ 'homea-homeb' in the Request-URI of the INVITE, sent towards the
+ S-CSCF of the terminating 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 between Originating Home and Terminating Home Network
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 16]
+
+RFC 7549 3GPP 'iotl' May 2015
+
+
+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
+ Finland
+
+ EMail: christer.holmberg@ericsson.com
+
+
+ Jan Holm
+ Ericsson
+ Kistavagen 25
+ Stockholm16480
+ Sweden
+
+ EMail: jan.holm@ericsson.com
+
+
+ Roland Jesske
+ Deutsche Telekom
+ Heinrich-Hertz-Strasse 3-7
+ Darmstadt 64307
+ Germany
+
+ Phone: +4961515812766
+ EMail: r.jesske@telekom.de
+
+
+ Martin Dolly
+ AT&T
+ 718 Clairmore Ave
+ Lanoka Harbor 08734
+ United States
+
+ EMail: md3135@att.com
+
+
+
+
+
+
+Holmberg, et al. Standards Track [Page 17]
+