Tech-invite  3GPPspace  IETFspace
21  22  23  24  25  26  27  28  29  31  32  33  34  35  36  37  38  4‑5x

Content for  TS 24.229  Word version:  19.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…   A.2…   A.2.1.4…   A.2.1.4.7…   A.2.1.4.8…   A.2.1.4.10A…   A.2.1.4.12…   A.2.2…   A.2.2.4…   A.2.2.4.7…   A.2.2.4.8…   A.2.2.4.10A…   A.2.2.4.12…   A.3…   A.3.3…   B…   C…   E…   F…   H…   I…   K…   L…   L.2A…   M…   N…   O…   Q…   R…   S…   U…   U.2A…   V…   W… 
5.11 Procedures at the E-CSCF  5.11.1 General  5.11.2 UE originating case  5.11.3 Use of an LRF  5.11.4 Subscriptions to E-CSCF events  5.11.5 Current location discovery during an emergency call  5.12 Location Retrieval Function (LRF)  5.13 ISC gateway function  5.13.1 General  5.13.2 ISC gateway function as an exit point  5.13.3 ISC gateway function as an entry point  5.13.4 THIG functionality in the ISC gateway function  5.13.5 IMS-ALG functionality in the ISC gateway function  5.13.6 Screening of SIP signalling 
...

 

5.11  Procedures at the E-CSCF |R7|  p. 365

5.11.1  General  p. 365

The PSAP may either be directly connected to the IM CN subsystem or via the PSTN. Based on regional/national requirements and network operator policy, the PSAP may be connected to the IM CN subsystem of another network.
The E-CSCF can receive URIs for a domain for which the operator running the E-CSCF is not responsible. Where RFC 3261 specifies a requirement that the SIP entity has to be responsible for the domain for particular functionality to occur, the E-CSCF may ignore this restriction.
The E-CSCF retrieves a PSAP URI, based on the location of the UE and the requested type of emergency service. The PSAP URI can be retrieved from LRF (see subclause 5.11.3) or from local configuration. The PSAP address will either point to a PSAP connected to the IM CN subsystem or to a PSAP connected to the PSTN.
If operator policy determines that the E-CSCF selects the PSAP and if, based on the location information contained in the INVITE request, the E-CSCF fails to select the PSAP, the E-CSCF can interrogate an external server in order to retrieve location information.
When the E-CSCF receives an emergency request for a dialog requesting privacy or a standalone emergency transaction requesting privacy or any request or response related to a UE-originated emergency dialog requesting privacy, and if operator policy (e.g. determined by national regulatory requirements applicable to emergency services) allows requests for suppression of public user identifiers and location information per TS 22.101, the E-CSCF:
  • shall provide the privacy service role according to RFC 3323 and RFC 3325;
  • shall remove any location object from the message's body with Content-Type header field containing the content type application/pidf+xml. If only one message body remains in the message's body then the E-CSCF sets the Content-Type header field to the content type specified for the body; and
  • shall remove the Geolocation header field (if present) and the Geolocation-Routing header field (if present);
prior to forwarding any such request to a PSAP.
The E-CSCF 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 E-CSCF 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 "e-cscf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17.
Up

5.11.2  UE originating case  p. 366

The E-CSCF may forward an emergency request to a PSAP in the IM CN subsystem, a PSAP attached to another network, or a PSAP in the PSTN. If the PSAP is attached to another network, the requrest can pass IBCF(s) before entering the other network. If the PSAP is located in the PSTN, the request will pass a BGCF and a MGCF before entering the PSTN.
Upon receipt of an initial request for a dialog, or a standalone transaction, or an unknown method including a Request-URI with an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031, or an emergency number the E-CSCF shall:
1)
if:
  1. the topmost Route header field of the received SIP INVITE request contains an E-CSCF URI inserted by a P-CSCF, an AS or an IBCF;
  2. the Contact header field includes an instance-id feature tag containing an IMEI URN as specified in RFC 7254 or an MEID URN as specified in RFC 8464. Only the IMEI shall be used for generating an instance ID for a multi-mode UE that supports both 3GPP and 3GPP2 defined radio access networks; and
  3. required by the operator policy;
then:
a0)
remove its own SIP URI from the topmost Route header field;
a)
insert URI of the EATF to be contacted into the Route header field as the topmost entry followed by own URI to be used to receive the request from EATF;
b)
insert a type 3 "orig-ioi" header field parameter in the P-Charging-Vector header field. The E-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The E-CSCF shall not include the type 3 "term-ioi" header field parameter;
c)
if required by national regulatory requirements applicable to emergency services, include:
  • a CPC with value "emergency"; and optionally
  • an OLI set to a value corresponding to the characteristics of the access used when the emergency request was initiated by the UE, i.e., an OLI that corresponds to a wireless access; and
