I.2 Originating, transit and interconnection routeing procedures

24.2293GPPIP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP)Release 18Stage 3TS

The additional routeing functionality, or associated functional entity, performing these additional routeing procedures should analyse the destination address, and determine whether to route to another network, directly, or via the IBCF, or to the BGCF, the MGCF or the I-CSCF in its own network. This analysis may use public (e.g., DNS, ENUM) and/or private database lookups, and/or locally configured data and may, based on operator policy, modify the Request-URI (e.g. to remove number prefixes, to translate local numbers to global numbers, to update the Request-URI with the URI including an obtained ported-to routeing number, etc).

In addition, and based upon local policy, the analysis may include the carrier identified by the "cic" tel-URI parameter of the Request-URI and other signalling information from the incoming request as part of the route determination. Examples of other signalling information are: the content of the P-Access-Network-Info header field, the value of the "cpc" tel URI parameter of the P-Asserted-Identity header field, the value of the "phone-context" Tel URI parameter of the Request-URI, the SDP content, the ICSI values in the Contact header field and the content of the P-Asserted-Service header field.

If the additional routeing functionality decides that the request shall be routed via a specific entity (e.g. IBCF), it shall insert the URI of this entity in the Route header of the request.

When provided as a stand-alone entity, the network element performing these functions need not Record-Route the INVITE request.

When provided as a stand-alone entity, the network element performing these functions shall not apply the procedures of RFC 3323 [33] relating to privacy.

If overlap signalling using the multiple-INVITE method is supported as a network option, several INVITE requests with the same Call ID and same From header field (including "tag" header field parameter) can be received outside of an existing dialog. Such INVITE requests relate to the same call and the additional routeing function shall route such INVITE request received during a certain period of timeto the same next hop.

When colocated with a MGCF, based on local policy for calls originated from circuit-switched networks, if the circuit-switched is a transit network the additional routeing function shall add in requests in the P-Charging-Vector header field a "transit-ioi" header field parameter with an entry which identifies the PSTN network which the request was transitting or with a void entry.

NOTE 1: Only one "transit-ioi" header field parameter entry is added per transit network.

NOTE 2: The local policy can take bilateral agreements between operators into consideration.

The entity implementing the additional routeing functionality shall remove the P-Served-User header field prior to forwarding the request.

If

a) the additional routeing functionality supports indicating the traffic leg as specified in RFC 7549 [225];

b) the Request-URI does not already include an "iotl" SIP URI parameter, and

NOTE 3: If an "iotl" SIP URI parameter is included it contains the value "visitedA-homeB" inserted by the TRF in the roaming architecture for voice over IMS with local breakout scenario.

c) required by local policy;

then the additional routeing functionality shall:

a) if the Request-URI contains a SIP URI, append the "iotl" SIP URI parameter set to "homeA-homeB" to the Request-URI; and

b) if the Request-URI contains a tel URI:

– convert the tel URI in the Request-URI to the form of a SIP URI with user=phone; and

– append an "iotl" SIP URI parameter with a value set to "homeA-homeB" in the Request-URI.