IETF ECRIT / 3GPP / TISPAN Emergency Services Work

Documentation

The 3GPP stage 2 is contained in: http://www.3gpp.org/ftp/Specs/html-info/23167.htm

You may also wish to browse 23.271 referenced from this document.

The 3GPP stage 3 is contained in: http://www.3gpp.org/ftp/Specs/html-info/24229.htm
Specifically sections 5.1.6, 5.2.10, 5.4.8 and 5.11.

The TISPAN stage 2, which is an endorsement of the above is (ETSI TS 182009 - if the link does not work):
http://pda.etsi.org/PDA/copy_file.asp?Action_type=&Action_Nb=&Profile_id=Qjgue5axQBa7L4A86'9Ao&Wki_Id=7ooWqIsa1YnpntptUveYX

The IETF documents are:
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-framework-00.txt http://www.ietf.org/internet-drafts/draft-ietf-ecrit-phonebcp-00.txt

Terminology

The 3GPP E-CSCF and the IETF ECRIT ESRP (Emergency Service Routeing Proxy) appear to be roughly compatible in functionality. Note that the 3GPP P-CSCF also has to recognise emergency calls in order to route them to the E-CSCF.

Discussion points

I did a quick work through of the documents to identify areas where things are different, or just not covered, and should therefore be discussed. We may want to skip minor issues until later.

LCP

draft-ietf-ecrit-phonebcp-00 section 4: Draft-ietf-ecrit-framework-00 section 5.5:

For devices that operate on a network where the network operator controls the specification of every device connected to that network that could be used for emergency calls, the method by which location is determined need not be an IETF standard, but can be any method that achieves the desired result. Such a method MUST be specified, and every device MUST support it.

For all other devices, location configuration by DHCP, [Placeholder for L7 LCP] and LLDP-MED MUST be supported. DHCP [RFC2131] has been enhanced to provide the location of a device. [RFC3825] describes how a geo-location (lat/lon/alt) may be obtained and [I-D.schulzrinne-geopriv-dhcp-civil] describes how a civic (street address) location can be obtained via DHCP.

...

For devices that operate on a network where the network operator does not control the specification of every device connected to the network, at least one of DHCP, [L7 LCP] or LLDP-MED MUST be supported on the network.

...

Devices SHOULD get location immediately after obtaining local network configuration information. It is essential for the location to be determined BEFORE any VPN tunnels are established. It is equally essential that this location information is not overwritten by any process engaged from establishing a VPN connection. In other words, the established VPN to Chicago from the device in Dallas should not overwrite the Dallas location for any reason especially an emergency call.

Referring to LCP:

Where an access network can control the specification of EVERY endpoint that could make an emergency call that is directly connected to the network, or indirectly connected (for example, a device on a LAN behind a network attachment unit), it may specify any protocol it wishes for each endpoint. This is a very unusual case; nearly every access network can be used to support an Ethernet based LAN behind it. For example, existing mobile networks are being used to support routers and LANs behind a wireless data network WAN connection. It is possible that the access network supports a protocol not on the phonebcp list, but another element which the access network provider controls the specification of can acquire location using that protocol and then that element can support one of the phonebcp's list of protocols. For example, if the access network provider supplies a router which includes a DHCP server, it can acquire location using an access network specific protocol, and use the location information to supply it to its clients via DHCP.

I don't believe that 3GPP, after the work with TISPAN, can now claim the exemption, as TISPAN allows legacy SIP terminals on the system. 3GPP does not support a location configuration protocol on its terminals.

LoST usage

Draft-ietf-ecrit-framework-00 section 3: draft-ietf-ecrit-phonebcp-00 section 2: draft-ietf-ecrit-phonebcp-00 section 6.1: draft-ietf-ecrit-phonebcp-00 section 6.2:

We route( (Section 6)) the call based on location using the LoST protocol ( [I-D.ietf-ecrit-lost]) which maps a location to a set of PSAP URIs. Each URI resolves to a PSAP or an Emergency Services Routing Proxy which serves a group of PSAPs. The call arrives at the PSAP with the location included in the INVITE request.

o It would determine the PSAP's URI by using the [I-D.ietf-ecrit-lost] mapping server from the location provided in the signaling