d)
route the request based on SIP routeing procedures and do not continue with the rest of the steps;
1A)
remove its own SIP URI from the topmost Route header field;
1B)
if the received request does not contain a P-Charging-Vector header field, insert a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260;
1C)
if an "orig-ioi" header field parameter is received in the P-Charging-Vector header field, store the value of the received "orig-ioi" header field parameter;
1D)
if operator policy determines that an LRF is to be used, forward the request to the LRF as indicated in subclause 5.11.3;
2)
if the PSAP is the next hop, store the value of the "icid-value" header field parameter received in the P-Charging-Vector header field and remove the received information in the P-Charging-Vector header field, else keep the P-Charging-Vector if the next hop is an exit IBCF or a BGCF;
3)
if the PSAP is the next hop remove the P-Charging-Function-Addresses header fields, if present, else keep the P-Charging-Function-Addresses header fields if the next hop is an exit IBCF or an BGCF;
4)
if an IBCF or a BGCF is the next hop, delete any received "orig-ioi" header field parameter, and insert a type 2 "orig-ioi" header field parameter into the P-Charging-Vector header field. The E-CSCF shall set the type 2 "orig-ioi" header field parameter to a value that identifies the sending network. The E-CSCF shall not include the "term-ioi" header field parameter;
5)
get location information as:
  • geographical location information received in a PIDF location object as defined in RFC 4119 and RFC 5491, with the content type application/pidf+xml, as described RFC 6442; and
  • location identifier as derived from the P-Access-Network-Info header field, if available.
5A)
if the location is retrieved using information from the Geolocation header field, and if:
  • the Geolocation-Routing header field is present, and includes a value not allowing routing of the request based on user location information;
  • the Geolocation-Routing header field is present, and includes a value unknown to the E-CSCF; or
  • the Geolocation-Routing header field is not present.
    not use the location retrieved from the Geolocation header field when deciding where to forward the request.
6)
select, based on location information and optionally type of emergency service:
  1. a PSAP connected to the IM CN subsystem or another network, and add the PSAP URI to the topmost Route header field; or
  2. a PSAP in the PSTN, add the BGCF URI to the topmost Route header field, add a PSAP URI in tel URI format to the Request-URI with an entry used in the PSTN/CS domain to address the PSAP and set the handling header field parameter value of the Content-Disposition header field associated with the application/pidf+xml message body (if present) to "optional";
7)
void;
8)
if due to local policy or if the PSAP requires interconnect functionalities (e.g. PSAP address is of an IP address type other than the IP address type used in the IM CN subsystem, or the PSAP URI contains the domain name of another network), put the address of the IBCF to the topmost Route header field, in order to forward the request to the PSAP via an IBCF in the same network;
9)
create a Record-Route header field containing its own SIP URI;
10)
if the request is an INVITE request, save the Contact, CSeq and Record-Route header field values received in the request such that the E-CSCF is able to release the session if needed; and
11)
if no P-Asserted-Identity header field is present and if required by operator policy governing the indication to PSAPs that a UE does not have sufficient credentials (e.g. determined by national regulatory requirements applicable to emergency services), insert a P-Asserted-Identity header field set to a non-dialable callback number (see ANSI/J-STD-036-B [176]);
12)
if required by national regulatory requirements applicable to emergency services, include:
  • a CPC with value "emergency"; and optionally
  • an OLI set to a value corresponding to the characteristics of the access used when the emergency request was initiated by the UE, i.e., an OLI that corresponds to a wireless access; and
13)
route the request based on SIP routeing procedures.
Upon receipt of an initial request for a dialog, a standalone transaction, or an unknown method, that does not include a Request-URI with an emergency service URN or an emergency number, the E-CSCF shall reject the request by sending a 403 (Forbidden) response.
When the E-CSCF receives the request containing the access-network-charging-info parameter in the P-Charging-Vector, the E-CSCF shall store the access-network-charging-info parameter from the P-Charging-Vector header field. The E-CSCF shall retain access-network-charging-info parameter in the P-Charging-Vector header field.
When the E-CSCF receives any request or response (excluding ACK requests and CANCEL requests and responses) related to a UE-originated dialog or standalone transaction, the E-CSCF may insert previously saved values into a P-Charging-Function-Addresses header field before forwarding the message.
When the E-CSCF receives any request or response related to a UE-originated dialog or standalone transaction, the E-CSCF may insert previously saved values into a P-Charging-Vector before forwarding the message. If the original request contained a P-Charging-Vector header field including an orig-IOI header field parameter, insert a type 2 "term-ioi" header field parameter in the P-Charging-Vector header field of the outgoing response. The type 2 "term-ioi" header field is set to a value that identifies the sending network of the response and the "orig-ioi" header field parameter is set to the previously received value of "orig-ioi" header field parameter. Values of "orig-ioi" and "term-ioi" header field parameters in the received response are removed.
Based on local policy the E-CSCF shall 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 to an initial request.
When the E-CSCF receives any 1xx or 2xx response related to a UE-originated dialog or standalone transaction, the E-CSCF shall remove any P-Preferred-Identity header field and P-Asserted-Identity header field, and insert a P-Asserted-Identity header field with the digits that can be recognized as a valid emergency number if dialled as a tel URI representing the number, before forwarding the message.
When the E-CSCF receives any response related to a UE-originated dialog or standalone transaction containing a "term-ioi" header field parameter, the E-CSCF shall store the value of the received "term-ioi" header field parameter received in the P-Charging-Vector header field, if present, and remove all received "orig-ioi" and "term-ioi" header field parameters.
When the E-CSCF receives an INVITE request from the UE, the E-CSCF may require the periodic refreshment of the session to avoid hung states in the E-CSCF. If the E-CSCF requires the session to be refreshed, the E-CSCF shall apply the procedures described in Section 8 of RFC 4028.
When the E-CSCF receives a 2xx response related to a UE-originated dialog and if:
  1. the E-CSCF supports the current location discovery during the emergency call;
  2. the UE indicated a Recv-Info header field with the g.3gpp.current-location-discovery info package name in the dialog of the emergency call; and
  3. the UE indicated an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml" MIME type in the dialog of the emergency call;
