    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]