Tech-invite3GPPspecsSIPRFCs
Overview21222324252627282931323334353637384‑5x

Content for  TS 24.229  Word version:  17.0.0

Top   Top   Up   Prev   Next
1…   3…   4…   4.5…   5…   5.1.1.4…   5.1.2…   5.1.4…   5.2…   5.2.3…   5.2.6…   5.2.7…   5.3…   5.4…   5.4.1.2.2…   5.4.1.3…   5.4.2   5.4.3…   5.4.3.3…   5.4.4…   5.5…   5.7…   5.7.2…   5.8…   5.11…   6…   6.6…   7…   7.2A…   7.2A.6…   7.3…   7.9A…   8…   A…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W…

 

5.5  Procedures at the MGCF

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

5.5.2  Subscription and notificationWord‑p. 300
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 TS 29.163;
    • include the "100rel" option tag in the Supported header field (as defined in RFC 3262);
    • include the "precondition" option tag in the Supported header field (as defined in RFC 3312 as updated by RFC 4032) 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;
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.
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). 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 TS 29.163.
If resource priority in accordance with RFC 4412 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.
Up
5.5.3.1.2  Calls terminating in circuit-switched networksWord‑p. 301
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;
  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), if such routeing is applicable for the call.
The MGCF may support resource priority in accordance with RFC 4412 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.
Up

5.5.3.2  Subsequent requestsWord‑p. 302
5.5.3.2.1  Calls originating in circuit-switched networks
When the MGCF generate a subsequent request in accordance with TS 29.163, 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 TS 29.163; and
  • the MGCF receives 200 (OK) response to a PRACK request
Up
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.
When the MGCF generate a response to a subsequent request in accordance with TS 29.163, 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.
Up

5.5.4  Call releaseWord‑p. 303

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

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 |R13|
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:
  1. indicate the support for the precondition mechanism using the Supported header field;
  2. not indicate the requirement for the precondition mechanism using the Require header field; and
  3. 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.
Up
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:
  1. 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
  2. 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.
Up

5.5.6  Further initial requestsWord‑p. 304
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.

5.6  Procedures at the BGCF

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

5.6.2  Common BGCF proceduresWord‑p. 305
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.
Up

5.6.3  Specific procedures for INVITE requests and responses |R11|Word‑p. 306
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 RFC 4028 clause 8.
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.
Up

5.6.4  Specific procedures for subsequent requests and responses |R13|Word‑p. 307
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.
Up


Up   Top   ToC