the E-CSCF:
  1. shall include an Allow header field indicating support of the PUBLISH method in the SIP 2xx response; and
  2. shall include an Allow-Events header field indicating support of the presence event package in the SIP 2xx response;
before forwarding the message.
Up

5.11.3  Use of an LRF |R9|  p. 369

Where the network operator determines that an LRF is to be used, the E-CSCF shall route initial requests for a dialog and standalone requests that contain an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in RFC 5031, or an emergency number, to the LRF in accordance with the procedures of RFC 3261.
For the outgoing request, the E-CSCF shall:
  1. insert a type 3 "orig-ioi" header field parameter in the P-Charging-Vector header field. The E-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The E-CSCF shall not include the type 3 "term-ioi" header field parameter; and
  2. perform step 11 of subclause 5.11.2 before sending the INVITE request to the LRF.
When the E-CSCF receives any 3xx response to such a request, the E-CSCF shall select a Contact header field URI from the 3xx response according to RFC 3261 and continue processing the steps given in subclause 5.11.2 with the following additions:
  1. at step 6), if item a) applies, place the URI received in the selected Contact header field URI in the 3xx response in the topmost entry in the Route header field;
  2. at step 6), if item b) applies, replace the original Request-URI with the URI received in the selected Contact header field URI in the 3xx response;
  3. if the user did not request privacy or if national regulator policy applicable to emergency services does not require the user be allowed to request privacy, then if the selected Contact header field URI contains a P-Asserted-Identity header field encoded as a header field of the URI, replace all P-Asserted-Identity header fields in the original request with this value;
  4. if operator local policies allow insertion of UE location information and if the received 3xx response contains a message/external-body MIME type as specified in RFC 4483 with "access-type" MIME type parameter containing "URL" and "URL" MIME type parameter containing an HTTP or HTTPS URI identifying a PIDF location object as defined in RFC 4119 and RFC 5491, then the E-CSCF shall insert a Geolocation header field containing this PIDF location object by reference (see RFC 6442);
  5. if the location source parameter for the SIP Geolocation header field as defined in RFC 8787 is supported, include a loc-src parameter in the Geolocation header field set to the domain name of the visited network; and
  6. if operator policies allow forming requests from a URI and if 3xx response is received, then follow the procedures of Section 19.1.5 of RFC 3261 with the following additions and clarifications:
    • replacement or inclusion of any header field from the URI in the selected Contact header field is subject to operator policy; and
    • if operator policy allows any LRF to provide a location by value, and the URI in the selected Contact header field contains the "Geolocation" header field, a "Geolocation-Routing" header field and a header field with hname "body" with a value, replace the entire message body with value of the header field with hname "body" in the URI in the selected Contact header field, otherwise do not perform this replacement.
If no 1xx or 2xx response to the request is received from the addressed PSAP within an operator settable timeout, or a 4xx - 5xx response is received, and additional URI values were included in the Contact header field of the response, the E-CSCF shall use these values according to RFC 3261 in new requests that are otherwise generated according to the rules specified above.
If no 1xx or 2xx response to the request is received from the addressed PSAP within an operator settable timeout, or a 4xx - 5xx response is received, and all URI values included in the Contact header field of the 3xx response have been attempted, the E-CSCF shall use a default URI value configured in the E-CSCF in a new request that is otherwise generated according to the rules specified above.
If a 6xx response to the request is received, the E-CSCF acts in accordance with RFC 3261.
When the E-CSCF receives any response related to the above request containing a "term-ioi" header field parameter, the E-CSCF shall store the value of the received "term-ioi" header field parameter received in the P-Charging-Vector header field, if present, and remove all received "orig-ioi" and "term-ioi" header field parameters from the forwarded response.
If no 3xx response to the request is received from the LRF within an operator settable timeout, the E-CSCF shall use a default URI value configured in the E-CSCF in a request that is otherwise generated according to the rules specified above.
Up

5.11.4  Subscriptions to E-CSCF events |R9|  p. 370

5.11.4.1  Subscription to the event providing dialog state  p. 370

When an incoming SUBSCRIBE request addressed to the E-CSCF arrives containing the Event header field with the dialog event package, the E-CSCF shall:
  1. based on the local policy, check if the request was generated by a subscriber who is authorised to subscribe to the dialog state of this particular user. The authorized subscribers include:
    • all the LRFs that belong to the same network operator.
    If the requester is not authorised, the E-CSCF shall reject the request with an appropriate 4xx - 6xx response;
  2. store the "icid-value" header field parameter received in the P-Charging-Vector header field;
  3. store the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present; and
  4. generate a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the authorised subscription was successful as described in RFC 4235. The E-CSCF shall populate the header fields as follows:
    • an Expires header field, set to either the same or a decreased value as the Expires header field in the SUBSCRIBE request; and
    • a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. The E-CSCF shall set the type 3 "term-ioi" header field parameter to a value that identifies the sending network of the response, the "orig-ioi" header field parameter is set to the previously received value of the "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the received value of the "icid-value" header field parameter in the request.
The E-CSCF may set the Contact header field to an identifier uniquely associated to the SUBSCRIBE request and generated within the E-CSCF, that may help the E-CSCF to correlate refreshes for the SUBSCRIBE.
Afterwards the E-CSCF shall perform the procedures for notification about dialog state as described in subclause 5.11.4.2.
When the E-CSCF receives a subscription refresh request for a dialog that was established by the UE subscribing to the dialog event package, the E-CSCF shall accept the request.
Up

5.11.4.2  Notification about dialog state  p. 371

