doc: Add RFC documents

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]
+