Skip to main content

SIP URI Inter Operator Traffic Leg parameter
draft-holmberg-dispatch-iotl-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7549.
Authors Christer Holmberg , Jan Holm , Roland Jesske , Martin Dolly
Last updated 2014-06-13
RFC stream (None)
Formats
Reviews
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 7549 (Proposed Standard)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-holmberg-dispatch-iotl-01
Network Working Group                                        C. Holmberg
Internet-Draft                                                   J. Holm
Intended status: Standards Track                                Ericsson
Expires: December 15, 2014                                     R. Jesske
                                                        Deutsche Telekom
                                                                M. Dolly
                                                                     ATT
                                                           June 13, 2014

              SIP URI Inter Operator Traffic Leg parameter
                  draft-holmberg-dispatch-iotl-01.txt

Abstract

   In telecommunication networks, the signalling path between a calling
   user and a called user can be partioned 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.  The
   directionality in traffic legs relates to a SIP request creating a
   dialogue and stand-alone SIP request.  A traffic leg might be
   associated with multiple SIP dialogs, e.g. in case a B2BUA which
   modifies the SIP dialog identifier is located within the traffic leg.

   This document defines a new SIP URI parameter, 'iotl', which 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 'iotl' parameter is defined in order to fulfil requirements from
   the 3rd-Generation Partnership Project (3GPP), but it can also be
   used in other network environments.

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 of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any

Holmberg, et al.        Expires December 15, 2014               [Page 1]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

   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 December 15, 2014.

Copyright Notice

   Copyright (c) 2014 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
   2.  Use-cases . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.2.  Originating roaming call  . . . . . . . . . . . . . . . .   5
     2.3.  Terminating roaming call  . . . . . . . . . . . . . . . .   5
     2.4.  Originating home to terminating home call . . . . . . . .   5
   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  iotl SIP URI parameter  . . . . . . . . . . . . . . . . . . .   5
     4.1.  Usage . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Parameter Values  . . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  General . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.2.  homeA-homeB . . . . . . . . . . . . . . . . . . . . .   7
       4.2.3.  homeB-visitedB  . . . . . . . . . . . . . . . . . . .   7
       4.2.4.  visitedA-homeA  . . . . . . . . . . . . . . . . . . .   7
       4.2.5.  homeA-visitedA  . . . . . . . . . . . . . . . . . . .   7
       4.2.6.  visitedA-homeB  . . . . . . . . . . . . . . . . . . .   8
   5.  Syntax  . . . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
   9.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   9
   10. Normative References  . . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  3GPP Examples  . . . . . . . . . . . . . . . . . . .  10
     A.1.  General . . . . . . . . . . . . . . . . . . . . . . . . .  10

Holmberg, et al.        Expires December 15, 2014               [Page 2]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

     A.2.  The UE registers via P-CSCF . . . . . . . . . . . . . . .  10
     A.3.  Originating IMS call  . . . . . . . . . . . . . . . . . .  11
     A.4.  Terminating IMS call  . . . . . . . . . . . . . . . . . .  12
     A.5.  Call between originating home and terminating home
           network . . . . . . . . . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   In a telecommunication network, an end user can be attached (e.g.
   using a radio access network) to its own operator network (home
   network), or to another operator's network (visited network).  In the
   latter case the user is referred to as a roaming user.

   Telecommunication operator networks are often not connected directly
   to each other.  Instead, there might be intermediate networks,
   referred to as transit networks, between them.  A transit network
   might act on a SIP level or on IP level.

   In telecommunication networks, the signalling path between a calling
   user and a called user can be partioned 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.  The
   directionality in traffic legs relates to a SIP request creating a
   dialogue and stand-alone SIP request.  A traffic leg might be
   associated with multiple SIP dialogs, e.g. in case a B2BUA which
   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, signalling
   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 signalling
   path can be divided into multiple traffic legs, and the type of
   traffic legs depends on how the signalling is routed.

Holmberg, et al.        Expires December 15, 2014               [Page 3]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

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

        Figure 1: Telecommunication operator network roaming roles

   ORIG HNW = Originating Home Network

   TERM HNW = Terminating Home Network

   ORIG VNW = Originating Visited Network

   TERM VNW = Terminating Visited Network

   In Figure 1 Alice is a user initiating communication with Bob, and:

   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',
   which 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 'iotl' parameter is defined in order to fulfil requirements from
   the 3rd-Generation Partnership Project (3GPP), but it can also be
   used in other network environments.

