3GPP SIP URI Inter-Operator Traffic Leg Parameter
Extracted elements (20)
Multiple 'iotl' values can be combined using dot notation in a single parameter (e.g., 'iotl=homea-homeb.visiteda-homea'), allowing a single SIP URI to indicate that the entity represents the end of multiple traffic legs simultaneously.
The 'iotl' parameter enables intermediary entities to make policy decisions related to media anchoring, signaling policy, insertion of media functions (e.g., transcoders), and charging based on the type of inter-operator traffic leg in the signaling path.
This specification intentionally does not create an IANA registry for 'iotl' parameter values; a registry should be considered only if new parameter values are defined in the future, keeping the initial scope minimal.
SIP entities that do not support the SIP URI 'iotl' parameter will simply ignore it if received, as defined in RFC 3261, ensuring backward compatibility with existing SIP implementations.
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 the SIP request for routing of initial dialog or stand-alone requests.
As defined in RFC 3261, a SIP proxy must not modify or remove URI parameters from SIP URIs associated with other entities; this also applies to the 'iotl' parameter.
During SIP registration, entities can add the 'iotl' parameter to Path or Service-Route header field SIP URIs if the entity is aware the SIP URI will indicate the end of a specific traffic leg for subsequent initial requests or stand-alone requests on the registration path.
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 request contains multiple Route header fields with 'iotl' parameters, the 'iotl' parameter associated with the topmost Route header field SIP URI (or the closest to topmost if the topmost lacks 'iotl') identifies the type of traffic leg.
The 'homea-homeb' value indicates that the SIP entity responsible for the host part of the associated SIP URI represents the end of a traffic leg between the originating home network and the terminating home network; in 3GPP, this is between two S-CSCFs.
The 'homea-visiteda' value indicates the end of a traffic leg between the originating home network and the originating visited network; in 3GPP, this is between the home S-CSCF and the TRF serving the calling user, used in RAVEL scenarios.
The 'homeb-visitedb' value indicates that the addressed SIP entity represents the end of a traffic leg between the terminating home network and the terminating visited network where the called user is located; in 3GPP, this is between the home S-CSCF and the UE or SCC AS to ATCF.
The 'iotl' (Inter-Operator Traffic Leg) SIP URI parameter indicates that the entity associated with a SIP URI, or an entity responsible for its host part, represents the end of a specific traffic leg or multiple traffic legs in 3GPP networks.
The 'iotl' parameter defines five values: 'homea-homeb' (originating home to terminating home), 'homeb-visitedb' (terminating home to terminating visited), 'visiteda-homea' (originating visited to originating home), 'homea-visiteda' (originating home to originating visited), and 'visiteda-homeb' (originating visited to terminating home).
The 'visiteda-homea' value indicates that the SIP entity responsible for the host part represents the end of a traffic leg between the originating visited network and the originating home network; in 3GPP, this is between the UE and home S-CSCF or P-CSCF to home S-CSCF.
The 'visiteda-homeb' value indicates that the SIP entity responsible for the host part represents the end of a traffic leg between the originating visited network and the terminating home network; in 3GPP, this is between the TRF and the home S-CSCF of the called user in RAVEL scenarios.
IANA added one new value 'iotl' to the 'SIP/SIPS URI Parameters' registry (defined in RFC 3969), with predefined values set to 'Yes' and reference to RFC 7549.
An agreement MUST exist between operators for usage of the roaming role information conveyed in the 'iotl' parameter, as the information is used for policy decisions related to charging and service triggering.
The 'iotl' parameter SHOULD only be used for policy decisions by nodes within the same trust domain (per RFC 3325), and network boundary entities MUST NOT forward 'iotl' information received from untrusted entities, to prevent abuse affecting user billing or service availability.
The ABNF grammar defines 'iotl-param' as: iotl-tag '=' iotl-value ['.' iotl-value], where iotl-tag is the literal string 'iotl' and iotl-value is one of the five named values or an 'other-iotl' composed of alphanumeric characters and hyphens.