Contents

1   Introduction

This document specifies the SIP-based Ml interface used by the Emergency Call Session Control Function (E-CSCF) between the E-CSCF and the Location Repository Function (LRF).

Status codes generated by the CSCF are no longer part of this document, instead refer to CSCF Fault Codes Catalogue.

This document is based on the CSCF Mw Interface. It only describes the details that are relevant to the Ml interface. SIP headers that are not mentioned in this document are sent transparently to the LRF if received. For these and other details, refer to the CSCF Mw Interface.

Unless otherwise indicated, SIP headers are handled transparently by the E-CSCF in the Ml interface.

2   Interface Overview

This section describes the interface between the E-CSCF and the LRF as shown in Figure 1.

2.1   Interface Role

This section describes the role of the Ml interface in the E-CSCF.

2.2   Services

The services offered by the E-CSCF are shown in Table 1.

2.3   Encapsulation and Addressing

The E-CSCF supports SIP on User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) on IPv4 and IPv6.

The E-CSCF follows the procedures for SIP routing as specified in the following specifications:

• RFC 3261 Session Initiation Protocol
• RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
• RFC 4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
• RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification

3   Procedures

This section describes the procedures used with the offered and used interfaces of the E-CSCF.

An overview of the dynamics on Public Safety Answering Point (PSAP) address retrieval is shown in Figure 2.

An overview of initial subscription on dialog event is shown in Figure 3.

3.1   PSAP Address Retrieval

3.1.1   Initial INVITE Request

When a SIP INVITE is received, the E-CSCF sends an INVITE to the LRF, which includes information listed in Table 2.

When a 3xx is received from the LRF, the important information expected is listed in Table 3.

3.1.2   CANCEL INVITE Request

The CANCEL procedure is shown in Figure 4.

On receipt of a CANCEL, the E-CSCF sends the SIP CANCEL request to the LRF and it includes the mandatory parameters defined in RFC 3261 SIP: Session Initiation Protocol and relevant extensions to the RFCs.

The LRF sends the SIP 200 (OK) response to the E-CSCF.

3.1.3   Unsuccessful Cases at INVITE

The unsuccessful cases for PSAP address retrieval are shown in Figure 5 and Figure 6.

The provisional responses 1xx (except 100), and 2xx received from the LRF are proxied back to the Proxy Call Session Control Function (P-CSCF). This is if an LRF is not compliant to 3GPP® TS 24.229.

The 4xx, 5xx (except 503), and 6xx received from the LRF are dropped.

3.1.4   Alternative LRF

For 503 received or no response received before transaction time-out, if there are still alternative LRFs available, the E-CSCF routes the INVITE to the available alternative LRF.

3.2   Dialog Event Subscription

3.2.1   Initial Subscription Request

When a SIP SUBSCRIBE is received from the LRF in the E-CSCF, the important information that is expected is listed in Table 4.

(1)  The from-tag may be received but it is ignored.

A SIP NOTIFY is sent from the E-CSCF to the LRF, which includes information listed in Table 6.

SIP NOTIFY includes an XML document with the following information:

• version = 0
• state (attribute) = full.
• entity is set to the identity of the calling party, fetched from the Request-URI in the SUBSCRIBE request.
• dialog id is set to a single unique string.
• call-id = the value of Event header call-id parameter received.
• l ocal-tag = the value of Event header to-tag parameter received.
• direction = initiator.
• state (element) is set to the current state of Finite-State Machine (FSM). Supported states are proceeding, early, confirmed, and terminated.

3.2.2   Subscription Refresh Request

When a SIP SUBSCRIBE is received from the LRF in the E-CSCF, the important information expected is listed in Table 7.

A SIP NOTIFY is sent from the E-CSCF to the LRF, which includes information listed in Table 9.

SIP NOTIFY includes an XML document with the following information:

• version = stepped by 1 compared to previously sent XML document.
• state (attribute) = full.
• entity is set to the identity of the calling party, fetched from the Request-URI in the SUBSCRIBE request.
• dialog id is set to a single unique string.
• call-id = the value of Event header call-id parameter received.
• l ocal-tag = the value of Event header to-tag parameter received.
• direction = initiator.
• state (element) is set to the current state of FSM. Supported states are proceeding, early, confirmed, and terminated.

Note:  