The E-CSCF shall send a NOTIFY request when an event pertaining to the dialog or dialogs occurs, as specified in RFC 6665.
When generating NOTIFY requests, the E-CSCF shall not preclude any valid dialog event package parameters in accordance with RFC 4235. Where RFC 4235 expresses an option or only a recommendation as to the generation of a NOTIFY request, it is a matter of operator policy as to whether such requests are generated.
For each NOTIFY request triggered by an event and on all dialogs which have been established due to subscription to the dialog event package, and in addition to the requirements specified in RFC 4235, the E-CSCF shall:
  1. set the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260, and a type 3 "orig-ioi" header field parameter. The E-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The E-CSCF shall not include the type 3 "term-ioi" header field parameter.
  2. in the body of the NOTIFY request, include one <dialog> XML element for each dialog to be reported in accordance with the subscription; and
  3. for each <dialog> XML element:
    • if the subscription is for all dialogs, rather than a specific dialog, then include the call-id attribute.
If the subscription is to a specific dialog (or to a specific set of dialogs), when sending a final NOTIFY request with all dialogs set to a state of "terminated", the E-CSCF shall also terminate the subscription to the dialog event package by setting the Subscription-State header field to the value of "terminated".
When the E-CSCF receives any response to the NOTIFY request, the E-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.
Up

5.11.4.3  Subscription to the presence event package |R14|  p. 372

When an incoming SUBSCRIBE request addressed to the E-CSCF arrives containing the Event header field with the presence event package and a Target-Dialog header field:
  1. based on the local policy, the E-CSCF shall check if the request was generated by a subscriber who is authorised to subscribe to the presence state of this particular user. The authorized subscribers include:
    • all the LRFs that belong to the same network operator.
    If the requester is not authorised, the E-CSCF shall reject the request with an appropriate 4xx - 6xx response;
  2. the E-CSCF shall determine the dialog of the related emergency call, i.e. a confirmed dialog identified by:
    1. the call identifier in the callid portion of the Target-Dialog header field; and
    2. the "remote-tag" header field parameter of the Target-Dialog header field.
    If such dialog does not exist, the E-CSCF shall reject the request with an appropriate 4xx - 6xx response;
  3. if :
    1. the UE did not indicate a Recv-Info header field with the g.3gpp.current-location-discovery info package name in the dialog of the related emergency call; or
    2. the UE did not indicate an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml" MIME type in the dialog of the related emergency call;
    the E-CSCF shall reject the request with an appropriate 4xx - 6xx response;
  4. the E-CSCF shall store the "icid-value" header field parameter received in the P-Charging-Vector header field;
  5. the E-CSCF shall store the "orig-ioi" header field parameter received in the P-Charging-Vector header field if present; and
  6. the E-CSCF shall generate a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the authorised subscription was successful as described in RFC 4235. The E-CSCF shall populate the header fields as follows:
    • an Expires header field, set to either the same or a decreased value as the Expires header field in the SUBSCRIBE request; and
    • a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the SUBSCRIBE request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. The E-CSCF shall set the type 3 "term-ioi" header field parameter to a value that identifies the sending network of the response, the "orig-ioi" header field parameter is set to the previously received value of the "orig-ioi" header field parameter and the "icid-value" header field parameter is set to the received value of the "icid-value" header field parameter in the request;
  7. the E-CSCF shall associate the dialog of the 200 (OK) response to the SUBSCRIBE request with the dialog of the related emergency call;
  8. if the Expires header field of the SUBSCRIBE request is set to zero, the E-CSCF shall perform the procedure in subclause 5.11.5.2 in the dialog of the related emergency call and shall indicate that the receiving entity is requested to send the location information once; and
  9. if the Expires header field of the SUBSCRIBE request is not set to zero, the E-CSCF shall perform the procedure in subclause 5.11.5.2 in the dialog of the related emergency call and shall indicate that the receiving entity is requested to start sending the location information.
The E-CSCF may set the Contact header field to an identifier uniquely associated to the SUBSCRIBE request and generated within the E-CSCF, that may help the E-CSCF to correlate refreshes for the SUBSCRIBE.
Afterwards the E-CSCF shall perform the procedures for notification about presence event as described in subclause 5.11.4.4.
When the E-CSCF receives a subscription refresh request for the subscription associated with the initial SUBSCRIBE request, the E-CSCF shall accept the request.
When the E-CSCF receives an unsubscription request for the subscription associated with the initial SUBSCRIBE request:
  1. the E-CSCF shall accept the request; and
  2. if the dialog of the related emergency call still exists, the E-CSCF shall perform the procedure in subclause 5.11.5.2 in the dialog of the related emergency call and shall indicate that the receiving entity is requested to stop sending the location information.
Up

5.11.4.4  Notification about presence |R14|  p. 373

Upon reception of a PUBLISH request in the dialog of the related emergency call as described in subclause 5.11.5.3, the E-CSCF shall send a NOTIFY request for the presence event package as specified in RFC 6665. The E-CSCF:
  1. if the PUBLISH request contains a body of the "application/pidf+xml" MIME type, shall include in the NOTIFY request the body of the "application/pidf+xml" MIME type of the PUBLISH request;
  2. if the PUBLISH request contains P-Access-Network-Info header field(s), shall include in the NOTIFY request the P-Access-Network-Info header field(s) of the PUBLISH request; and
  3. shall set the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260, and a type 3 "orig-ioi" header field parameter in the NOTIFY request. The E-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The E-CSCF shall not include the type 3 "term-ioi" header field parameter.
