<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type=<?xml version="1.0" encoding="US-ASCII"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="no"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="no" ?>
<?rfc subcompact="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC6643 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6643.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC5031 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5031.xml">
<!ENTITY RFC4412 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4412.xml">
<!ENTITY RFC7090 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7090.xml">
<!ENTITY RFC7135 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7135.xml">
<!ENTITY RFC6881 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6881.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY I-D.ietf-stir-rph-emergency-services SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-stir-rph-emergency-services.xml">]>
<rfc category="std" docName="draft-rosen-stir-emergency-calls-00" ipr="trust200902">
  <front>
    <title>Non-Interactive Emergency Calls</title>
    <author initials="B." surname="Rosen" fullname="Brian Rosen">
       <address>
        <postal>
          <street>470 Conrad Dr</street>
          <city>Mars</city>
          <region> PA </region>
          <code>16046 </code>
          <country>US </country>
        </postal>
        <phone> </phone>
        <email>br@brianrosen.net
        </email>
      </address>
    </author>
    <date year="2020"/>
    <area>ART</area>
    <workgroup>stir</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
<t>
Emergency calls from citizens to authorities, and call back of such emergency calls by authorities to citizens need assurances that headers intended to get appropriate priority from the networks they traverse, and in some cases, appropriate routing.  Protection of the SIP Resource Priority Header and the SIP Priority header is needed for such calls.  This document describes the environment for placing emergency calls and call backs which motivate the need and use of the mechanisms described in other documents  </t>
    </abstract>
  </front>

  <middle>
    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="introduction" title="Introduction">

		<t><xref target="RFC6643"/> describes how devices use the Internet to place
   emergency calls and how Public Safety Answering Points (PSAPs) handle Internet
   emergency calls.  In traditional telephone networks, emergency calls are not afforded any priority in the network.  Emergency calls are marked with a Service URN, <xref target="RFC5031"/>. </t>
<t>Sometimes, the emergency services need to call the person that placed an emergency call after the original emergency call was terminated.  This is a case of "call-back".  <xref target="RFC7090"/> discusses using SIP Priority to mark a call as a call back.  The Resource Priority Header, <xref target="RFC4412"/> defines a way to request the network afford priority in resources: The 'Priority'
   header field describes the importance that the SIP request should
   have for the receiving human or its agent.  For example, that header
   may be factored into decisions about call routing to mobile devices
   and assistants and about call acceptance when the call destination is
   busy.  The 'Priority' header field does not affect the usage of PSTN
   gateway or proxy resources, for example.  In addition, any User Agent
   Client (UAC) can assert any 'Priority' value, and usage of 'Resource-
   Priority' header field values is subject to authorization.
</t>
<t>This document describes the environment for placing emergency calls on the Internet, which has different capabilities than the PSTN, as well as call backs across the Internet and describes the requirements for protecting them with the "stir" mechanism.</t>

    </section>
    
    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section anchor="terminology" title="Terminology">

      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
      NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
      "MAY", and "OPTIONAL" in this document are to be interpreted as
      described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
      appear in all capitals, as shown here.</t>
     <t>SIP is the Session Initiation Protocol <xref target="RFC3261"/></t>
     <t>PSAP is a Public Safety Answering Point, the call center for emergency calls.</t>


     
	  
    </section>


    <!-- ////////////////////////////////////////////////////////////////////////////////// -->


    <section anchor="call" title="Emergency Calls">

 <t>SIP signaling for emergency calls is defined in <xref target="RFC6881"/>.  An emergency call is marked with a Service URN <xref target="RFC5031"/> in the Request-URI field.  RFC6881 does not have any recommendations for the Resource Priority Header.  Emergency calls will make use of the stir mechanism to assure the PSAP that the calling party identifier is accurate.  There are numerous cases of what is called "swatting" where an emergency call with a spoofed identity is placed and the caller fraudulently reports serious criminal activity at some address, prompting the authorities to respond with significant force (SWAT team).  By validating the identity, authorities hope swatting will become much less possible.  </t>

<t>It is desirable in some networks to be able to provide some priority in the call handling network for emergency calls, even though the PSTN does not do that.  <xref target="RFC7135"/> defines the "esnet" namespace, and 4 priority levels "for local
   emergency session establishment to a public safety answering point
   (PSAP), between PSAPs, and between a PSAP and first responders and
   their organizations. ".  There is presently no recommendation for what priority level to assign to emergency calls.  There are other documents <xref target="i3"/> that describe how to use the esnet values within an Emergency Services IP Network, which is distinct from the originating service provider networks, over which emergency calls may be placed.</t>
<t>This document recommends that emergency calls from outside an Emergency Services IP Network be assigned esnet.0.  This document makes no recommendations on what originating service provider networks actually provide for resource priority other than to note the obvious: emergency calls should receive some priority for resources.</t>
<t>Whatever the network does with the RPH value, it is desirable to protect it from manipulation and <xref target="I-D.ietf-stir-rph-emergency-services"/> provides the mechanism to accomplish that.</t>
    </section>

    <section anchor="callback" title="Emergency Call-backs">
 <t>After an emergency call is placed, it is sometimes necessary for the PSAP, or a responder, to call the caller back.  This call is placed by the authorities back to the original caller.  <xref target="RFC7090"/> describes the use of the SIP Priority header field, with the value "psap-callback" to mark such calls and describes how called networks may use that marking.  RFC7090 does not describe any priority, and does not mention use of the Resource Priority header field.  There is no protection against misuse of the SIP Priority field, and because, as RFC7090 illustrates, it may affect routing, it is very desirable to protect it from modification.</t>
<t>This document recommends that emergency calls-backs from authorities outside an ESInet contain a Resource Priority header field and be assigned esnet.0.  This document makes no recommendations on what service provider networks actually provide for resource priority other than to note the obvious: emergency calls-backs should receive some priority for resources.</t>
<t>Many countries are starting to adopt the emergency calling paradigms promulgated by the IETF.  For example, in North America, the <xref target="i3"/> standard defines IP based emergency calling networks, drawing from IETF work.  In those systems, a PKI is being created, with a trusted root, the "PSAP Credentialing Agency" (PCA).  The PCA provides a root of trust that could be used to sign call-backs protecting the SIP Priority and Resource Priority header fields. </t>
</section>
    <section title="IANA Considerations">
 <t>There are no actions requested of IANA in this document</t>
</section> 

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->

    <section title="Security Considerations">
 <t>TBD</t>
   </section>

    <section title="Acknowledgments">
 <t>TBD</t>
   </section>

    <!-- ////////////////////////////////////////////////////////////////////////////////// -->
  </middle>

  <!-- ////////////////////////////////////////////////////////////////////////////////// -->

  <back>
    <references title="Normative References">

  &RFC8174;
 
       </references>

    <references title="Informative References">
    <reference anchor="i3" target="https://www.nena.org/resource/resmgr/standards/NENA-STA-010.2_i3_Architectu.pdf">
        <front>
          <title>Detailed Functional and Interface Standards for the NENA i3 Solution</title>
<author>
            <organization>NENA</organization>
          </author>

          <date month="September" year="2016"/>
        </front>
        <format type="PDF"/>
      </reference> 
   &RFC5031;&RFC4412;&RFC6643;&RFC7090;&RFC7135;&RFC6881;&RFC2119;&RFC3261;&I-D.ietf-stir-rph-emergency-services; </references>
  </back>
</rfc>