If the request for subscription refresh is received after the INVITE dialog has terminated, no XML document is included in the SIP NOTIFY request.

3.2.3   Subscription Termination Request

When a SIP SUBSCRIBE is received from the LRF in the E-CSCF, the important information expected is listed in Table 10.

A SIP NOTIFY is sent from the E-CSCF to the LRF, which includes information listed in Table 12.

SIP NOTIFY includes an XML document with the following information:

• version = stepped by 1 compared to previously sent XML document.
• state (attribute) = full.
• entity is set to the identity of the calling party, fetched from the Request-URI in the SUBSCRIBE request.
• dialog id is set to a single unique string.
• call-id = the value of Event header call-id parameter received.
• l ocal-tag = the value of Event header to-tag parameter received.
• direction = initiator.
• state (element) is set to the current state of FSM. Supported states are proceeding, early, confirmed, and terminated.

Note:  

If the request for subscription termination is received after the INVITE dialog has terminated, no XML document is included in the SIP NOTIFY request.

3.2.4   Event Notification on INVITE Dialog State Change

A SIP NOTIFY is sent from the E-CSCF to the LRF when the INVITE dialog state changes. The SIP NOTIFY includes information listed in Table 13.

SIP NOTIFY includes an XML document with the following information:

• version = stepped by 1 compared to previously sent XML document.
• state (attribute) = partial.
• entity is set to the identity of the calling party, fetched from the Request-URI in the SUBSCRIBE request.
• dialog id is set to a single unique string.
• call-id = the value of Event header call-id parameter received.
• l ocal-tag = the value of Event header to-tag parameter received.
• direction = initiator.
• state (element) is set to the current state of FSM. Supported states are proceeding, early, confirmed, and terminated. When the state is changed to "terminated", the event attribute and code attribute are included.

3.2.5   Event Notification on Subscription Expiry

A SIP NOTIFY is sent from the E-CSCF to the LRF when the subscription expires, which includes information listed in Table 14.

SIP NOTIFY includes an XML document with the following information:

• version = stepped by 1 compared to previously sent XML document.
• state (attribute) = partial.
• entity is set to the identity of the calling party, fetched from the Request-URI in the SUBSCRIBE request.
• dialog id is set to a single unique string.
• call-id = the value of Event header call-id parameter received.
• l ocal-tag = the value of Event header to-tag parameter received.
• direction = initiator.
• state (element) is set to the current state of FSM. Supported states are proceeding, early, confirmed, and terminated.

3.2.6   Event Notification on Locked E-CSCF

A SIP NOTIFY is sent for each subscribe dialog from the E-CSCF to the LRF when the E-CSCF goes into administrative state LOCKED, which includes information listed in Table 15.

SIP NOTIFY includes an XML document with the following information:

• version = stepped by 1 compared to previously sent XML document.
• state (attribute) = partial.
• entity is set to the identity of the calling party, fetched from the Request-URI in the SUBSCRIBE request.
• dialog id is set to a single unique string.
• call-id = the value of Event header call-id parameter received.
• l ocal-tag = the value of Event header to-tag parameter received.
• direction = initiator
• state (element) is set to the current state of FSM. The event attribute and code attribute is to be included.

3.2.7   Unsuccessful Case at SUBSCRIBE

In the 489 (Bad Event) response to SUBSCRIBE sent by the E-CSCF to the LRF, the information included is listed in Table 16:

4   Information Model

This section describes supported SIP methods and gives information about SIP headers.

4.1   Supported SIP Methods

The following supported SIP methods are listed in Table 17.

(1)  SIP OPTIONS is only used for network monitoring, refer to CSCF Mw Interface.

4.2   SIP Header Information

4.2.1   Request-URI

The value of incoming Request-URI received is included in the Request-URI in the INVITE request to the LRF; it may be an emergency service URN (refer to RFC 5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services) or dialed string in SIP URI or tel URI.

4.2.2   P-Asserted-Identity

The E-CSCF includes a P-Asserted-Identity (PAI) header in the INVITE request to the LRF in the following scenarios:

• When there is PAI received in the original request from the P-CSCF.
• When there is a P-Preferred-Identity (PPI) header but no PAI received in the original request from the P-CSCF, if the ecscfNonRegAssertedCallerIdPreLrfEnabled is set to true, and a PAI can be created from the PPI successfully.

