Subject: [Ecrit] Conference call on IETF/3GPP emergency call

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Tue, 14 Nov 2006 16:47:10 +0100

A repeat of the conference call information and some discussion points
at the end of the mail.

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

And the normative references from these.

Conference details
------------------

Details for the call are as follows:

Date: Wednesday 15th November
Time:	8:00 am Central US time
	9:00 am Eastern US time
	2:00 pm UK time
	3:00 pm Central European time
	4:00 pm Finland
I will leave others to extrapolate for other locations.

Expected duration: 2 hours - if we need longer we will organise follow
call(s).

Chairperson Name:  KEITH DRAGE
Company:  LUCENT TECHNOLOGIES READY ACCESS Access Phone Number:
8007718734 International Access Phone Number:  +1 6477233953 7-Digit
Access Code:  5776249 

Participation
-------------
I am circulating this mail to participants in 3GPP SA2, 3GPP CT1, ETSI
TISPAN WG2, ETSI TISPAN WG3, IETF ECRIT. If you know someone who should
be involved, please forward this email.

This is an open conference call. The conference bridge is good up to
about 50 ports. However this will not be a tutorial. You will be
expected to have a working knowledge of at least some of the key
documents. 

I will attempt to ensure we have some notes of the discussions to
circulate.

It would help to send me a mail indicating you intend to participate, if
only to ensure that I get your name spelled right on the notes.
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 (no particular order and some are minor)
==========================================================

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.

A)	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. 

B)	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.

C)	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.

D)	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).

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

E)	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.

F)	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.

G)	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.

H)	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.

I)	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.

J)	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.

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

   3.   The From: header MUST be present and SHOULD be the AoR of the
        caller.

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

   6.   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).

L)	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.

M)	Presence
--------------

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

   3.  (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.

N)	Session timer
-------------------

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

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

Session timer support is optional in 3GPP terminals.

O)	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.

P)	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.

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

Q)	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.

R)	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
   3 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.

S)	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.

T)	emergency registration (not currently part of the IETF
architecture)

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

V)	location determination mechanisms, and underlying 3GPP location
architecture

Regards

Keith

Keith Drage
Lucent Technologies
[email-masked]
tel: +44 1793 776249

_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 15 Nov 2006 15:14:31 +0100

Hi Keith,

I am unable to connect to the conference bridge. I get the error message 
"Access Code Invalid"

Ciao
Hannes