1. The Request URI SHOULD be a PSAP URI obtained from LoST (see Section 6.2). If the device cannot access a LoST server, the To: SHOULD be a service URN in the "sos" tree. If the device cannot do local dialstring interpretation, the Request URI: SHOULD be a dialstring URI [I-D.rosen-iptel-dialstring]with the dialed digits. sips MUST be specified, unless the operation must be retried due to a failure to establish a TLS connection.

User agents that can obtain location information MUST perform the mapping from location information to PSAP URI using [I-D.ietf-ecrit-lost]. The mapping is performed whenever the UA acquires new location information that is outside the bounds of the current PSAP coverage region specified in the LoST response or the time-to-live value of that response has expired.

No current 3GPP decision to use LoST, although it could be suitable between E-CSCF and LRF. Certainly there is no guarantee of support of a LoST query from the terminal.

Recognition of emergency calls

draft-ietf-ecrit-phonebcp-00 section 6.2:

All proxies in the outbound path SHOULD recognize emergency calls with a Request URI of the service URN in the "sos" tree. A proxy recognizing such a call (which indicates that the endpoint understood the call was an emergency call, but was unable to map its location to a PSAP URI) MUST perform the LoST mapping and retarget the call to the PSAP URI (the service URN SHOULD remain as a Route header).

To deal with old user agents that predate this specification and with UAs that do not have access to their own location data, proxies that recognize a call as an emergency call that is not marked as such (see Section 5) or where the Request-URI is a service:sos URN MUST also perform this mapping, with the best location it has available for the endpoint. The resulting PSAP URI would become the Request URI.

In 3GPP all intermediate proxies recognise emergency calls. However they route emergency calls to a special proxy called E-CSCF that performs the location to URI mapping rather than perform it at the proxy concerned.

Usage of sos URN

draft-ietf-ecrit-phonebcp-00 section 5: draft-ietf-ecrit-phonebcp-00 section 6.1:

Devices MUST use the service:sos URN scheme to mark emergency calls.

To determine which calls are emergency calls, some entity needs to map a user entered dialstring into this URN scheme. A user may "dial" 1-1-2, but the call would be sent to urn:service:sos. This mapping is SHOULD performed at the endpoint device, but MAY be performed at an intermediate entity (such as a SIP proxy server).

1. The To: header MUST be present and SHOULD be a service URN in the "sos" tree. If the device cannot do local dialstring interpretation, the To: SHOULD be a dialstring URI with the dialed digits. sips MUST be specified, unless the operation must be retried due to a failure to establish a TLS connection.

Not an issue in 3GPP, as this is what is specified. Except that 3GPP IMS cannot support TLS connections. Note that SIPS may not in any case be appropriate for PSTN connected PSAPs where interworking is involved.

Dialstring provisioning

draft-ietf-ecrit-phonebcp-00 section 5:

