One document matched: draft-winterbottom-ecrit-direct-00.xml
<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC5222 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5222.xml">
<!ENTITY RFC3261 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY I-D.ietf-ecrit-phonebcp PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-phonebcp.xml">
<!ENTITY I-D.ietf-sip-gruu PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-gruu.xml">
<!ENTITY I-D.ietf-sip-outbound PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-outbound.xml">
<!ENTITY I-D.patel-ecrit-sos-parameter PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.patel-ecrit-sos-parameter.xml">
<!ENTITY I-D.ietf-sipcore-location-conveyance PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipcore-location-conveyance.xml">
<!ENTITY I-D.thomson-geopriv-res-gw-lis-discovery PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.thomson-geopriv-res-gw-lis-discovery.xml">
<!ENTITY I-D.ietf-geopriv-held-identity-extensions PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-held-identity-extensions.xml">
<!ENTITY I-D.schulzrinne-ecrit-psap-callback PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.schulzrinne-ecrit-psap-callback.xml">
<!ENTITY RFC3841 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3841.xml">
<!ENTITY RFC5031 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
<!ENTITY I-D.ietf-ecrit-lost-servicelistboundary PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-lost-servicelistboundary.xml">
<!ENTITY I-D.ietf-ecrit-framework PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ecrit-framework.xml">
<!ENTITY I-D.rosen-ecrit-premature-disconnect-rqmts PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.rosen-ecrit-premature-disconnect-rqmts.xml">
<!ENTITY RFC5234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY RFC3969 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3969.xml">
]>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<rfc category="bcp" ipr="trust200902" docName="draft-winterbottom-ecrit-direct-00.txt">
<front>
<title abbrev="ECRIT Direct">ECRIT Direct Emergency Calling</title>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<city>University of Wollongong</city>
<region>NSW</region>
<code>2500</code>
<country>AU</country>
</postal>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<region/>
<code>02 600</code>
<country>Finland</country>
</postal>
<email>Hannes.Tschofenig@gmx.net</email>
</address>
</author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs+ecrit@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<date year="2009"/>
<area>RAI</area>
<workgroup>ECRIT</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>This document describes a generic emergency calling client. </t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The current IETF ECRIT architecture, as described in <xref target="I-D.ietf-ecrit-phonebcp"
/> and in <xref target="I-D.ietf-ecrit-framework"/>, focuses on devices where emergency
calls are routed primarily through the subscriber's home VSP and the direct signaling
communication between the end host and the PSAP that contains the IP-based PSAP is only an
exception. This is a convenient assumption if one considers the regular communication
patterns of the device and the potential proprietary protocol implementations used between
the end host and the VSP and the ability to move the interoperability challenges away from
the end device and closer to VSPs. There are, however, challenges for regulators to enforce
emergency services functionality when the VSP is located in a different jurisdiction with
the current model. Inclusion of a VSP introduces unnecessary elements into the emergency call path
making the overall solution more cumbersome.</t>
<t> This document describes the regulatory challenge and illustrates a model for direct
communication between the end host and the PSAP that is supported by the basic SIP
communication patterns. With the help of the Location-to-Service Translation protocol a PSAP
URI is discovered that allows the end device to directly send SIP communication requests
towards the PSAP. </t>
<t> Note that the information returned by LoST may not necessarily be the address of the PSAP
itself but might rather be an entity that gets the emergency call closer to the PSAP by
returning the address of an Emergency Services Routing Proxy (ESRP). </t>
<t>This memo attempts to address the issues raised above and describe the requirements,
procedures and operations necessary for a generic IP emergency calling client. The intent of
this client is that it will be able to use the available ECRIT building blocks to allow any
IP enabled device with access to the Internet to make an emergency call without requiring a
voice service subscription. Further more, a means for call-back in the event of a dropped
call is also described. </t>
</section>
<section anchor="terminology" title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in
<xref target="RFC2119"/>. </t>
</section>
<section title="The Jurisdictional Problem">
<t>The jurisdictional problem is illustrated with <xref target="juris"/> that highlights that
providing the data in the Location Information Server (LIS) and the LoST server are correct,
that the caller and the PSAP are assured of being in the same regulatory jurisdiction. This
is important, because it shows that it is the access component of the network and not the
service component against which reguatory obligations can be imposed with any hope of
enforcement. Regulation without the possibility of enforcement is challenging as there is
very little coordination between regulators world wide in this area, consequently any
emergency calling procedure should ensure that all nodes against which the procedures apply
fall within the same regulatory boundary. </t>
<t>
<figure anchor="juris" title="Jurisdictional Boundaries in Internet Emergency Calling">
<artwork><![CDATA[
+-----+
| VSP |
| # |
+-----+
o-------------o----------------------o-------------o
/ \
/ +---------+ +--------+ \
/ | Access \ ASSURED / ESINet \ \
o | Network \ / \ o
| + + COMMON + O + |
| / O | / <P\ | |
| + <C\ o REGULATORY + /'\ + |
| | /'\ / | PSAP / o
o + Caller + JURISDICTION + +-------+ + /
\ \ __________| \ / \/ /
\ /
o--------------o----------------------o---------------o
]]>
</artwork>
</figure>
</t>
</section>
<section title="Network Reference model">
<t>In many deployments today the emergency calling device is located behind a NAT or a
firewall, and there is no assumption or requirement for a VSP subscription to exist. <xref
target="network"/> illustrates such a typical scenario. Indeed any subscription of this
nature is immaterial to the operation described in this memo.</t>
<t>
<figure anchor="network" title="Network Configuration">
<artwork><![CDATA[
.... ....
,' ',' ',
+----------+ ; ;
+--------+ | Firewall | ; ; +------+
| Device |--->| NAT | --->: ISP :----->| ESRP |
+--------+ +----------+ ; ; +------+
`, ,', ,'
{ } { }
```` ````
]]>
</artwork>
</figure>
</t>
</section>
<section title="ESRP Route Determination">
<t>The ESRP is discovered by the emergency client obtaing its location from a LIS, for
example, using HELD, and then using LoST to resolve the location and 'urn:services.sos'
Service URN to the ESRP URI. </t>
<t> When the emergency client is started the device needs to perform LIS and LoST server
discovery, as described in Section 7 of <xref target="I-D.ietf-ecrit-phonebcp"/>. </t>
<t>The emergency client MUST support location acquisition and the LCPs described in Section
6.5 of <xref target="I-D.ietf-ecrit-phonebcp"/>. The description in Section 6.5 and 6.6 of
<xref target="I-D.ietf-ecrit-phonebcp"/> regarding the interaction between the device and
the LIS applies to this document. </t>
<t> The emergency client MUST use LoST <xref target="RFC5222"/> to obtain an ESRP URI. The
exact timing of individual LoST lookups may vary based on a number of factors, including the
design of the user interface. For example, a hypothetical user interface may offer an
emergency call button that triggers a <listServicesByLocation> interaction to
learn about the available emergency services (potentially using the serviceListBoundary
extension defined in <xref target="I-D.ietf-ecrit-lost-servicelistboundary"/>). The service
options may be presented to the emergency caller in a graphical fashion and once a specific
service is selected a LoST query would be initiated (unless a cached mapping is available
that makes this request obsolete). The LoST <findService> query to obtain the
ESRP URI for the selected service is in this example initiated at the time the emergency
call setup is performed. It is recommended that ESRP discovery occurs at call time. </t>
</section>
<section title="Emergency Client Registration">
<t>Emergency registration is only necessary when an emergency call procedure is initiated.
Immediately prior to making an emergency call, the emergency client performs a SIP emergency
registration with the registrar in the ESRP, the ESRP-registrar. The emergency registration
is a SIP registration with specific options and headers which are required in order to guard
the emergency network and ensure callback should it be required. </t>
<t>Each emergency client MUST provide an instance-id, as defined in <xref
target="I-D.ietf-sip-outbound"/>, this allows the ESRP-registrar to generate a GRUU <xref
target="I-D.ietf-sip-gruu"/> that can be used as a callback identifier. A GRUU is
necessary as the callback identifier because the emergency client does not provide a
longer-term contact address to the ESRP-registrar prior to registration, and the GRUU
provides a handle by which the PSAP can identify the calling emergency client. To simplify
the emergency client and ESRP-registrar implementations, only public GRUUs are provided by
the ESRP-registrar. The public GRUU is guaranteed to be the same for a device regardless of
re-registration with a different call-id, which may occur if the device unexpectedly reboots.
This is not true for temporary GRUUs, which makes temporary GRUUs undesriable in the scope
of this application space. </t>
<t> The PSAP is able to define and mandate the time over which callback is possible. This
needs to be a reasonable period of time, nominally 10s of minutes, as the device may well be
transient with regards to network attachment. The ESRP-registrar reflects the regulatory
callback period in the expiry value of emergency registration responses. Emergency clients
claiming compliance to this specification MUST honour the value in the registration response
from the ESRP-registrar, up to a maximum of 60 minutes. An emergency client SHOULD respect a
registration expiry of longer than 60 minutes, but MAY terminate its registration with and
ESRP-registrar at 60 minutes if the expiry value provided by the ESRP-registrar was longer. </t>
<t> In the event that a registration is lost by the emergency client prior to reaching
registration expiry then the emergency client MUST re-register with the ESRP-registrar and
SHOULD use the same call-id. In this circumstance the ESRP-registrar SHOULD match the
instance-id and the call-id to recognize that it is a re-registration for a dropped
connection, and expiry time in the registration response SHOULD be set to the time remaining
from the original registration occurred. </t>
<t>
<xref target="I-D.ietf-sip-outbound"/> requires a device to support at least 2 registrations
to different proxies. The emergency client requirements in this memo relax this requirement
down to one registration, but more than one is allowed. There are several reasons for
relaxing the connection redundancy requirement. Firstly, ESRPs are expected to have inbuilt
redundancy, so if a connection is dropped due to a failed proxy in the ESRP, then a new
connection or registration will automatically be directed to an active proxy in the ESRP
cluster. If the connection dropped because of some other failure along the path from the
emergency client to the ESRP, then multiple SIP registrations are unlikely to provide any
measurable reliability improvements since single points of failure in this path are
inherently likely. Secondly, re-registrations only occur immediately prior to call
placement, so any outbound failure will also likely result in the call dropping. If this
occurs then the emergency client MUST re-register with the ESRP-registrar, and since
instance-id and public GRUU will remain unchanged as a result of this, the emergency client
can either receive a callback from the PSAP, or it can initiate a new call to the emergency
network. </t>
<t> Location information is critical to emergency calling. Providing location information to
the calling-entity with sufficient granularity to allow ESRP route determination is crucial.
Since this must occur prior to the emergency client registering with the ESRP-registrar, the
emergency client must have access to a certain amount of location information (and the
amount varies depending on the specific emergency services deployment architecture). </t>
<t> The device SHOULD include all the location information it has when registering with the
ERSP-registrar. Inclusion of location information in SIP REGISTER messages is specified in
<xref target="I-D.ietf-sipcore-location-conveyance"/>. There are three possible execution
paths for the ESRP-registrar when receiving a REGISTER message: <list style="numbers">
<t> If the REGISTER message does not include location information the ESRP-registrar MUST
use HELD identity <xref target="I-D.ietf-geopriv-held-identity-extensions"/> to obtain
the location of the device as both a location value and reference. In order to contact
the LIS the ESRP-registrar SHOULD determine the LIS address using the mechanism described
in <xref target="I-D.thomson-geopriv-res-gw-lis-discovery"/>. The ESRP-registrar MAY use other methods
for LIS determination where available.</t>
<t>If the REGISTER message contains a location URI then the ESRP-registrar MUST
dereference it so that it has a location available to route the impending emergency call.
The ESRP-registrar MAY validate the LIS address in the location URI with that of the LIS
serving the network from which the REGISTER message originated. LIS determination MAY be performed
using the methods described in <xref target="I-D.thomson-geopriv-res-gw-lis-discovery"/>.</t>
<t>The REGISTER message contains location information by value. Any actions performed by
the ESRP-registrar to valid this information are specific to the jurisdiction in which the ESRP
operates and are out of the scope of this document.</t>
</list>
</t>
<t>Where location conveyance is used confidentiality protection SHOULD be provided using
Transport Layer Security (TLS).</t>
<t><xref target="reg-flow"/> show the registration message exchange graphically.</t>
<t>
<figure anchor="reg-flow" title="Registration message flow">
<artwork><![CDATA[
+--------+ +-----+ +------+ +------+
| Device | | LIS | | LoST | | ESRP |
+--------+ +-----+ +------+ +------+
| | | |
+<----LIS Discovery---->+ | |
| | | |
+----locationRequest--->+ | |
| | | |
+<---locationResponse---| | |
| | | |
+------------------findService------------->+ |
| | | |
+<--------------findServiceResponse---------+ |
| | | |
+------------------------REGISTER------------------------>+
| | | |
| +<------locationRequest-----------+
| | | |
| +-------locationResponse--------->+
| | | |
+<-------------------------200 OK ------------------------+
| | | |
]]>
</artwork>
</figure>
</t>
<t>
<figure anchor="reg-msg" title="Sample REGISTER message">
<artwork><![CDATA[
REGISTER sip:sos.example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bKnashds7
Max-Forwards: 70
From: anon <sip:anon@sos.example.com>;tag=7F94778B653B
To: anon <sip:anon@sos.example.com>
Call-ID: 16CB75F21C70
CSeq: 1 REGISTER
Geolocation: <https://lis.access.example.com:9192/suXweu838737d72>
;inserted-by="anon@192.0.2.2"
;routing-allowed=yes
Geolocation: <cid:target123@192.0.2.2>
;inserted-by="anon@192.0.2.2"
;routing-allowed=no
Require: gruu, geolocation
Supported: outbound, gruu
Contact: <sip:anon@192.0.2.2;transport=tcp>
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
]]>
</artwork>
</figure>
</t>
<t>Since the emergency client does not have a nominal domain, it MUST register in the same
domain as the ESRP. This is illustrated in the example REGISTER message show in <xref
target="reg-msg"/>. </t>
</section>
<section title="Emergency Client Call Intitiation">
<t> Immediately subsequent to the registration a SIP INVITE request is sent to the ESRP in the
following form: <list style="numbers">
<t>The Request URI MUST be the service URN <xref target="RFC5031"/> in the "sos" tree. </t>
<t>The To header MUST be a service URN in the "sos" tree. </t>
<t>The From header MUST be present and MUST be the public GRUU returned from the
registration with the ESRP-registrar.</t>
<t>A Route header MUST be present with an ESRP URI, obtained from LoST.</t>
<t>A Contact header MUST be present and contain the public GRUU <xref
target="I-D.ietf-sip-gruu"/>, and be valid for several minutes following the
termination of the call, provided that the UAC remains registered with the same
registrar, to permit an immediate call-back to the specific device which placed the
emergency call. </t>
<t>A SDP offer MUST be included in the INVITE. If voice is supported the offer MUST
include the G.711 codec, see Section 14 of <xref target="I-D.ietf-ecrit-phonebcp"/>. </t>
<t> SIP Caller Preferences <xref target="RFC3841"/> SHOULD be used to signal how the PSAP
should handle the call. For example, a language preference expressed in an
Accept-Language header may be used as a hint to cause the PSAP to route the call to a
call taker who speaks the requested language. SIP Caller Preferences may also be used to
indicate a need to invoke a relay service for communication with people with
disabilities in the call. </t>
</list>
</t>
</section>
<section title="Call Termination Control">
<t> The description in <xref target="I-D.rosen-ecrit-premature-disconnect-rqmts"/> is relevant
for this document. </t>
</section>
<section title="SIP Feature Restrictions">
<t> The functionality defined in Section 9.3 in <xref target="I-D.ietf-ecrit-phonebcp"/>
regarding disabling of certain features is relevant for this document and an emergency
client MUST NOT implement the the features listed in ED-70, and ED-71. </t>
</section>
<section title="Testing">
<t> The description in Section 15 of <xref target="I-D.ietf-ecrit-phonebcp"/> regarding
emergency call testing is used by this specification. Since this specification mandates a
registration with the ESRP-registrar a similar tagging URI to that described in <xref
target="I-D.patel-ecrit-sos-parameter"/> is used to indicate a test registration.</t>
<t>Test registrations SHALL be of short durations, but MUST be long enough to allow completion of a "test call"
as described in <xref target="I-D.ietf-ecrit-phonebcp"/>.
</t>
<section title="Test Registration">
<t>When the emergency client sends a REGISTER request for emergency test registration, the
"sos.test" URI parameter MUST be appended to the URI in the Contact header. This indicates
to the ESRP-registrar that the request is for emergency test registration.
</t>
<t>
<figure anchor="test-reg" title="Test REGISTER Message Fragment">
<artwork><![CDATA[
...
Contact: <sip:anon@192.0.2.2;transport=tcp;sos.test>
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF>"
Content-Type: multipart/mixed; boundary=boundary1
Content-Length: ...
]]>
</artwork>
</figure>
</t>
<t>
Only one Contact header field SHOULD be included in
the emergency REGISTER test request. If more than one Contact header is included then the presence of the "sos.test"
URI in any of the Contact fields SHALL result in the ESRP-registrar treating the registration as a test registration.
</t>
</section>
<section title="Format">
<t>The following syntax specification uses the augmented Backus-Naur
Form (BNF) as described in <xref target="RFC5234"/>.
</t>
<t> The "sos.test" URI parameter is a "uri-parameter", as defined by <xref target="RFC3261"/>.
</t>
<t>uri-parameter =/ sos-param-test</t>
<t>sos-param-test = "sos.test"</t>
</section>
</section>
<section title="PSAP Callback">
<t>PSAP callback occurs as described in <xref target="I-D.schulzrinne-ecrit-psap-callback"
/>.</t>
</section>
<section anchor="security-considerations" title="Security Considerations">
<t>TBD</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This specification defines one new SIP URI parameter, as per the registry created by <xref target="RFC3969"/>.</t>
<t>Parameter Name: sos.test</t>
<t>Predefined Values: none</t>
<t>Reference: [RFCXXXX]</t>
<t>[NOTE TO IANA: Please replace XXXX with the RFC number of this specification.] </t>
</section>
<section title="Acknowledgements">
<t>Thanks to Elaine Quah for being a sounding board. </t>
</section>
</middle>
<back>
<references title="Normative References"> &RFC2119; &RFC5222; &RFC3261;
&I-D.ietf-ecrit-phonebcp; &I-D.ietf-sip-gruu; &I-D.ietf-sip-outbound;
&I-D.ietf-sipcore-location-conveyance; &I-D.thomson-geopriv-res-gw-lis-discovery;
&I-D.ietf-geopriv-held-identity-extensions; &I-D.schulzrinne-ecrit-psap-callback;
&RFC3841; &RFC5031; &RFC5234; &RFC3969;</references>
<references title="Informative References"> &I-D.ietf-ecrit-framework;
&I-D.patel-ecrit-sos-parameter; &I-D.ietf-ecrit-lost-servicelistboundary;
&I-D.rosen-ecrit-premature-disconnect-rqmts; </references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:54:14 |