5.5 Procedures at the MGCF

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

5.5.1 General

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.

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 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 [93]) 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.

EXAMPLE: Upon receipt of an INVITE request addressed to a GRUU assigned to a dialog it has active, and containing a Replaces header field referencing that dialog, the MGCF will be able to establish the new call replacing the old one.

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 [112], 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 [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 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.

5.5.2 Subscription and notification

Void.

5.5.3 Call initiation

5.5.3.1 Initial INVITE

5.5.3.1.1 Calls originated from circuit-switched networks

When the MGCF receives an indication of an incoming call from a circuit-switched network, the MGCF shall:

1) generate an INVITE request:

– set the Request-URI to the "tel" format using an E.164 address or to the "sip" format using an E164 address in the user portion and set user=phone in accordance with 3GPP TS 29.163 [11B];

NOTE 1: Details how to set the host portion are out of scope of the document. However, when a SIP URI is used the host portion needs to be part of the domain name space owned by the I-CSCF

– include the "100rel" option tag in the Supported header field (as defined in RFC 3262 [27]);

– include the "precondition" option tag in the Supported header field (as defined in RFC 3312 [30] as updated by RFC 4032 [64]) if the MGCF supports the SIP preconditions mechanism;

– not indicate the requirement for the precondition mechanism by using the Require header field;

– create a new, globally unique value for the "icid-value" header field parameter and insert it into the P-Charging-Vector header field;

– insert a type 2 "orig-ioi" header field parameter into the P-Charging-Vector header field. The MGCF shall set the type 2 "orig-ioi" header field parameter to a value that identifies the sending network in which the MGCF resides and the type 2 "term-ioi" header field parameter shall not be included;

– based on local policy, add an "fe-addr" element of the "fe-identifier" header field parameter to the P-Charging-Vector header field with its own address or identifier; and

– if services that require knowledge of the adjacent network are provided within the network, based on operator policy, insert a Via "received-realm" header field parameter, as defined in RFC 8055 [208];

When the MGCF receives a 1xx or 2xx response to an initial request for a dialog, the MGCF shall store the value of the received "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.

NOTE 2: Any received "term-ioi" header field parameter will be a type 2 IOI. The type 2 IOI identifies the sending network of the response message.

Upon receiving a 199 (Early Dialog Terminated) provisional response to an established early dialog the MGCF shall release resources specifically related to that early dialog.

Based upon local policy, the MGCF may support preferred circuit carrier access (RFC 4694 [112]). If such routeing is applicable for the call, the MGCF shall perform the interworking of the carrier identification code from the circuit switched signalling protocol as described in 3GPP TS 29.163 [11B].

If resource priority in accordance with RFC 4412 [116] is required for a dialog, then the MGCF shall include the Resource-Priority header field in all requests associated with that dialog.

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) that relate to the same call can be sent by the MGCF. The MGCF shall route those INVITE requests to the same next hop.

5.5.3.1.2 Calls terminating in circuit-switched networks

When the MGCF receives an initial INVITE request with Supported header field indicating "100rel", the MGCF shall:

1) based on local policy, store the "fe-identifier" header field parameter of the P-Charging-Vector header field, if present;

2) store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present;

NOTE 1: Any received "orig-ioi" header field parameter will be a type 2 IOI. The type 2 IOI identifies the sending network of the request message.

3) send a 100 (Trying) response;

4) after a matching codec is found or no codec is required at the MGW, send 183 "Session Progress" response:

– set the Require header field to the value of "100rel";

– store the values received in the P-Charging-Function-Addresses header field;

– store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field; and

– insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the initial INVITE request, a type 2 "term-ioi" header field parameter and the "icid-value" header field parameter. The MGCF shall set the type 2 "term-ioi" header field parameter to a value that identifies the network in which the MGCF resides, the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the previously received value of "icid-value" header field parameter in the request. Based on local policy, the MGCF shall include the stored "fe-identifier" header field parameter in the P-Charging-Vector header field.

If a codec is required and the MGCF does not find an available matching codec at the MGW for the received initial INVITE request, the MGCF shall:

– send 503 (Service Unavailable) response if the type of codec was acceptable but none were available and the MGCF is unable to handle further requests received from the same upstream entity on the transport address where the INVITE request was received (i.e. MGCF is overloaded by SIP requests);

– send 500 (Server Internal Error) response if the type of codec was acceptable but none were available and the MGCF is able to handle further requests received from the same upstream entity on the transport address where the INVITE request was received (i.e. MGCF is not overloaded by SIP requests); or

– send 488 (Not Acceptable Here) response if the type of codec was not supported, and may include SDP in the message body to indicate the codecs supported by the MGCF/MGW.

Based upon local policy, the MGCF may support preferred ciruit carrier access (RFC 4694 [112]), if such routeing is applicable for the call.

NOTE 2: Interworking of the "cic" tel-URI parameter, if present in a tel-URI or in the userinfo part of a SIP URI with user=phone Request-URI, to the circuit switched signalling protocol is described in 3GPP TS 29.163 [11B].

The MGCF may support resource priority in accordance with RFC 4412 [116] if required for a dialog. The MGCF shall use compatible namespace and priority levels to the capabilities supported in the CS network.

Based on local policy, the MGCF shall include the stored "fe-identifier" header field parameter in the P-Charging-Vector header field, add its own address or identifier as "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header field and send the P-Charging-Vector header field in the related final response.

5.5.3.2 Subsequent requests

5.5.3.2.1 Calls originating in circuit-switched networks

