Network Working Group
Internet Engineering Task Force (IETF)                       C. Holmberg
Internet-Draft
Request for Comments: 7549                                       J. Holm
Intended status:
Category: Standards Track                                       Ericsson
Expires: August 23, 2015
ISSN: 2070-1721                                                R. Jesske
                                                        Deutsche Telekom
                                                                M. Dolly
                                                                     ATT
                                                       February 19,
                                                                    AT&T
                                                                May 2015

3rd-Generation Partnership Project (3GPP)

           3GPP SIP URI Inter Operator Inter-Operator Traffic Leg parameter
                  draft-holmberg-dispatch-iotl-06.txt Parameter

Abstract

   In 3rd-Generation Partnership Project (3GPP) 3GPP networks, the signalling signaling path between a calling user and a
   called user can be partioned partitioned into segments, referred to as traffic
   legs.  Each traffic leg may span networks belonging to different operators,
   operators and will have its own characteristics that can be different
   from other traffic legs in the same call.  A traffic leg might be
   associated with multiple SIP dialogs, e.g. e.g., in case a B2BUA which 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'. '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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum 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 six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on August 23, 2015.
   http://www.rfc-editor.org/info/rfc7549.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3   4
   2.  Applicability . . .  Conventions . . . . . . . . . . . . . . . . . . . . .   5
   3.  Traffic leg examples . . . .   6
   3.  Applicability . . . . . . . . . . . . . . . .   5
     3.1.  General . . . . . . . .   6
   4.  Traffic Leg Examples  . . . . . . . . . . . . . . . . .   5
     3.2.  Originating roaming call . . .   6
     4.1.  General . . . . . . . . . . . . .   5
     3.3.  Terminating roaming call . . . . . . . . . . . .   6
     4.2.  Originating Roaming Call  . . . .   5
     3.4.  Originating home to terminating home call . . . . . . . .   5
   4.  Conventions . . . .   6
     4.3.  Terminating Roaming Call  . . . . . . . . . . . . . . . .   7
     4.4.  Call from Originating Home to Terminating Home  . . . . .   6   7
   5.  iotl  'iotl' SIP URI parameter  . Parameter  . . . . . . . . . . . . . . . . . .   6   7
     5.1.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . .   6   7
     5.2.  Parameter Values  . . . . . . . . . . . . . . . . . . . .   7   8
       5.2.1.  General . . . . . . . . . . . . . . . . . . . . . . .   7   8
       5.2.2.  homea-homeb . . . . . . . . . . . . . . . . . . . . .   7   8
       5.2.3.  homeb-visitedb  . . . . . . . . . . . . . . . . . . .   7   8
       5.2.4.  visiteda-homea  . . . . . . . . . . . . . . . . . . .   7   9
       5.2.5.  homea-visiteda  . . . . . . . . . . . . . . . . . . .   8   9
       5.2.6.  visiteda-homeb  . . . . . . . . . . . . . . . . . . .   8   9
   6.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8  10
     6.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   8  10
     6.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   9  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9  10
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9  10
   9.  Acknowledgments . . . . .  References  . . . . . . . . . . . . . . . . . .   9
   10. Change Log . . . . . . .  11
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
   11.  11
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  11
   Appendix A.  3GPP Examples  . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . .  12
     A.1.  General . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  13
   Appendix A.  3GPP Examples . . . .  12
     A.2.  The UE Registers via P-CSCF . . . . . . . . . . . . . . .  13
     A.1.  General  12
     A.3.  Originating IMS Call  . . . . . . . . . . . . . . . . . .  14
     A.4.  Terminating IMS Call  . . . . . . .  13
     A.2.  The UE registers via P-CSCF . . . . . . . . . . . . . . .  13
     A.3.  15
     A.5.  Call between Originating IMS call  . . . . . . . . . . . . Home and Terminating Home
           Network . . . . . .  14
     A.4.  Terminating IMS call . . . . . . . . . . . . . . . . . .  15
     A.5.  Call between originating home and terminating home
           network .  16
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  16  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   In a 3rd-Generation Partnership Project (3GPP) 3GPP network, an end user end-user device can be attached (e.g. (e.g., using a
   radio access network) to its own operator network (home network) [TS.3GPP.24.229],
   [TS.3GPP.24.229] or to another operator's network (visited network)
   [TS.3GPP.24.229].  In the latter
   case 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 network networks act on
   the SIP level or on the IP level.

   In 3GPP networks, the signalling signaling path between a calling user and a
   called user can be partioned partitioned into segments, referred to as traffic
   legs.  Each traffic leg may span networks belonging to different
   operators,
   operators and will have its own characteristics that can be different
   from other traffic legs in the same call.  A traffic leg might be
   associated with multiple SIP dialogs, e.g. e.g., in case a Back-
   To-Back User Agent (B2BUA) B2BUA [RFC3261] which
   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, decisions related to e.g. to, e.g., media anchoring, signalling signaling
   policy, insertion of media functions (e.g. transcoder) (e.g., transcoder), and
   charging.

   The figure below shows two users (Alice and Bob) and the different
   type of networks that the signaling might traverse.  The signalling signaling
   path can be divided into multiple traffic legs, and the type of
   traffic legs depends on how the signalling signaling is routed.

   Alice -- ORIG HNW +++++ TRANSIT NW +++++ TERM HNW -- Bob
   Home           +     +                +    +   +    Home
                  +     ++++++++++++++++++    +   +
                  +                           +   +
                  +                           +   +
                  +     +++++++++++++++++++++++   +
                  +     +              +          +
   Alice -- ORIG VNW +++++ TRANSIT NW ++    TERM VNW -- Bob
   Visited                                           Visited

               Figure 1: 3GPP operator network roaming roles

   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 1, Alice is a user initiating communication with Bob, and: Bob. Also,
   consider the following information:

   Alice is attached to an originating network, which is either the home
   network of Alice, Alice or a visited network (in case Alice is roaming).  In
   both cases 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, Bob or a visited network (in case Bob is roaming).  In
   both cases cases, any terminating service is provided by the home network
   of Bob.

   A transit network, network providing transit functions (e.g. (e.g., translation of
   free phone numbers), 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 of Inter Operator 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).

   This document defines the following 'iotl' parameter values:

   o  homea-homeb

   o  homeb-visitedb

   o  visiteda-homea

   o  homea-visiteda

   o  visiteda-homeb

   SIP entities that do not support the SIP URI 'iotl' parameter will
   simply ignore it, if received, as defined in [RFC3261].

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

3.  Applicability

   The SIP URI 'iotl' parameter defined in this document has known uses
   in 3GPP networks.  Usage in other networks is also possible.

3.

4.  Traffic leg examples

3.1. Leg Examples

4.1.  General

   This section describes examples of different types of traffic legs in
   3GPP networks.

3.2.

4.2.  Originating roaming call 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
   signalling
   signaling path between the UA User Agent (UA) of Alice and the home S-CSCF [3GPP TS
   24.229]
   Serving Call Session Control Function (S-CSCF) [TS.3GPP.24.229] of
   Alice.

3.3.

4.3.  Terminating roaming call 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 signalling signaling path between the home S-CSCF of
   Bob and the UA of Bob.

3.4.

4.4.  Call from Originating home Home to terminating home call 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 signalling signaling path
   between the S-CSCFs represents one traffic leg (referred to as the
   'homea-homeb' traffic leg).

4.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

5.  iotl  'iotl' SIP URI parameter 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. (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,
   URI to indicate the type(s) of traffic leg.  Each parameter value
   indicates a type of traffic leg.

   For routing of an initial SIP request for a dialog, or a stand-alone
   SIP request, a SIP entity can add the 'iotl' parameter to (a) the SIP
   URI of the Request-URI [RFC3261], [RFC3261] or to (b) the SIP URI of a Route header
   field [RFC3261], of an initial request for a
   dialog, or [RFC3261] of an stand-alone 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], [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, 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  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;
   o  If  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  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, 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, dialogs or stand-
   alone requests, requests sent on the registration path.

   As defined in [RFC3261], a SIP proxy must not modify or remove uri 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.

5.2.2.  homea-homeb

   This value indicates that

   Note that, when a SIP entity responsible for 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.

   In 3GPP, this traffic leg is between the home S-CSCF and the UE User
   Equipment (UE) of the called user, 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, user or between the P-CSCF Proxy Call Session Control Function
   (P-CSCF) in the visited network, serving the calling user, user and the
   home S-CSCF of the calling user.

5.2.5.  homea-visiteda

   This value indicates that the SIP entity addressed by the SIP URI
   associated with the parameter represents the end of a traffic leg
   between the home network (originating) and the visited network
   (originating) in which the calling user is located.

   In 3GPP, this traffic leg is between the home S-CSCF of the calling
   user and the Transit and Roaming Function (TRF) [3GPP TS 24.229] [TS.3GPP.24.229]
   serving the calling user, 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
   Breakout (RAVEL) [3GPP TS 24.229] [TS.3GPP.24.229] feature is enabled.

5.2.6.  visiteda-homeb

   This value indicates that a SIP entity responsible for the host part
   of the SIP URI associated with the parameter represents the end of a
   traffic leg between the visited network (originating) of the calling
   user and the home network (terminating) of the called user.

   In 3GPP, this traffic leg is between the Transit and Roaming Function
   (TRF) [3GPP TS 24.229] TRF [TS.3GPP.24.229] serving
   the calling user and the home S-CSCF of the called user, 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 Roaming Architecture for Voice over IMS with Local
   breakout (RAVEL) [3GPP TS 24.229] RAVEL [TS.3GPP.24.229] feature
   is enabled.

6.  Syntax

6.1.  General

   This section defines the ABNF for the 'iotl' SIP URI parameter.  The
   ABNF defined in this specification is conformant to RFC 5234
   [RFC5234].

   This specification does not create an IANA registry for 'iotl'
   parameter values.  A registry should be considered if new parameter
   values are defined in the future.

6.2.  ABNF

   The ABNF [RFC5234] grammar for the role 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,
   there MUST exist an agreement between the operators for usage of the
   roaming role information.

   General security considerations for SIP are defined in [RFC3261]

8.  IANA Considerations

   [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this
   document.]  This specification adds one new value to the IANA
   registration in the "SIP/SIPS URI Parameters" registry as defined in
   [RFC3969].

         Parameter Name  Predefined Values  Reference
         ____________________________________________
                   iotl      Yes            [This RFC]

9.  Acknowledgments

   The authors wish to thank everyone in the 3GPP community that gave
   comments on the initial version of this document, and contributed
   with comments and suggestion during the work.  A special thanks to
   Paul Kyziwat, Dale Worley and Michael Hammer.  Robert Sparks
   performed the Gen-ARTreview of the draft.

10.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   draft-holmberg-dispatch-iotl-04

   o  Change based on IESG review from Stephen Farrell:

   o  - Editorial changes.

   draft-holmberg-dispatch-iotl-04

   o  Change based on IESG review from Spencer Dawkins:

   o  - List of defined iotl parameter values listed in the
      Introduction.

   o  - ABNF editorial fix.

   o  Change based on IESG review from Barry Leiba:

   o  - Only use lowercase when writing the iotl parameter values.

   o  Change based on IESG review from Alissa Cooper:

   o  - Sentence about usage in non-3GPP networks removed from the
      Introduction.

   o  - Editorial correction in the Security Considerations.

   o  Change based on IESG review from Benoit Claise:

   o  - 'iotl' parameter name abbreviation extented in the Introduction.

   o  Change based on IESG review from Kathleen Moriarty:

   o  - Reference to RFC 3261 added to the Security Considerations.

   o  Change based on IESG review from Stephen Farrell:

   o  - Additional text and explanation added to the Security
      Considerations.

   draft-holmberg-dispatch-iotl-03

   o  Change based on Gen-ART review from Robert Sparks:

   o  - Removed text saying that the mechanism is scoped for 3GPP
      networks only.

   o  - Clarify that entities that do not support the parameter will
      ignore it.

   o  - Clarify that the draft does not create an IANA registry for
      parameter values.

   o  - Remove sentence regarding directionality.

   o  - Reference to RFC 3327 added.

   o  - Reference to RFC 3608 added.

   o  - 'dialogue' -> 'dialog'.

   o  Change based on Ops-ART review from Nevil Brownlee:

   o  - Reference to RFC 3261 added to 'B2BUA'.

   o  - Reference to 3GPP TS 24.229 added for 'S-CSCF'.

   draft-holmberg-dispatch-iotl-02

   o  Change based on comments from Richard Barnes:

   o  - 3GPP scope text modified.

   o  - Reference to 3GPP TS 24.229 added.

   o  - Reference to RFC 3325 added, and incorporated into the Security
      Considerations.

   o  - 'iotl' selection procedure made into a bullet list.

   draft-holmberg-dispatch-iotl-01

   o  Scope the SIP URI 'iotl' parameter to 3GPP, based on decision at
      IETF#90:

   o  - Document name changed.

   o  - Clarified that usage of cause user
   billing or service failure, the parameter is SHOULD only defined within
      3GPP networks.

   draft-holmberg-dispatch-iotl-00
   o  Added text be used for
   making policy decisions based on how to identify the traffic leg type when SIP-URIs
      of multiple Route header fields and/or role by nodes within the Request-URI contain an
      'iotl' parameter.

   o  Clarify that a traffic leg might span over multiple SIP dialogs.

   o  Added text saying that same
   trust domain [RFC3325], and network boundary entities supporting the 'iotl' parameter
      must not remove a parameter MUST NOT
   forward information received from a request, if untrusted entities.  In addition,
   an agreement MUST exist between the parameter is
      associated with a operators for usage of the
   roaming role information.

   General security considerations for SIP URI belonging to another entity.

   o  Modified ABNF, are defined in order [RFC3261]

8.  IANA Considerations

   Per this specification, IANA has added one new value to allow multiple the "SIP/SIPS
   URI Parameters" registry as defined in [RFC3969].

         Parameter Name  Predefined Values  Reference
         ____________________________________________
                   iotl values for a single
      URI.

   o  In IANA section, changed indication that predefined values exist.

   o  Example call flows added.

11.      Yes            RFC 7549

9.  References

11.1.

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997. 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. 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. 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. 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. 2004,
              <http://www.rfc-editor.org/info/rfc3969>.

   [RFC5234]  Crocker, D. D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008. 2008,
              <http://www.rfc-editor.org/info/rfc5234>.

   [TS.3GPP.24.229]
              3GPP, "Vocabulary for 3GPP Specifications", 3GPP TS 24.229
              12.6.0, September 2014.

11.2.

9.2.  Informative References

   [RFC3325]  Jennings, C., Peterson, J., and M. Watson, "Private
              Extensions to the Session Initiation Protocol (SIP) for
              Asserted Identity within Trusted Networks", RFC 3325,
              DOI 10.17487/RFC3325, November 2002. 2002,
              <http://www.rfc-editor.org/info/rfc3325>.

Appendix A.  3GPP Examples

A.1.  General

   This section contains example call flows based on 3GPP usage of the
   SIP URI 'iotl' parameter.

A.2.  The UE registers Registers via P-CSCF

   The Visited Proxy (P-CSCF) adds the iotl 'iotl' value 'homeb-visitedb' to
   the Path header field of the REGISTER request, request to be used for
   terminating routing towards Alice.  The Home Proxy (S-CSCF) adds the
   iotl
   'iotl' value 'visiteda-homea' to the Service-Route header field, field to be
   used for originating initial/stand-alone requests from Alice.

             Visited Proxy    Visited Proxy      Home Proxy   Home Proxy
Alice's . . . . P-CSCF . . . . .  IBCF-V . . . . . IBCF-H . . . . S-CSCF
  |                |                |                |                |
  |   REGISTER F1  |                |                |                |
  |--------------->|   REGISTER F2  |                |                |
  |                |--------------->|   REGISTER F3  |                |
  |                |                |--------------->|  REGISTER F4   |
  |                |                |                |--------------->|
  |                |                |                |                |
  |                |                |                |  200 (OK) F5   |
  |                |                |                |<---------------|
  |                |                |  200 (OK) F6   |                |
  |                |                |<---------------|                |
  |                |  200 (OK) F7   |                |                |
  |                |<---------------|                |                |
  |  200 (OK) F8   |                |                |                |
  |<---------------|                |                |                |

   F1 REGISTER Alice -> P-CSCF
   REGISTER sip:registrar.home1.net SIP/2.0

   F2 REGISTER P-CSCF -> IBCF-V
   REGISTER sip:registrar.home1.net SIP/2.0
   Path: <p-cscf URI;iotl=homeb-visitedb>

   F3 REGISTER IBCF-V -> IBCF-H
   REGISTER sip:registrar.home1.net SIP/2.0
   Path: <p-cscf URI;iotl=homeb-visitedb>

   F4 REGISTER IBCF-H -> S-CSCF
   REGISTER sip:registrar.home1.net SIP/2.0
   Path: <p-cscf URI;iotl=homeb-visitedb>
   F5 200 OK S-CSCF -> IBCF-H
   200 OK
   Path: <p-cscf URI;iotl=homeb-visitedb>
   Service-Route: <s-cscf URI;iotl=visiteda-homea>

   F6 200 OK IBCF-H -> IBCF-V
   200 OK
   Path: <p-cscf URI;iotl=homeb-visitedb>
   Service-Route: <s-cscf URI;iotl=visiteda-homea>

   F7 200 OK IBCF-V -> P-CSCF
   200 OK
   Path: <p-cscf URI;iotl=homeb-visitedb>
   Service-Route: <s-cscf URI;iotl=visiteda-homea>

   F8 200 OK P-CSCF -> Alice
   200 OK
   Path: <p-cscf URI;iotl=homeb-visitedb>
   Service-Route: <s-cscf URI;iotl=visiteda-homea>

                   Figure 2: The UE registers Registers via P-CSCF

A.3.  Originating IMS call Call

   In the originating INVITE request from Alice, the iotl '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, (S-CSCF) to indicate the traffic leg type between the
   Visited Proxy P-CSCF (P-CSCF) and the Home Proxy S-CSCF. (S-CSCF).

             Visited Proxy    Visited Proxy      Home Proxy   Home Proxy
Alice's . . . . P-CSCF . . . . .  IBCF-V . . . . . IBCF-H . . . . S-CSCF
  |                |                |                |                |
  |   INVITE F1    |                |                |                |
  |--------------->|   INVITE F2    |                |                |
  |                |--------------->|   INVITE F3    |                |
  |                |                |--------------->|   INVITE F4    |
  |                |                |                |--------------->|
  |                |                |                |                |
  |                |                |                |    180   F5    |
  |                |                |    180   F6    |<---------------|
  |                |    180   F7    |<---------------|                |
  |    180   F8    |<---------------|                |                |
  |<---------------|                |                |                |
  |                |                |                |                |

   F1 INVITE Alice -> P-CSCF
   INVITE sip:Bob@homeb.net SIP/2.0
   Route: <p-cscf URI>,<s-cscf URI;iotl=visiteda-homea>

   F2 INVITE P-CSCF -> IBCF-V
   INVITE sip:Bob@homeb.net SIP/2.0
   Route: <ibcf-v URI>,<s-cscf URI;iotl=visiteda-homea>

   F3 INVITE IBCF-V -> IBCF-H
   INVITE sip:Bob@homeb.net SIP/2.0
   Route: <ibcf-h URI>,<s-cscf URI;iotl=visiteda-homea>

   F4 INVITE IBCF-H -> S-CSCF
   INVITE sip:Bob@homeb.net SIP/2.0
   Route: <s-cscf URI;iotl=visiteda-homea>

         Figure 3: Originating IMS call IP Multimedia Subsystem (IMS) Call

A.4.  Terminating IMS call Call

   In the terminating INVITE request towards Alice, the iotl 'iotl' value
   'homeb-visitedb',
   'homeb-visitedb' provided to the Home Proxy S-CSCF (S-CSCF) during
   registration,
   registration is added to the Route header field representing the
   Visited Proxy P-CSCF, (P-CSCF) to indicate the traffic leg type between the
   Home Proxy S-CSCF (S-CSCF) and the Visited Proxy P-CSCF. (P-CSCF).

Home Proxy    Home Proxy      Visited Proxy     Visited Proxy
S-CSCF  . . . . IBCF-H . . . . .  IBCF-V . . . . . P-CSCF . . . . .  Bob
  |                |                |                |                |
  |   INVITE F1    |                |                |                |
  |--------------->|   INVITE F2    |                |                |
  |                |--------------->|   INVITE F3    |                |
  |                |                |--------------->|   INVITE F4    |
  |                |                |                |--------------->|
  |                |                |                |                |
  |                |                |                |    180   F5    |
  |                |                |    180   F6    |<---------------|
  |                |    180   F7    |<---------------|                |
  |    180   F8    |<---------------|                |                |
  |<---------------|                |                |                |
  |                |                |                |                |

   F1 INVITE S-CSCF -> IBCF-H
   INVITE sip:Bob@visitedb.net SIP/2.0
   Route: <ibcf-h URI>,<p-cscf-v URI;iotl=homeb-visitedb

   F2 INVITE IBCF-H -> IBCF-V
   INVITE sip:Bob@visitedb.net SIP/2.0
   Route: <ibcf-v URI>,<p-cscf-v URI;iotl=homeb-visitedb

   F3 INVITE IBCF-V -> P-CSCF
   INVITE sip:Bob@visitedb.net SIP/2.0
   Route: <p-cscf-v URI;iotl=homeb-visitedb

   F4 INVITE P-CSCF -> Bob
   INVITE sip:Bob@visitedb.net SIP/2.0

                      Figure 4: Terminating IMS call Call

A.5.  Call between originating home Originating Home and terminating home network Terminating Home Network

   The S-CSCF of the originating home network adds the iotl 'iotl' value
   'homea-homeb' in the Request-URI of the INVITE, sent towards the
   S-CSCF of the terminating network, 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 Originating Home and terminating home network Terminating Home Network

Acknowledgements

   The authors wish to thank everyone in the 3GPP community that gave
   comments on the initial version of this document and contributed with
   comments and suggestions during the work.  A special thanks to Paul
   Kyziwat, Dale Worley, and Michael Hammer.  Robert Sparks performed
   the Gen-ART review of the document.

Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email:

   EMail: christer.holmberg@ericsson.com

   Jan Holm
   Ericsson
   Kistavagen 25
   Stockholm16480
   Sweden

   Email:

   EMail: jan.holm@ericsson.com

   Roland Jesske
   Deutsche Telekom
   Heinrich-Hertz-Strasse 3-7
   Darmstadt  64307
   Germany

   Phone: +4961515812766
   Email:
   EMail: r.jesske@telekom.de

   Martin Dolly
   ATT
   AT&T
   718 Clairmore Ave
   Lanoka Harbor  08734
   USA

   Email:
   United States

   EMail: md3135@att.com