The home emergency dialstrings MAY be provisioned into the device (or other element doing dialstring to universal emergency call URN mapping). [I-D.ietf-ecrit-lost]) provides dialstrings for a given location and SHOULD be used by devices to learn the local (i.e. "visited" dialstrings.

3GPP currently has its own mechanisms for doing this, and does not use LoST. These mechanism are however access specific, and are not provided (except by prior configuration) in WLAN terminals and DSL terminals.

Location

Draft-ietf-ecrit-framework-00 section 5.2:

Cell tower/sector: Cell tower and sectors identify the cell tower and the antenna sector that the mobile device is currently using. Traditionally, the tower location is expressed as a point, and routing decisions are made on that point. Cell/sector information could also be transmitted as an irregularly shaped polygon of geospatial coordinates reflecting the likely geospatial location of the mobile device.

For 3GPP IMS, in addition to normal location field, this information would be expected to be available at the E-CSCF in the P-Access-Network-Info header (for 3GPP/3GPP2 accesses). For DSL it would contain a location id which would have to be mapped using some database to a real location. For WLAN it may ultimately be some form of MAC address.

Delivery of location to PSAP

Draft-ietf-ecrit-framework-00 section 5.3:

All location objects MUST be delivered to the PSAP. To facilitate such policy decisions, location information should contain information about the source of data, such as GPS, manually entered or based on access network topology. In addition, the generator of the location information should be included. The ability of the UA to understand how it learned its location, and include this information element in the location object that is sent to the PSAP, provides the call-taker with many pieces of information to make decisions upon, and ask the caller with.

Not necessarily an issue in itself, but may be difficult to interwork with the PSTN to supply to PSTN based PSAPs.

Indication of location used for routeing

Draft-ietf-ecrit-framework-00 section 5.3:

The call should indicate which location information has been used for routing, so that the same location information is used for all call routing decisions. Otherwise, two proxies might pick different location information from the call request, resulting in different routing decisions for different transactions.

Not yet covered in 3GPP documentation.

Security mechanisms

Draft-ietf-ecrit-framework-00 section 7:

Since emergency calls carry privacy-sensitive information, they are subject to the requirements for geospatial protocols [RFC3693]. In particular, signaling information should be carried in TLS, i.e., in 'sips' mode. While requiring TLS is actually the way the standards are written, it is unacceptable to have an emergency call fail to complete because a TLS connection was not created, for any reason. In many cases, persistent TLS connections can be maintained between elements to minimize the time needed to establish them.

3GPP networks do not use TLS, but provide security using trust relationships and IPsec.

GRUU usage

Draft-ietf-ecrit-framework-00 section 9:

The call-taker must be able to reach the emergency caller if the original call is disconnected. In traditional emergency calls, wireline and wireless emergency calls include a callback identifier for this purpose. In SIP systems, the caller should include a Contact header field indicating its device URI, if available, or possibly a GRUU[I-D.ietf-sip-gruu] if calls need to be routed via a proxy. This identifier would be used to initiate call-backs immediately by the call-taker if, for example, the call is prematurely dropped.

GRUU will be supported in 3GPP release 7. GRUU requires registration. Not all 3GPP emergency calls require prior registration. In 3GPP also not considered the interaction of GRUU with 3GPP emergency registration.

Calling identity

Draft-ietf-ecrit-framework-00 section 9 and 16.1: draft-ietf-ecrit-phonebcp-00 section 6.1:

In addition, a call-back identifier should be included either as the URI in the From header field [RFC3261] preferably verified by SIP Identity[RFC4474]. This identifier would be used to initiate a call- back at a later time and may reach the caller, not necessarily on the same device (and at the same location) as the original emergency call.

Fraudulent calls to PSAPs is a significant concern. Current systems rely on inherent security mechanisms in the PSTN to make sure the identity of the caller is known. As Internet technologies are increasingly used to place calls, it is becoming easier to hide the indentity of a caller. Use of the SIP Identity mechanism [RFC4474] i is recommended. If SIP Identity cannot be provided, carriers should make use of P-Asserted-Identity, [RFC3325]

1. The From: header MUST be present and SHOULD be the AoR^? of the caller.

1. A Via: header MUST be present and SHOULD include the URI of the device

1. Either a P-Asserted-Identity [RFC3325] or an Identity header [RFC4474], or both, SHOULD be included to identify the sender.

TISPAN emergency call requirements, based on NTT input, require privacy rules to be adhered to for emergency calls.

Neither TISPAN or 3GPP have indicated any intent to adopt RFC 4474 and currently use only RFC 3325.

3GPP indicates that if privacy is required then To: field should be set to anonymous (this is an ordinary call bit of text that applies by default to emergency calls as well).

REFER usage

Draft-ietf-ecrit-framework-00 section 10: draft-ietf-ecrit-phonebcp-00 section 6.4:

A PSAP may need to REFER[RFC3515] a call to a bridge for conferencing. The caller should also be prepared to have the call transferred (usually attended, but possibly blind) as per[I-D.ietf-sipping-service-examples].

The PSAP is expected to use normal signaling (e.g. SIP) as per IETF standards. Devices and proxies should expect to:

1. Be REFERed to a conference bridge; PSAPs often include dispatchers, responders or specialists on a call.
2. Be REFERed to a secondary PSAP. Some responder's dispatchers are not located in the primary PSAP. The call may have to be transferred to another PSAP. Most often this will be an attended transfer, or a bridged transfer.

Not taken account of by 3GPP specifications. If PSAP is PSTN connected, REFER currently not supported by interworking gateway. In 3GPP specs, REFER is currently optional to UAs.

Presence

draft-ietf-ecrit-phonebcp-00 section 6.4:

1. (For devices that are Mobile) SUBSCRIBE to the Presence of the AoR^? (or equivalent for other signaling schemes) to get location updates.

Presence support is optional in 3GPP terminals.

Session timer

draft-ietf-ecrit-phonebcp-00 section 6.4:

1. Support Session Timer (or equivalent) to guard against session corruption

Session timer support is optional in 3GPP terminals.

Session clearing

draft-ietf-ecrit-phonebcp-00 section 6.4:

Devices with an active emergency call (i.e. SIP Dialog) MUST NOT generate a BYE request (or equivalent for other non-SIP signaling). The PSAP must be the only entity that can terminate a call. If the user "hangs up" an emergency call, the device should ring, and when answered, reconnect the caller to the PSAP.

3GPP terminals are not allowed to hang up, but specification of the user interface is outside the scope of the 3GPP specifications, so the detail about local ringing has not been covered.

Media types

Draft-ietf-ecrit-framework-00 section 12: draft-ietf-ecrit-phonebcp-00 section 3: draft-ietf-ecrit-phonebcp-00 section 6.1:

Newer text forms are rapidly appearing, with Instant Messaging now very common, PSAPs should accept IM with at least [RFC3428] as well as [RFC3920].

Using current (evolving) standards, devices that create media sessions and exchange audio, video and/or text, and have the capability to establish sessions to a wide variety of addresses, and communicate over private IP networks or the Internet, should support emergency calls.

1. A normal SDP offer SHOULD be included in the INVITE. The offer SHOULD NOT include compressed audio codecs, although a wideband codec offer MAY be included.

Note

Silence suppression (Voice Activity Detection methods) MUST NOT be used on emergency calls. PSAP call takers sometimes get information on what is happening in the background to determine how to process the call.

Currently 3GPP has only specified voice. MESSAGE method is not included. MSRP and real time text would be subject to end to end negotiation with the PSAP and would not be supported by an intermediate PSTN gateway. Neither would they be interworked with existing mechanisms.

What is a compressed audio codec. Is AMR one? If so this is the only codec likely to be used from 3GPP terminals. Operators are unlikely to approve of G.711 over the air, assuming there was enough bandwidth to get it there in the first place - it would need at least 3G speeds.

Supplementary services

draft-ietf-ecrit-phonebcp-00 section 6.5:

The calling device and/or service SHOULD disable outgoing call features such as: o Call Waiting o Call Transfer o Three Way Call o Flash hold o Outbound Call Blocking

The emergency dialstrings SHOULD NOT be permitted in Call Forward numbers or speed dial lists.

The device and/or service SHOULD disable the following incoming call features on calls from the PSAP: o Call Waiting (all kinds) o Do Not Disturb o Call Forward (all kinds) (if the PSAP calls back within some (30min?) interval)

Not covered at the moment in 3GPP specifications.

Test

draft-ietf-ecrit-phonebcp-00 section 7.1:

INVITE requests to a service urn with a urn parameter of "test" indicates a request for an automated test. For example, "urn:service.sos.fire;test". As in standard SIP, a 200 (OK) response indicates that the address was recognized and a 404 (Not found) that it was not. A 486 (Busy Here) should be returned if the test service is busy, and a 488 (Not Acceptable Here) should be returned if the PSAP does not support the test mechanism.

...

A PSAP accepting a test call SHOULD accept a media loopback test[I-D.ietf-mmusic-media-loopback] and SHOULD support the "rtp-pkt- loopback" and "rtp-start-loopback" options. The user agent would specify a loopback attribute of "loopback-source", the PSAP being the mirror. User Agents should expect the PSAP to loop back no more than

1. packets of each media type accepted, after which the PSAP would normally send BYE.

User agents SHOULD perform a full call test, including media loopback, after a disconnect and subsequent change in IP address. After an initial IP address assignment test, a full test SHOULD be repeated approximately every 30 days with a random interval.

User agents MUST NOT place a test call immediately after booting, as a widespread power outage and subsequent restoration would impose an inordinate load on the emergency call routing system.

PSAPs MAY refuse repeated requests for test from the same device in a short period of time.

Not covered at moment in 3GPP specifications.

Configuration

Draft-ietf-ecrit-framework-00 section 18.1:

draft-ietf-sipping-config-framework is included in the normative references, but no text exists in the document apparently. It should be noted that 3GPP at the moment only supports OMA DM for terminal configuration.

Other discussion points

Some of these may come up in the discussion above, but these have been specifically suggested to me.

Emergency registration

(not currently part of the IETF architecture)

Call identification

(likely IETF outcome: request URI = sos URN plus loose routing)

Location determination mechanisms, and underlying 3GPP location

-- HannesTschofenig - 29 Nov 2006