If the dialog of the related emergency call is terminated, the E-CSCF shall send a NOTIFY request for the presence event package indicating that the subscription is terminated by setting the Subscription-State header field to the "terminated" value. The E-CSCF shall set the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260, and a type 3 "orig-ioi" header field parameter in the NOTIFY request. The E-CSCF shall set the type 3 "orig-ioi" header field parameter to a value that identifies the sending network of the request. The E-CSCF shall not include the type 3 "term-ioi" header field parameter.
When the E-CSCF receives any response to the NOTIFY request, the E-CSCF shall store the value of the "term-ioi" header field parameter received in the P-Charging-Vector header field, if present.
Up

5.11.5  Current location discovery during an emergency call |R14|  p. 373

5.11.5.1  General  p. 373

The UE can be requested to provide the current location information during an emergency call.

5.11.5.2  Requesting current location informaton  p. 373

If:
  1. the UE indicated a Recv-Info header field with the g.3gpp.current-location-discovery info package name in the dialog of the emergency call;
  2. the UE indicated an Accept header field indicating the "application/vnd.3gpp.current-location-discovery+xml" MIME type in the dialog of the emergency call; and
  3. the dialog of the emergency call is a confirmed dialog;
then in order to request providing of the location information, the E-CSCF shall send an INFO request as described in RFC 6086, as an in-dialog request of the dialog of the emergency call towards the UE. In the INFO request:
  1. the E-CSCF shall include an Info-Package header field as described in RFC 6086, containing the g.3gpp.current-location-discovery info package name; and
  2. the E-CSCF shall include an request-for-current-location body as specified in subclause 7.12.2.2 in the MIME body of "application/vnd.3gpp.current-location-discovery+xml" MIME type.
Up

5.11.5.3  Receiving current location informaton  p. 374

Upon receiving a PUBLISH request as described in RFC 3903 as in-dialog request of the dialog of the emergency call, with Event header field containing the presence event package name, the E-CSCF shall perform the procedures described in subclause 5.11.4.4.

5.12  Location Retrieval Function (LRF) |R9|  p. 374

5.12.1  General  p. 374

The LRF can receive URIs for a domain for which the operator running the LRF is not responsible. Where RFC 3261 specifies a requirement that the SIP entity has to be responsible for the domain for particular functionality to occur, the LRF may ignore this restriction.
The LRF 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 LRF 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 "lrf" and optionally an appropriate fe-param part of the URN set in accordance with subclause 7.2.17.
Up

5.12.2  Treatment of incoming initial requests for a dialog and standalone requests  p. 374

The LRF shall respond to all received initial requests for a dialog, and to all standalone requests, as a redirect server as defined in Section 8.3 of RFC 3261 with the following additions:
1)
the LRF shall generate a 300 (Multiple Choices) response to all such requests;
2)
the LRF shall set the Contact header field of the response to a list (one or more) address(es) of PSAP(s), selected according to network operator policy;
2A)
if the location is retrieved using information from the Geolocation header field, and if:
  • the Geolocation-Routing header field is present, and includes a value not allowing routing of the request based on user location information;
  • the Geolocation-Routing header field is present, and includes a value unknown to the LRF; or
  • the Geolocation-Routing header field is not present;
the LRF shall not use the location retrieved from the Geolocation header field when selecting PSAP(s);
2B)
if the access-type field of the P-Access-Network-Info header field not containing "network-provided" parameter is set to "3GPP-NR-ProSe-L3UNR", a location is retrieved using "U2N-relay-ID" parameter of the P-Access-Network-Info header field containing the "network-provided" parameter, and the retrieved location does not match the user-provided location from the P-Access-Network-Info header field not containing the "network-provided" parameter, then the LRF shall not use the location retrieved from the P-Access-Network-Info header field not containing the "network-provided" parameter when selecting PSAP(s);
3)
the LRF shall insert a P-Charging-Vector header field containing the "orig-ioi" header field parameter, if received in the request, a type 3 "term-ioi" header field parameter and the "icid-value" header field parameter. The LRF shall set the type 3 "term-ioi" header field parameter to a value that identifies the service provider from which the response is sent, 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;
4)
optionally, generate a reference identifier and set the P-Asserted-Identity header field encoded as a header field of the URI in the Contact header field to this value in each included Contact header field URI associated with a PSAP. The LRF shall maintain state for any generated reference identifier. If the LRF uses a SIP URI (or any other permitted URI scheme other than tel URI) as the reference identifier, the LRF has the responsibility of ensuring (e.g. by configuration) that the emergency request is being routed to an IP connected PSAP. Subclause 5.12.3.1 defines a means of maintaining the state of the reference identifier. If required by operator policy governing the indication to PSAPs that a UE does not have sufficient credentials (e.g. determined by national regulatory requirements applicable to emergency services), the reference identifier shall not be equal to a non-dialable callback number used to indicate the UE does not have credentials;
5)
if required by operator local policies, the LRF shall include a message/external-body MIME type as specified in RFC 4483 with:
  1. "access-type" MIME type parameter containing "URL"; and
  2. "URL" MIME type parameter containing an HTTP or HTTPS URI identifying a PIDF location object as defined in RFC 4119 and RFC 5491; and
