SIP URI Inter Operator Traffic Leg parameter

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 divided into smaller parts, 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. 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.

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

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

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.

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.

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

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 .

As specified in , 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 a traffic leg, the SIP entity inserting the SIP URI can add a SIP URI 'iotl' parameter to the SIP URI, to indicate the type of traffic leg. For routing of a SIP request, a SIP entity can add the 'iotl' parameter to the SIP URI of the Request-URI , or to the SIP URI of a Route header field , of an initial request for a dialog, or of an stand-alone request. During SIP registration , 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. This document does not specify the usage of the 'iotl' parameter within a SIP URI of a Record-Route header field .

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

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.

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.

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.

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.

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.

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

The ABNF grammar for the role SIP URI parameter is:

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.

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

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

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