When the MGCF generate a subsequent request in accordance with 3GPP TS 29.163 [11B], the MGCF shall:

a) add a P-Charging-Vector header field with the "icid-value" header field parameter set to the value populated in the initial request for the dialog and a type 2 "orig-ioi" header field parameter. The MGCF shall set the type 2 "orig-ioi" header field parameter to a value that identifies the sending network in which the MGCF resides and shall not set the type 2 "term-ioi" header field parameter.

When the MGCF receives a 1xx or 2xx response to a subsequent request for a dialog, the MGCF shall store the value of the received "term-ioi" header field parameter in the P-Charging-Vector header field, if present.

When the MGCF receives 183 (Session Progress) response to an INVITE request, the MGCF shall:

– store the values received in the P-Charging-Function-Addresses header field.

The MGCF shall send an UPDATE request when the following conditions are fulfilled:

– conditions as specified in 3GPP TS 29.163 [11B]; and

– the MGCF receives 200 (OK) response to a PRACK request

NOTE: When the MGCF is confirming the successful resource reservation using an UPDATE request (or a PRACK request) and the MGCF receives a 180 (Ringing) response or a 200 (OK) response to the initial INVITE request before receiving a 200 (OK) response to the UPDATE request (or a 200 (OK) response to the PRACK request), the MGCF does not treat this as an error case and does not release the session.

5.5.3.2.2 Calls terminating in circuit-switched networks

When the MGCF receives a subsequent request, the MGCF shall:

1) store the value of the "orig-ioi" header field parameter received in the P-Charging-Vector header field, if present.

NOTE: Any received "orig-ioi" header field parameter will be a type 2 IOI. The type 2 IOI identifies the sending network of the request message.

When the MGCF generate a response to a subsequent request in accordance with 3GPP TS 29.163 [11B], the MGCF shall, insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the subsequent request, a type 2 "term-ioi" header field parameter and the "icid-value" header field parameter. The MGCF shall set:

1) the type 2 "term-ioi" header field parameter to a value that identifies the network in which the MGCF resides;

2) the "orig-ioi" header field parameter set to the previously received value of "orig-ioi" header field parameter in the subsequent request; and

3) the "icid-value" header field parameter set to the previously received value of "icid-value" header field parameter in the subsequent request.

When the MGCF receives an indication of a ringing for the called party of outgoing call to a circuit-switched network, the MGCF shall:

– send 180 (Ringing) response to the UE.

When the MGCF receives an indication of answer for the called party of outgoing call to a circuit-switched network, the MGCF shall:

– send 200 (OK) response to the UE. The 200 (OK) response shall include an P-Asserted-Identity header field if corresponding information is received from the circuit-switched network.

5.5.4 Call release

5.5.4.1 Call release initiated by a circuit-switched network

When the MGCF receives an indication of call release from a circuit-switched network, the MGCF shall:

– send a BYE request to the UE.

5.5.4.2 IM CN subsystem initiated call release

NOTE: The release of a call towards the circuit-switched network additionally requires signalling procedures other than SIP in the MGCF that are outside the scope of this document.

5.5.4.3 MGW-initiated call release

When the MGCF receives an indication from the MGW that the bearer was lost, the MGCF shall:

– send a BYE request towards the UE; and

– may include Error-Info header field with a pointer to additional information indicating that bearer was lost.

5.5.5 Call-related requests

5.5.5.1 Session modification

5.5.5.1.0 General

This subclause applies after the 2xx response to the initial INVITE request has been sent or received.

5.5.5.1.1 Session modifications originating from circuit-switched networks

If the precondition mechanism was used during the session establishment, as described in subclause 5.5.3.1.1 or 5.5.3.1.2, the MGCF shall indicate support of the precondition mechanism during a session modification. If the precondition mechanism was not used during the session establishment, the MGCF shall not indicate support of the precondition mechanism during a session modification.

In order to indicate support of the precondition mechanism during a session modification, upon generating a reINVITE request, an UPDATE request with an SDP body, or a PRACK request with an SDP body, the MGCF shall:

a) indicate the support for the precondition mechanism using the Supported header field;

b) not indicate the requirement for the precondition mechanism using the Require header field; and

c) if a reINVITE request is being generated, indicate the support for reliable provisional responses using the Supported header field,

and follow the SDP procedures in clause 6 for the precondition mechanism.

5.5.5.1.2 Session modifications terminating in circuit-switched networks

When the MGCF receives a reINVITE request for hold/resume operation, the MGCF shall:

– send a 100 (Trying) response;

– after performing interaction with MGW to hold/resume the media flow, send a 200 (OK) response.

Upon receiving a reINVITE request, an UPDATE request, or a PRACK request that indicates support for the precondition mechanism by using the Supported header field or requires use of the precondition mechanism by using the Require header field, the MGCF shall:

a) if the precondition mechanism was used during the session establishment, as described in subclause 5.5.3.1.1 or 5.5.3.1.2, use the precondition mechanism for the session modification; and

b) if the precondition mechanism was not used during the session establishment, and

1) if use of the precondition mechanism is required using the Require header field, reject the request by sending a 420 (Bad Extension) response; and

2) if the support of the precondition mechanism is indicated using the Supported header field, not use the precondition mechanism for the session modification.

If the precondition mechanism is used for the session modification, the MGCF shall indicate support for the preconditions mechanism, using the Require header field, in responses that include an SDP body, to the session modification request.

5.5.6 Further initial requests

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.

NOTE: The detailed interface for requesting MGCF/MGW capabilities is not specified in this version of the document. Other solutions can be used in the interim.