4.2.3   P-Preferred-Identity

The E-CSCF includes a P-Preferred-Identity (PPI) header in the INVITE request to the LRF in the following scenarios:

• When there is a PPI received together with a PAI in the original request from the P-CSCF.
• When there is a PPI received without a PAI in the original request from the P-CSCF, if the ecscfNonRegAssertedCallerIdPreLrfEnabled is set to false.
• When there is a PPI received without a PAI in the original request from the P-CSCF, if the ecscfNonRegAssertedCallerIdPreLrfEnabled is set to true, but a PAI cannot be created successfully.

4.2.4   Event

The EVENT header is received in the SUSBCRIBE request. The Event header value must be set to dialog and the call-id and to-tag parameters must be included.

The E-CSCF includes Event in the NOTIFY request. The id parameter is included if it was received in the SUBSCRIBE request.

4.2.5   Expires

The E-CSCF includes Expires in the 200 response to the SUBSCRIBE request to LRF. If the received value of Expires in the SUBSCRIBE request is greater than the system defined maximum (CscfDialogEventRefreshMax) or the Expires header was not received, then the configured maximum value is sent in the Expires header to the LRF. If the received value of Expires header in the SUBSCRIBE request is between the configured CscfDialogEventRefreshMin value and CscfDialogEventRefreshMax value, the same value that was received is returned to the LRF in the Expires header. If the received value of Expires header in the SUBSCRIBE request is less than the configured CscfDialogEventRefreshMin, the request is rejected.

4.2.6   Subscription State

The E-CSCF includes Subscription State in the NOTIFY request to LRF. The subscription state is either active or terminated. The subscription state is terminated either when LRF terminates the subscription (reason code is set to timeout), the subscription expires (reason code is set to timeout) or when the E-CSCF goes into administrative state LOCKED (reason code is set to noresource).

4.2.7   Allow-Events

The Allow-Events header includes a list of tokens which indicates the event packages supported by the E-CSCF, for example, dialog.

5   Formal Syntax

Not applicable.

6   Security Considerations

Not applicable.

7   Related Standards

This section states the related standards and explains any deviations from them.

The main related standards are 3GPP TS 24.229 IP Multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP), RFC 3261 Session Initiation Protocol, and ATIS-0700015.v003 ATIS Standard for Implementation of 3GPP Common IMS Emergency Procedures for IMS Origination and ESInet/Legacy Selective Router Termination.

Other applicable standards:

• RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers
• RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification
• RFC 3455 Private Header Extensions to the SIP for the 3GPP
• RFC 4235 An INVITE-Initiated Dialog Event Package for the Session Initiation Protocol (SIP)
• RFC 5031 A Uniform Resource Name (URN) for Emergency and Other Well-Known Services

The main deviations from the standards are as follows:

• SIPS URI is not supported,
• TLS is not supported.

8   Example of SIP NOTIFY Body

An example of the SIP NOTIFY body is as follows:

<?xml version="1.0"?>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
             version="2"
             state="full"
             entity="sip:alice@myvsp.com”>
      <dialog id="as7d900as8" call-id="a84b4c76e66710"
             local-tag="192831234" direction="initiator">
          <state event=”rejected” code=”486”>terminated</state>
      </dialog>
</dialog-info>

9   Examples of Contact SIP URI Header Components

This section shows examples of Contact headers including SIP URI header components returned in the 3XX response from the LRF.

The first SIP URI header component of the set is indicated with the "?" mechanism within the URI. Subsequent header names and values are encoded in ampersand ("&") separated hname = hvalue pairs. The special hname "body" indicated that the associated hvalue is the message-body of the outgoing SIP request.

Contact: sip:9981005003449@bgcf.one.att.net?P-Asserted-Identity= \⇒
sip:+11005003554%40bgcf.one.att.net&User-to-User=\⇒
001D4252807322943584000038A42064FF62F2101080939A%3Bencoding%3Dhex\⇒
%3Bpurpose%3Disdn-uui%3Bcontent%3Disdn-uui&X-Carrier-Info=\⇒
02fb05fe03000560&X-AUTH=fd01fc06

Note:  

To follow the syntax of SIP URI header component, the following characters have been escaped:

%3B is the escaped character for ";"

%40 is the escaped character for "@"

%3D is the escaped character for "="