5.6 Procedures at the BGCF

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

5.6.1 General

The use of the Path and Service-Route header fields shall not be supported by the BGCF.

For all SIP transactions identified:

– if priority is supported, as containing an authorised Resource-Priority header field, or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;

the BGCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the MGCF shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.

NOTE: The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact meaning of priority is not defined further in this document, but is left to national regulation and network configuration.

When the BGCF receives any request or response related to a dialog or standalone transaction, the BGCF may insert previously saved values into a P-Charging-Vector header field before forwarding the message.

When the BGCF receives any request or response (excluding ACK requests and CANCEL requests and responses) related to a dialog or standalone transaction, the BGCF may insert previously saved values into a P-Charging-Function-Addresses header field before forwarding the message.

With the exception of 305 (Use Proxy) responses, the BGCF may recurse on a 3xx response only when the domain part of the URI contained in the 3xx response is in the same domain as the BGCF. For the same cases, if the URI is an IP address, the BGCF shall only recurse if the IP address is known locally to be a address that represents the same domain as the BGCF.

The BGCF shall log all SIP requests and responses that contain a "logme" header field parameter in the SIP Session-ID header field if required by local policy.

When sending a failure response to any received request, depending on operator policy, the BGCF may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "bgcf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17.

5.6.2 Common BGCF procedures

When determining where to route the received request, the originating BGCF may use the information obtained from other protocols or any other available databases.

The BGCF may support retrieval of NP data as part of the procedures to determine where to route the request. Retrieval of NP data by the BGCF is subject to local policy. Retrieval of NP data is relevant only if the Request-URI contains an international public telecommunications number. The interface used at the BGCF to retrieve the NP data is out of scope of this specification. If the Request-URI contains a tel-URI with an "npdi" tel-URI parameter, as defined in RFC 4694 [112], NP data has been obtained previously and NP data retrieval is only performed if required by local policy. If NP data is retrieved by the BGCF, the BGCF shall add the tel-URI NP parameters to the Request-URI as defined in RFC 4694 [112]: an "npdi" tel-URI parameter is added to indicate that NP data retrieval has been performed, and if the number is ported, an "rn" tel-URI parameter is added to identify the ported-to routeing number. The "rn" tel-URI parameter may be used by the BGCF for routeing the request.

The BGCF NP procedures also apply when the request contains a Request-URI in the form of a SIP URI user=phone, where the "npdi" and "rn" tel-URI parameters are contained in the userinfo part of the SIP URI.

When the BGCF receives a request, the BGCF shall forward the request:

– to an MGCF within its own network; or

– to another network containing a BGCF, or I-CSCF; or

– where the request is for another network, to an IBCF in its own network, if local policy requires IBCF capabilities towards another network; or

– where the Ici interface is used to interconnect two networks and the destination network is beyond such interface, to an IBCF in its own network..

When forwarding the request to the next hop, the BGCF may leave the received Request-URI unmodified.

If the request is not routed to a BGCF or to an entity that implements the additional routeing functionality, the BGCF shall remove the P-Served-User header field prior to forwarding the request.

When the BGCF receives a request and the Request-URI contains a tel URI in local number format or a SIP URI with the user part not starting with a + and the "user" SIP URI parameter equals "phone", the BGCF shall not forward the request to an entity in another network (e.g. BGCF, I-CSCF) unless the local policy (e.g. routeing of service numbers) requires forwarding the request outside the network. If local policy does not allow forwarding the request outside the network and additional routeing capabilities as defined in annex I are locally available, the BGCF shall attempt translation of the local number. If the translation fails, the BGCF shall send an appropriate SIP response to the originator. If local policy does not allow forwarding the request outside the network and additional routeing capabilities as defined in annex I are not locally available, the BGCF shall either:

– forward the request to any appropriate entity in its own network where additional routeing functionality are available; or

– send an appropriate SIP response to the originator.

The BGCF need not Record-Route the INVITE and the SUBSCRIBE requests. While the next entity may be a MGCF acting as a UA, the BGCF shall not apply the procedures of RFC 3323 [33] relating to privacy. The BGCF shall store the values received in the P-Charging-Function-Addresses header field. The BGCF shall store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and retain the "icid-value" header field parameter in the P-Charging-Vector header field.

NOTE 1: The means by which the decision is made to forward to an MGCF or to another network is outside the scope of the present document, but can be by means of a lookup to an external database, or can be by data held internally to the BGCF.

If the BGCF supports carrier routeing, then the BGCF shall support the following procedures, based on local policy:

a) if the BGCF is configured to populate an operator configured preassigned carrier into a tel-URI contained in the Request-URI, and a preassigned carrier is required for this call, then the BGCF shall include the "cic" tel-URI parameter in the Request-URI identifying the preassigned carrier (as described in RFC 4694 [112]); or