6)
if required by operator local policies, the LRF shall include geographical information, encoded as header fields of the URI in a Contact header field of the 300 (Multiple Choices) response, in the following way:
  1. if operator policy indicates location-by-reference is to be used:
    1. a Geolocation-Routing header field with value "yes"; and
    2. a Geolocation header field that contains an HTTP URI or a HTTPS URI associated with a location-by-reference, as defined in RFC 6442; and
  2. if operator policy indicates location-by-value is to be used:
    1. a Geolocation-Routing header field with value "yes";
    2. Geolocation header field with value associated with the location-by-value;
    3. a header field with hname "body" and with a value that contains an escape encoded MIME body of multipart/mixed MIME type containing:
      • the MIME body from the received request; and
      • the geographical location information as PIDF location object in accordance with RFC 4119 and RFC 5491; and
    4. a Content-Type header field with multipart/mixed MIME type.
Up

5.12.3  Subscription and notification  p. 376

5.12.3.1  Notification about dialog state  p. 376

Based on operator policy, the LRF can either subscribe to all dialog information on an E-CSCF or individually subscribe to each dialog as it receives the requests.
In the case that the LRF is subscribing to all dialogs at the E-CSCF, the LRF shall generate a SUBSCRIBE request to the dialog state event package in accordance with RFC 6665 and RFC 4235. The LRF shall include the following additional information in the SUBSCRIBE request:
  1. the Request-URI set to an E-CSCF address;
  2. no header field parameters in the Event header field;
  3. an Expires header field set to 600 000 seconds; and
  4. a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 and a type 3 "orig-ioi" header field parameter. The type 3 "orig-ioi" header field parameter identifies the service provider from which the request is sent. The LRF shall not include the type 3 "term-ioi" header field parameter.
Upon generation of a 300 response to an incoming dialog forming request that contains a reference identifier, and in the case that the LRF is subscribing to individual dialogs at the E-CSCF, the LRF shall generate a SUBSCRIBE request to the dialog state event package in accordance with RFC 6665 and RFC 4235. The LRF shall include the following additional information in the SUBSCRIBE request:
  1. the Request-URI set to the value of the P-Asserted-Identity in the original request to which the response was generated;
  2. a Route header field that addresses the request to the E-CSCF. How such a value is determined depends on deployment;
    1. if there is only one E-CSCF in the network, using the address of that E-CSCF preconfigured into the system;
    2. using the last entry in the Via header field of the original request to which the 3xx response was generated. If the deployment however includes some intermediate SIP proxy or B2BUA not otherwise included in the emergency call architecture this will not provide the desired result; or
    3. using the IP address from which the original request was received to which the 3xx response was generated. The request is sent to the same port number and IP address as the 3xx response was generated. If the deployment however includes some intermediate SIP proxy or B2BUA not otherwise included in the emergency call architecture this will not provide the desired result, and additionally, if the system is set up to use port numbers in a unidirectional manner, i.e. one port number for requests and another port number for responses, it will also not operate correctly.
  3. the "call-id" and "to-tag" header field parameters in the Event header field set to the values in the original request to which the 3xx response was generated. No "from-tag" header field parameter can be included as it is not known by the LRF;
  4. an Expires header field set to 86400 seconds; and
  5. a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 and a type 3 "orig-ioi" header field parameter. The type 3 "orig-ioi" header field parameter identifies the service provider from which the request is sent. The LRF shall not include the type 3 "term-ioi" header field parameter.
In the case that the LRF is subscribing to individual dialogs at the E-CSCF, and a NOTIFY request is received indicating a state of "terminated", the LRF shall end the subscription to the dialog event package.
When, as a result of successful subscription to the dialog event package, the LRF receives a notification containing dialog updates, the LRF shall update its record for each dialog included in the event package information.
Up

5.12.3.2  Notification about UE location |R14|  p. 377

Based on operator policy, the LRF can subscribe to UE location as it receives the requests.
Upon generation of a 300 response to an incoming dialog forming request that contains a reference identifier, the LRF shall generate a SUBSCRIBE request to the presence event package in accordance with RFC 6665 and RFC 3856. The LRF shall include the following additional information in the SUBSCRIBE request:
  1. the Request-URI set to an E-CSCF address;
  2. a Target-Dialog header field with the callid portion and the "remote-tag" header field parameter set to the values in the original request to which the 3xx response was generated. No "local-tag" header field parameter can be included as it is not known by the LRF;
  3. an Expires header field set to 86400 seconds or to 0 seconds; and
  4. a P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in TS 32.260 and a type 3 "orig-ioi" header field parameter. The type 3 "orig-ioi" header field parameter identifies the service provider from which the request is sent. The LRF shall not include the type 3 "term-ioi" header field parameter.
When, as a result of successful subscription to the presence event package, the LRF receives a notification containing the UE location, the LRF shall update its record for the dialog indicated in the Target-Dialog header field of the SUBSCRIBE request.
Up

5.13  ISC gateway function |R11|  p. 377

5.13.1  General  p. 377

As specified in TS 23.218 border control functions may be applied between the IM CN subsystem and an application server based on operator preference. The ISC gateway function may act both as an entry point and as an exit point for a network. If it processes a SIP request received from another network it functions as an entry point (see subclause 5.13.3) and it acts as an exit point whenever it processes a SIP request sent to other network (see subclause 5.13.2).
In many cases, the ISC interface carries more than one hop of the session, e.g. the application server has applied a service to a SIP request and then returned the SIP request to the S-CSCF, or a AS acting as a third-party call controller generates multiple outgoing legs. In these cases all the requests relating to the session on all hops / legs should be configured to route through the same ISC gateway function.
This ISC gateway function exists on a one to one basis with its addressed AS, i.e. the URI used to address the ISC gateway function will always reach the same AS beyond the ISC gateway function.
The functionalities of the ISC gateway function are entry and exit point procedures as defined in subclause 5.13.2 and subclause 5.13.3 and additionally can include:
The application level gateway shall log all SIP requests and responses that contain a "logme" header field parameter in the SIP Session-ID header field based on local policy.
Up

