3GPP SIP URI Inter-Operator Traffic Leg Parameter
EricssonHirsalantie 11Jorvas02420Finlandchrister.holmberg@ericsson.comEricssonKistavagen 25Stockholm16480Swedenjan.holm@ericsson.comDeutsche TelekomHeinrich-Hertz-Strasse 3-7Darmstadt64307Germany+4961515812766r.jesske@telekom.deAT&T718 Clairmore Ave08734Lanoka HarborUnited Statesmd3135@att.com
Transport
3GPPIMSNNIIOTLCSCFRAVELTRFoperatortransit
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.
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)
or to another operator's
network (visited network) .
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 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.
In , 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 , '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).
This document defines the following 'iotl' parameter values:
homea-homeb
homeb-visitedb
visiteda-homea
homea-visiteda
visiteda-homeb
SIP entities that do not support the SIP URI 'iotl' parameter will simply
ignore it, if received, as defined in .
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 .
The SIP URI 'iotl' parameter defined in this document has known uses
in 3GPP networks. Usage in other networks is also possible.
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 signaling path between the
User Agent (UA) of Alice and the home Serving
Call Session Control Function (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 signaling 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 signaling path between the S-CSCFs represents
one traffic leg (referred to as the 'homea-homeb' traffic leg).
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 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
or (b) the SIP URI of a Route header field
of the SIP request.
SIP entities can add the 'iotl' parameter to the SIP URI of a Path header field
or a Service-Route header
field 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:
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;
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
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 , 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 , a SIP proxy must
not modify or remove URI parameters from SIP URIs associated with other entities. This also
applies to the 'iotl' parameter.
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.
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 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.
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.
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)
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) feature is enabled.
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
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
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
.
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.
The ABNF
grammar for this SIP URI parameter is:
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 , 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
Per this specification, IANA has added one new value to
the "SIP/SIPS URI Parameters" registry as defined in
.
Vocabulary for 3GPP Specifications3GPP
This section contains example call flows based on 3GPP usage of the SIP URI
'iotl' parameter.
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.
| 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:
F3 REGISTER IBCF-V -> IBCF-H
REGISTER sip:registrar.home1.net SIP/2.0
Path:
F4 REGISTER IBCF-H -> S-CSCF
REGISTER sip:registrar.home1.net SIP/2.0
Path:
F5 200 OK S-CSCF -> IBCF-H
200 OK
Path:
Service-Route:
F6 200 OK IBCF-H -> IBCF-V
200 OK
Path:
Service-Route:
F7 200 OK IBCF-V -> P-CSCF
200 OK
Path:
Service-Route:
F8 200 OK P-CSCF -> Alice
200 OK
Path:
Service-Route:
]]>
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).
| 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: ,
F2 INVITE P-CSCF -> IBCF-V
INVITE sip:Bob@homeb.net SIP/2.0
Route: ,
F3 INVITE IBCF-V -> IBCF-H
INVITE sip:Bob@homeb.net SIP/2.0
Route: ,
F4 INVITE IBCF-H -> S-CSCF
INVITE sip:Bob@homeb.net SIP/2.0
Route:
]]>
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).
| 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-V
INVITE sip:Bob@visitedb.net SIP/2.0
Route: , P-CSCF
INVITE sip:Bob@visitedb.net SIP/2.0
Route: Bob
INVITE sip:Bob@visitedb.net SIP/2.0
]]>
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.
| 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
]]>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.