b) if the BGCF is configured to populate the freephone carrier ID, and a freephone carrier is required for this call, then the BGCF shall include the "cic" tel-URI parameter in the Request-URI identifying the freephone carrier (as described in RFC 4694 [112]).

The BGCF carrier routeing procedures also apply when the Request-URI is in the form of a SIP URI user=phone, where the "cic" tel-URI parameter is contained in the userinfo part of the SIP URI.

The BGCF shall not add the "cic" tel-URI parameter in the Request-URI if the parameter already exists in the tel-URI.

NOTE 2: Local policy should be able to control the interaction and precedence between routeing on "cic" parameter versus routeing based on "rn" parameter.

NOTE 3: The means to configure the BGCF with the pre-assigned carrier is outside the scope of this document.

If

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

b) an "iotl" SIP URI parameter is not already included in the Request-URI; and

NOTE 4: 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;

the BGCF shall before forwarding the request:

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 that can be converted to a SIP URI by the BGCF:

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

NOTE 5: If the "iotl" SIP URI parameter can not be included by the above procedure, the upstream nodes have to determine the II-NNI traversal scenario by analysing the content of the SIP request (implementation dependent) or using the default II-NNI traversal scenario type.

5.6.3 Specific procedures for INVITE requests and responses

When the BGCF receives an INVITE request that contains a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter, the BGCF shall decide based on local policy whether to perform loopback routeing for this request. The BGCF shall:

a) if loopback routeing is not to be performed for this request remove any "+g.3gpp.trf" or "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;

b) if loopback routeing is applied for this request:

i) remove all entries in the Route header field;

ii) if a "+g.3gpp.trf" header field parameter with a parameter value containing a valid URI, is included in the Feature-Caps header field of the request, insert the URI in a Route header field;

iii) if a "+g.3gpp.trf" header field parameter, with a parameter value containing a valid URI is not included in the Feature-Caps header field of the request, insert a locally configured TRF address, associated with the visited network for this call (as identified in the "+g.3gpp.home-visited" header field parameter), in the Route header field;

iv) remove any "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;

v) if included in the incoming request, remove the "+g.3gpp.trf" header field parameter from the Feature-Caps header field from the outgoing request;

vi) insert the "+g.3gpp.loopback" header field parameter, as specified in subclause 7.9A.4 in the Feature-Caps header field of the request, in accordance with RFC 6809 [190]. If providing the identifier of the home network is supported by the BGCF and the visited network, the BGCF may based on operator agreement insert the "+g.3gpp.loopback" header field parameter set to the identifier of the home network;

vii) remove the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present. The BGCF shall insert a type 1 "orig-ioi" header field parameter into the P-Charging-Vector header field and shall set the type 1 "orig-ioi" header field parameter to a value that identifies the home network of the served user (i.e. the network in which the BGCF resides). The BGCF shall not include the "term-ioi" header field parameter; and

viii) if the BGCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 [225] and if an "iotl" SIP URI parameter is not included in the TRF URI in the Route header field, the BGCF if required by local policy, append an "iotl" URI parameter with a value set to "homeA-visitedA" to the URI in the Route header field; and

c) if the final decision on loopback routeing is deferred to a subsequent entity in the home network, a further BGCF, then, retain in the request a Feature-Caps header field with the "+g.3gpp.home-visited" header field parameter with the parameter value set to the identifier of the visited network. The BGCF is expected to know by means of network configuration that such a subsequent entity exists;

If the BGCF inserts its own Record-Route header field, the BGCF may require the periodic refreshment of the session to avoid hung states in the BGCF. If the BGCF requires the session to be refreshed, the BGCF shall apply the procedures described in RFC 4028 [58] clause 8.

NOTE: Requesting the session to be refreshed requires support by at least one of the UEs. This functionality cannot automatically be granted, i.e. at least one of the involved UEs needs to support it.

If overlap signalling using the multiple-INVITE method is supported as a network option, several INVITE requests with the same Call ID and the 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 BGCF shall route such INVITE request received during a certain period of time to the same next hop.

If the BGCF inserted in the initial request for the dialog the header field parameters into the Feature-Caps header field then the BGCF shall include the header field parameters with the same parameter values into the Feature-Caps header field in any target refresh request for the dialog, and in each 1xx or 2xx response to target refresh request sent in the same direction.

Based on local policy, the BGCF shall add an "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field with its own address or identifier to an initial request.

5.6.4 Specific procedures for subsequent requests and responses

When the BGCF receives a subsequent request whose initial request applied loopback routeing, the BGCF shall:

a) remove the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present. The BGCF shall insert a type 1 "orig-ioi" header field parameter into the P-Charging-Vector header field and shall set the type 1 "orig-ioi" header field parameter to a value that identifies the home network of the served user (i.e. the network in which the BGCF resides). The BGCF shall not include the "term-ioi" header field parameter.