Holmberg, et al.        Expires December 15, 2014               [Page 4]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

2.  Use-cases

2.1.  General

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

2.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
   signalling path between the UA of Alice and the home S-CSCF of Alice.

2.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 signalling path between the home S-CSCF
   of Bob and the UA of Bob.

2.4.  Originating home to terminating home call

   In this case, the home S-CSCF of Alice forwards the initial SIP
   INVITE request towards the home S-CSCF of Bob. The signalling path
   between the S-CSCFs represents one traffic leg (referred to as the
   'homeA-homeB' traffic leg).

3.  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].

4.  iotl SIP URI parameter

4.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 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.

Holmberg, et al.        Expires December 15, 2014               [Page 5]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

   For routing of a SIP request, a SIP entity can add the 'iotl'
   parameter to the SIP URI of the Request-URI [RFC3261], or to the SIP
   URI of a Route header field [RFC3261], of an initial request for a
   dialog, or of an stand-alone request.

   If, within an initial request for a dialog, or within a stand-alone
   request, multiple Route header fields contain a SIP URI with a '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.

   If a SIP request contains an 'iotl' parameter both in the Request-URI
   SIP URI, and in one or more SIP-URIs of the Route header fields, 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.

   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 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.

   An entity that understands the 'iotl' parameter MUST NOT, from a SIP
   request, remove 'iotl' parameters from SIP URIs associated with other
   entities, unless the entity has means to determine that the 'iotl'
   parameter does not represent a valid traffic leg.

   This document does not specify the usage of the 'iotl' parameter
   within a SIP URI of a Record-Route header field [RFC3261].

4.2.  Parameter Values

4.2.1.  General

   This section describes the SIP URI 'iotl' parameter values defined in
   this specification.

Holmberg, et al.        Expires December 15, 2014               [Page 6]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

4.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.

4.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 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.

4.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 P-CSCF in the visited network,
   serving the calling user, and the home S-CSCF of the calling user.

4.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]
   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) [3GPP TS 24.229] feature is enabled.

Holmberg, et al.        Expires December 15, 2014               [Page 7]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

4.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 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] 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 Roaming Architecture for Voice over IMS with Local
   breakout (RAVEL) [3GPP TS 24.229] feature is enabled.

5.  Syntax

5.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].

5.2.  ABNF

   The ABNF [RFC5234] grammar for the role SIP URI parameter is:

 uri-parameter = transport-param / user-param / method-param / ttl-param
                 / maddr-param / lr-param / iotl-param / other-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

6.  Security Considerations

   There SHOULD exis a trust relationship between the networks that
   provide the roaming role and the networks that use the information
   for making policy decisions based on the role.  In addition, there
   MUST exist an agreement between the operators for usage of the
   roaming role information.

Holmberg, et al.        Expires December 15, 2014               [Page 8]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

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

8.  Acknowledgments

   The authors wish to thank everyone in the 3GPP community that gave
   comments on the initial version of this document.

9.  Change Log

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

   draft-holmberg-dispatch-iotl-00

   o  Added text on how to identify the traffic leg type when SIP-URIs
      of multiple Route header fields and/or the Request-URI contain an
      'iotl' parameter.

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

   o  Added text saying that entities supporting the 'iotl' parameter
      must not remove a parameter from a request, if the parameter is
      associated with a SIP URI beloning to another entity.

   o  Modified ABNF, in order to allow multiple iotl values for a single
      URI.

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

   o  Example call flows added.

10.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Holmberg, et al.        Expires December 15, 2014               [Page 9]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [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, December 2004.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

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

Holmberg, et al.        Expires December 15, 2014              [Page 10]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

   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 via P-CSCF

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.

Holmberg, et al.        Expires December 15, 2014              [Page 11]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

             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

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.

Holmberg, et al.        Expires December 15, 2014              [Page 12]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

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

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.

Holmberg, et al.        Expires December 15, 2014              [Page 13]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

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

Authors' Addresses

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com

Holmberg, et al.        Expires December 15, 2014              [Page 14]
Internet-DraftSIP URI Inter Operator Traffic Leg parameter     June 2014

   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
   ATT
   718 Clairmore Ave
   Lanoka Harbor  08734
   USA

   Email: md3135@att.com

Holmberg, et al.        Expires December 15, 2014              [Page 15]