5.13.2  ISC gateway function as an exit point  p. 378

5.13.2.1  Registration  p. 378

There are no specific requirements for the REGISTER method, i.e. the REGISTER method is treated as for other SIP methods.

5.13.2.2  General  p. 378

This subclause applies for requests sent from the S-CSCF to the AS via the ISC gateway function.
For all SIP transactions identified:
  • if priority is supported, as containing an authorised Resource-Priority header field or a temporarily 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 ISC gateway function shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the ISC gateway function shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.
Up

5.13.2.3  Initial requests  p. 378

Upon receipt of:
  • an initial request for a dialog;
  • a request for a standalone transaction; or
  • a request for an unknown method that does not relate to an existing dialog;
the ISC gateway function shall:
  1. if the request is an INVITE request, respond with a 100 (Trying) provisional response;
  2. remove the topmost entry from the Route header field in accordance with RFC 3261 procedures for processing Route header fields, and then add as the topmost entry the URI of the application server associated with this ISC gateway function, followed by a next entry of a URI needed to reach this ISC gateway function from the application server;
  3. if the request is an INVITE request and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, save the Contact, CSeq and Record-Route header field values received in the request such that the ISC gateway function is able to release the session if needed;
  4. If the request is a SUBSCRIBE and the ISC gateway function does not need to act as B2BUA, based on operator policy, the ISC gateway function shall determine whether or not to retain, for the related subscription, the SIP dialog state information and the duration information;
  5. if the request is an initial request for a dialog and local policy requires the application of ISC gateway function capabilities in subsequent requests, perform record route procedures as specified in RFC 3261;
  6. if the recipient of the request is understood from configured information to always send and receive private network traffic from this source, remove the P-Private-Network-Indication header field containing the domain name associated with that saved information;
  7. store the values from the P-Charging-Function-Addresses header field, if present;
  8. if the request is an initial request and "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain;
    • store the "fe-identifier" header field parameter of the P-Charging-Vector header field; and
    • remove the "fe-identifier" header field parameter from the P-Charging-Vector header field;
  9. remove some of the parameters from the P-Charging-Vector header field or the header field itself, depending on operator policy, if present; and
  10. remove the P-Charging-Function-Addresses header fields, if present, prior to forwarding the message;
and forwards the request according to RFC 3261.
When the ISC gateway function receives an INVITE request, the ISC gateway function may require the periodic refreshment of the session to avoid hung states in the ISC gateway function. If the ISC gateway function requires the session to be refreshed, the ISC gateway function shall apply the procedures described in RFC 4028.
When the ISC gateway function receives a response to any of the requests handled in this subclause, then the ISC gateway function shall:
  1. in the P-Charging-Vector header field, subject to operator policy, reinsert any parameters that were removed and stored. In addition, where the operator policy requires it, include on behalf of the supported application server a type 3 "term-ioi" header field parameter. This IOI may represent either the network of the ISC gateway function or the network providing the AS.
In responses, if "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain, the ISC gateway function acting as an exit point shall:
  • delete in the P-Charging-Vector header field any received "fe-identifier" header field parameter; and
  • add the stored"fe-identifier" to the P-Charging-Vector header field and include its own address or identifier as an "fe-addr" element of the "fe-identifier" header field parameter of the P-Charging-Vector header.
With the exception of 305 (Use Proxy) responses, the ISC gateway function shall not recurse on 3xx responses.
Up

5.13.2.4  Subsequent requests  p. 380

Upon receipt of a subsequent request, the ISC gateway function shall:
  1. if the request is an INVITE request, respond with a 100 (Trying) provisional response;
  2. if the request is a NOTIFY request with the Subscription-State header field set to "terminated" and the ISC gateway function has retained the SIP dialog state information for the associated subscription, once the NOTIFY transaction is terminated, the ISC gateway function can remove all the stored information related to the associated subscription;
  3. if the request is a target refresh request and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, save the Contact and CSeq header field values received in the request such that the ISC gateway function is able to release the session if needed; and
  4. if the subsequent request is other than a target refresh request (including requests relating to an existing dialog where the method is unknown) and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, save the Contact and CSeq header field values received in the request such that the ISC gateway function is able to release the session if needed;
and forwards the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261.
Up

5.13.2.5  Call release initiated by ISC gateway function  p. 380

If the ISC gateway function provides transport plane control functionality and receives an indication of a transport plane related error the ISC gateway function may:
  1. generate a BYE request for the terminating side based on information saved for the related dialog; and
  2. generate a BYE request for the originating side based on the information saved for the related dialog.
Upon receipt of the 2xx responses for both BYE requests, the ISC gateway function shall release all information related to the dialog and the related multimedia session.
Up

5.13.3  ISC gateway function as an entry point  p. 380

5.13.3.1  Registration  p. 380

There are no specific requirements for the REGISTER method, i.e. the REGISTER method is treated as for other SIP methods.

5.13.3.2  General  p. 380

