Content for  TS 24.229  Word version:  19.0.0

The MGCF, although acting as a UA, does not initiate any registration of its associated addresses. These are assumed to be known by peer-to-peer arrangements within the IM CN subsystem. Therefore Table A.4/1 and dependencies on that major capability shall not apply. The use of the Path and Service-Route header fields shall not be supported by the MGCF. 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 MGCF 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. When the MGCF sends any request or response related to a dialog, the MGCF may insert previously saved values into P-Charging-Vector and P-Charging-Function-Addresses header fields before sending the message. The MGCF shall use a GRUU referring to itself (as specified in RFC 5627) when inserting a contact address in a dialog establishing or target refreshing SIP message. This specification does not define how GRUUs are created by the MGCF; they can be provisioned by the operator or obtained by any other mechanism. A GRUU used by the MGCF when establishing a dialog shall remain valid for the lifetime of the dialog. The GRUU used by the MGCF shall not reveal calling party related information. The MGCF shall handle requests addressed to its currently valid GRUUs when received outside of the dialog in which the GRUU was provided. The MGCF may support retrieval of NP data, subject to local policy. The interface used at the MGCF to retrieve the NP data is out of scope of this specification. Retrieval of NP data is relevant only if the Request-URI contains an international public telecommunications number. For requests from the IM CN subsystem network, if the Request-URI contains a tel-URI with an "npdi" tel-URI parameter, as defined in RFC 4694, NP data has been obtained previously and NP data retrieval is not needed, but still may still be performed if required by local policy. If NP data is retrieved by the MGCF, and the request is routed to the IM CN subsystem, the MGCF shall add the tel-URI NP parameters to the Request-URI as defined in RFC 4694: 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 MGCF 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. The MGCF supports as a network option the inclusion of the XML MIME schema for PSTN. In cases where the XML MIME for PSTN is included the Content-Type header field is set to "application/vnd.etsi.pstn+xml" and the Content-Disposition to "signal" with the "handling" parameter set to "optional". The MGCF 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 MGCF 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 "mgcf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17.

Void.

When the MGCF responds to an OPTIONS request with a 200 (OK) response, the MGCF may include a message body with an indication of the DTMF capabilities and supported codecs of the MGCF/MGW.

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

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, 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: 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 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. If the BGCF supports carrier routeing, then the BGCF shall support the following procedures, based on local policy:

1. 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); or
2. 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).

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

1. the BGCF supports indicating the traffic leg as specified in RFC 7549;
2. an "iotl" SIP URI parameter is not already included in the Request-URI; and
3. 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.

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:

1. 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;
2. if loopback routeing is applied for this request:
   1. remove all entries in the Route header field;
   2. 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;
   3. 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;
   4. remove any "+g.3gpp.home-visited" header field parameter from the Feature-Caps header field of the outgoing request;
   5. if included in the incoming request, remove the "+g.3gpp.trf" header field parameter from the Feature-Caps header field from the outgoing request;
   6. 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. 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;
   7. 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
   8. if the BGCF supports indicating the traffic leg associated with a URI as specified in RFC 7549 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
3. 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 Section 8 of RFC 4028. 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.

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

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