5.11 Procedures at the E-CSCF

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

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

5.11.1 General

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 [26] 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.

NOTE 1: The E-CSCF would normally implement this override if the P-CSCF or S-CSCF is configured to pass on URIs (e.g. Request-URI) that are outside the responsible domain of the E-CSCF, otherwise emergency calls might not be routed to a PSAP. If the P-CSCF or S-CSCF does not do this, then the override need not be applied.

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.

NOTE 2: The protocol used between an E-CSCF and an external server is not specified in this version of the specification.

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 3GPP TS 22.101 [1A], the E-CSCF:

– shall provide the privacy service role according to RFC 3323 [33] and RFC 3325 [34];

NOTE 3: The procedure above is in addition to any procedure for the application of privacy at the edge of the trust domain specified by RFC 3325 [34] and subclause 4.4.

– 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);

NOTE 4: Operator policy can require retention/removal of user location information from such request or response separately from user identity, based on the national regulatory requirements.

prior to forwarding any such request to a PSAP.

NOTE 5: If the routeing functions are supported by an LRF, this information is not removed before the request is sent to the LRF.

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.

5.11.2 UE originating case

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 [69], or an emergency number the E-CSCF shall:

1) if:

a) 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;

NOTE 1: The E-CSCF is identified by two URIs, one preconfigured in the P-CSCF, AS or IBCF and one used to receive the request from EATF.

b) the Contact header field includes an instance-id feature tag containing an IMEI URN as specified in RFC 7254 [153] or an MEID URN as specified in RFC 8464 [187]. 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

c) 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 3GPP TS 32.260 [17];

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;

NOTE 2: Any received "orig-ioi" header field parameter will be a type 2 IOI generated by an S-CSCF or passed on by an IBCF. The type 2 IOI identifies the network from which the request was sent.

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 [90] and RFC 5491 [267], with the content type application/pidf+xml, as described RFC 6442 [89]; and

– location identifier as derived from the P-Access-Network-Info header field, if available.

NOTE 3: As an alternative to retrieve location information from the LRF the E-CSCF can also request location information from an external server. The address to the external server can be received in the Geolocation header field as specified in RFC 6442 [89]. The protocol used to retrieve the location information from the external server is not specified in this version of the specification.

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:

a) a PSAP connected to the IM CN subsystem or another network, and add the PSAP URI to the topmost Route header field; or

NOTE 4: 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, the E-CSCF conveys the Geolocation header field (if present), the Geolocation-Routing header field (if present), the location information in a PIDF location object (if present) and the P-Access-Network-Info header field containing the location identifier, if defined for the access type as specified in subclause 7.2A.4, to the PSAP.

b) 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";

NOTE 5: 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, the E-CSCF conveys the Geolocation header field (if present), the Geolocation-Routing header field (if present), the location information in a PIDF location object (if present) and the P-Access-Network-Info header field containing the location identifier, if defined for the access type as specified in subclause 7.2A.4, towards the MGCF. The MGCF can translate the location information if included in INVITE (i.e. both the geographical location information in PIDF-LO and the location identifier in the P-Access-Network-Info header field) into ISUP signalling, see 3GPP TS 29.163 [11B].

NOTE 6: The way the E-CSCF determines the next hop address when the PSAP address is a tel URI is implementation dependent.

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]);

NOTE 7: A P-Asserted-Identity header field that is present can contain a reference number used in the communication between the PSAP and LRF according to procedures in subclause 5.11.3. Such a P-Asserted-Identity header field would not be replaced with a P-Asserted-Identity header field set to a non-dialable callback number.

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.

NOTE 8: Depending on local operator policy, the E-CSCF has the capability to reject requests relating to specific methods in accordance with RFC 3261 [26], as an alternative to the functionality described above.

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.

NOTE 9: Numbers that can be recognized as valid emergency numbers if dialled by the user are specified in 3GPP TS 22.101 [1A]. The emergency numbers 112 and 911 are stored on the ME, in accordance with 3GPP TS 22.101 [1A].

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.

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

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 RFC 4028 [58] clause 8.

NOTE 11: Requesting the session to be refreshed requires support by at least the UE or the PSAP or MGCF. This functionality cannot automatically be granted, i.e. at least one of the involved UAs needs to support it in order to make it work.

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.

5.11.3 Use of an LRF

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 [69], or an emergency number, to the LRF in accordance with the procedures of RFC 3261 [26].

NOTE 1: The E-CSCF is by definition responsible for emergency service URNs and is therefore allowed to change the Request-URI of requests containing emergency service URNs when a 3xx or 416 response is received.

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 [26] and continue processing the steps given in subclause 5.11.2 with the following additions:

a) 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;

b) 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;

c) 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;

NOTE 2: Such a P-Asserted-Identity header field contains a reference number which is used in the communication between the PSAP and LRF.

d) 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 [186] 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 [90] and RFC 5491 [267], then the E-CSCF shall insert a Geolocation header field containing this PIDF location object by reference (see RFC 6442 [89]);

e) if the location source parameter for the SIP Geolocation header field as defined in RFC 8787 [266] is supported, include a loc-src parameter in the Geolocation header field set to the domain name of the visited network; and

f) if operator policies allow forming requests from a URI and if 3xx response is received, then follow the procedures of RFC 3261 [26] subclause 19.1.5 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 [26] 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 [26].

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.

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

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.

5.11.4 Subscriptions to E-CSCF events

5.11.4.1 Subscription to the event providing dialog state

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

NOTE: Any received "orig-ioi" header field parameter will be a type 3 IOI. The type 3 IOI identifies the service provider from which the request was sent.

4) generate a 200 (OK) response acknowledging the SUBSCRIBE request and indicating that the authorised subscription was successful as described in RFC 4235 [171]. 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.

5.11.4.2 Notification about dialog state

The E-CSCF shall send a NOTIFY request when an event pertaining to the dialog or dialogs occurs, as specified in RFC 6665 [28].

When generating NOTIFY requests, the E-CSCF shall not preclude any valid dialog event package parameters in accordance with RFC 4235 [171]. Where RFC 4235 [171] 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 [171], the E-CSCF shall:

1) set the P-Charging-Vector header field with the "icid-value" header field parameter populated as specified in 3GPP TS 32.260 [17], 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.

NOTE: Any received "term-ioi" header field parameter will be a type 3 IOI. The type 3 IOI identifies the service provider from which the response was sent.

5.11.4.3 Subscription to the presence event package

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:

a) the call identifier in the callid portion of the Target-Dialog header field; and

b) 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 :

a) 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

b) 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

NOTE: Any received "orig-ioi" header field parameter will be a type 3 IOI. The type 3 IOI identifies the service provider from which the request was sent.

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 [171]. 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

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.

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.

5.11.4.4 Notification about presence

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 [28]. 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 3GPP TS 32.260 [17], 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 3GPP TS 32.260 [17], 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.

NOTE: Any received "term-ioi" header field parameter will be a type 3 IOI. The type 3 IOI identifies the service provider from which the response was sent.

5.11.5 Current location discovery during an emergency call

5.11.5.1 General

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

5.11.5.2 Requesting current location informaton

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

5.11.5.3 Receiving current location informaton

Upon receiving a PUBLISH request as described in RFC 3903 [70] 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.