This subclause applies for requests sent from the AS to the S-CSCF via the ISC gateway function. Such requests come from the AS as a result of a request received from the S-CSCF and forwarded by the ISC gateway function.
For all SIP transactions identified:
  • if priority is supported (NOTE), as containing an authorised Resource-Priority header field or a temporarily 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 ISC gateway function shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs. If priority is supported, the ISC gateway function shall adjust the priority treatment of transactions or dialogs according to the most recently received authorized Resource-Priority header field or backwards indication value.
Up

5.13.3.3  Initial requests  p. 381

Upon receipt of:
  • an initial request for a dialog;
  • a request for a standalone transaction; or
  • a request for an unknown method that does not relate to an existing dialog;
the ISC gateway function shall verify whether the request is arrived from a trusted domain or not. If the request arrived from an untrusted domain, then the ISC gateway function shall:
  • remove all P-Charging-Vector header fields and all P-Charging-Function-Addresses header fields the request may contain.
Upon receipt of:
  • an initial request for a dialog;
  • a request for a standalone transaction except the REGISTER request; or
  • a request for an unknown method that does not relate to an existing dialog;
the ISC gateway function shall:
  1. if the request is an INVITE request, respond with a 100 (Trying) provisional response;
  2. remove the topmost entry from the Route header field in accordance with RFC 3261 procedures for processing Route header fields;
  3. if a P-Private-Network-Indication header field is included in the request, check whether the configured information allows the receipt of private network traffic from this source. If private network traffic is allowed, the ISC gateway function shall check whether the received domain name in any included P-Private-Network-Indication header field in the request is the same as the domain name associated with that configured information. If private network traffic is not allowed, or the received domain name does not match, then the ISC gateway function shall remove the P-Private-Network-Indication header field;
  4. if the initiator of the request is understood from configured information to always send and receive private network traffic from this source, insert a P-Private-Network-Indication header field containing the domain name associated with that configured information;
  5. if the request is an INVITE request and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, then the ISC gateway function shall save the Contact, CSeq and Record-Route header field values received in the request such that the ISC gateway function is able to release the session if needed;
  6. If the request is a SUBSCRIBE and the ISC gateway function does not need to act as B2BUA, based on operator policy, the ISC gateway function shall determine whether or not to retain, for the related subscription, the SIP dialog state information and the duration information; and
  7. if the request is an initial request for a dialog and local policy requires the application of ISC gateway function capabilities in subsequent requests, perform record route procedures as specified in RFC 3261;
When the ISC gateway function receives an INVITE request, the ISC gateway function may require the periodic refreshment of the session to avoid hung states in the ISC gateway function. If the ISC gateway function requires the session to be refreshed, the ISC gateway function shall apply the procedures described in Section 8 of RFC 4028.
When receiving an initial request and "fe-identifier" header field parameter of P-Charging-Vector header field is applied in the operator domain, the ISC gateway function acting as an entry point shall:
  • 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
  • delete in the P-Charging-Vector header field any received "fe-identifier" header field parameter.
When the ISC gateway function receives a response to an initial request (e.g. 183 or 2xx), the ISC gateway function shall:
  1. store the values from the P-Charging-Function-Addresses header field, if present;
  2. remove the "fe-identifier" header field parameter from the P-Charging-Vector header field, if present; and
  3. remove the P-Charging-Function-Addresses header field prior to forwarding the message.
With the exception of 305 (Use Proxy) responses, the ISC gateway function shall not recurse on 3xx responses.
Up

5.13.3.4  Subsequent requests  p. 382

Upon receipt of a subsequent request, the ISC gateway function shall:
  1. if the request is an INVITE request, then respond with a 100 (Trying) provisional response;
  2. if the request is a NOTIFY request with the Subscription-State header field set to "terminated" and the ISC gateway function has retained the SIP dialog state information for the associated subscription, once the NOTIFY transaction is terminated, the ISC gateway function can remove all the stored information related to the associated subscription;
  3. if the request is a target refresh request and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, then the ISC gateway function shall save the Contact and CSeq header field values received in the request such that the ISC gateway function is able to release the session if needed;
  4. if the subsequent request is other than a target refresh request (including requests relating to an existing dialog where the method is unknown) and the ISC gateway function is configured to perform application level gateway and/or transport plane control functionalities, then the ISC gateway function shall save the Contact and CSeq header field values received in the request such that the ISC gateway function is able to release the session if needed; and
  5. if the subsequent request is received from outside the trust domain, then the ISC gateway function shall remove a P-Charging-Vector header field, if present;
and forwards the request, based on the topmost Route header field, in accordance with the procedures of RFC 3261.
Up

5.13.3.5  Call release initiated by the ISC gateway function  p. 382

If the ISC gateway function provides transport plane control functionality and receives an indication of a transport plane related error the ISC gateway function may:
  1. generate a BYE request for the terminating side based on information saved for the related dialog; and
  2. generate a BYE request for the originating side based on the information saved for the related dialog.
Upon receipt of the 2xx responses for both BYE requests, the ISC gateway function shall release all information related to the dialog and the related multimedia session.
Up

5.13.4  THIG functionality in the ISC gateway function  p. 383

The ISC gateway function shall act according to the procedures defined for the IBCF in subclause 5.10.4 with the following exceptions:
  • there are no specific requirements for the REGISTER method, i.e. the REGISTER method is treated as for other SIP methods.

5.13.5  IMS-ALG functionality in the ISC gateway function  p. 383

The ISC gateway function shall act according to the procedures defined for the IBCF in subclause 5.10.5.

5.13.6  Screening of SIP signalling  p. 383

The ISC gateway function shall act according to the procedures defined for the IBCF in subclause 5.10.6.
Up

Up   Top   ToC