One document matched: draft-patel-ecrit-sos-parameter-03.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- <!DOCTYPE rfc SYSTEM "rfc2629.dtd">-->
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc category="std" docName="draft-patel-ecrit-sos-parameter-03.txt"
     ipr="trust200811">
  <front>
    <title abbrev="SOS URI Parameter for SIP Emergency">SOS Uniform Resource
    Identifier (URI) Parameter for Marking of Session Initiation Protocol
    (SIP) Requests related to Emergency Services</title>

    <author fullname="Milan Patel" initials="M." surname="Patel">
      <organization>Nortel</organization>

      <address>
        <postal>
          <street>Maidenhead Office Park, Westacott Way</street>

          <city> Maidenhead</city>

          <region>Berkshire, UK</region>
        </postal>

        <email>milanpa@nortel.com</email>
      </address>
    </author>

    <date month="January" year="2009" />

    <area>RAI</area>

    <workgroup>ECRIT Working Group</workgroup>

    <keyword>Emergency</keyword>

    <keyword>Session Initiation Protocol</keyword>

    <abstract>
      <t>This document defines a new Session Initiation Protocol (SIP) Uniform
      Resource Identifier (URI) parameter intended for marking SIP
      registration requests related to emergency services. The usage of this
      new URI parameter complements the usage of the Service Uniform Resource
      Name (URN) and is not intended to replace it.</t>
    </abstract>
  </front>

  <middle>
    <!-- Introduction -->

    <section anchor="sec-intro" title="Introduction">
      <t>One way to differentiate a SIP-based emergency call from an ordinary
      call is by the presence of the Service URN as defined in RFC 5031 <xref
      target="RFC5031" /> (and used in the IETF emergency services
      architecture described in PhoneBCP<xref
      target="I-D.ietf-ecrit-phonebcp" />). The 3GPP IP Multimedia Subsystem
      (IMS) emergency services architecture, illustrated in 3GPP TS 23.167
      <xref target="3GPP.23.167" />, specifies that the User Equipment (UE)
      performs emergency registration prior to or during the initiation of an
      emergency call. The circumstances where such an emergency registration
      is required are listed below: <t>- the UE is not registered with its
      home network;</t><t>- is currently registered but roaming (to ensure
      that the emergency call is handled in the visited network, as required
      by some jurisdictions).</t></t>

      <t>Emergency registration is possible only when the UE has sufficient
      credentials to register with its home network and can detect that an
      emergency session is initiated. Unfortunately, marking of the emergency
      registration can not be fulfilled by the use of the Service URN. </t>

      <t>In some countries, it is a regulatory requirement that devices be
      able to place emegency calls in circumstances where other calls may not
      be permitted. When a UE issues an emergency marked REGISTER request it
      informs the registrar that the contact address and the address-of-record
      being registered is to be used for emergency calls, and roaming and
      barring restrictions should not be applied for the registered
      address-of-record. A call back from a PSAP would be routed to the
      registered contact address. </t>

      <t>This document proposes a way to mark a REGISTER message as an
      emergency registration.</t>
    </section>

    <!-- Terminology-->

    <section anchor="sec-conv" 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, RFC 2119 <xref target="RFC2119" /></t>
    </section>

    <!--Requirements-->

    <section anchor="sec-req" title="Requirements">
      <t>Req: It shall be possible to distinguish emergency registration from
      non-emergency registration by providing an appropriate indication in the
      SIP header fields.</t>
    </section>

    <!-- solution-->

    <section anchor="sec-solution" title="The "sos" URI Parameter">
      <t>This section provides an overview of the proposed new URI parameter
      to be used for marking REGISTER requests related to emergency
      services.</t>

      <t>A new URI parameter "sos" is defined in this document. The "sos"
      parameter is appended to a URI consistent with RFC 3261 <xref
      target="RFC3261" />. It is proposed that use of this URI parameter is
      restricted to the Contact header included in the REGISTER request (and
      the 2xx response to the REGISTER request) related to an emergency call
      only. The "sos" URI parameter MUST NOT be considered as a replacement
      for the Service URN for emergency calls originated by a UA.</t>

      <section anchor="sec-register" title="REGISTER Request">
        <t>When the UA sends a REGISTER request for emergency registration,
        the "sos" URI parameter MUST be appended to the URI in the Contact
        header. This serves as an indication to the registrar that the request
        is for emergency registration.</t>

        <t>Example:<t>Contact: "Alice" <sip:alice@example.com;sos>
        ;q=0.7; expires=3600</t></t>

        <t>In the event that more than one Contact header field is included in
        the REGISTER request, only the contact addresses that include the
        "sos" URI parameter shall be considered as emergency registered
        contact addresses. </t>
      </section>

      <section anchor="sec-response" title="2xx Reponse to REGISTER Request">
        <t>The "sos" URI parameter MUST be present in the Contact header in
        the 200 (OK) response sent by the registrar upon successful
        registration. The "sos" URI parameter is appended to the URI included
        in the Contact header, thus indicating to the UA that this contact
        address will be included in the Contact header of an INVITE for
        emergency call intiation.</t>
      </section>
    </section>

    <section anchor="sec-syntax" title="Formal Syntax">
      <t>The following syntax specification uses the augmented Backus-Naur
      Form (BNF) as described in RFC 2234 <xref
      target="RFC2234" /><t>uri-parameter = *(";"value)</t><t>value =
      sos</t></t>
    </section>

    <!-- IANA Considerations -->

    <section anchor="sec:IANA" title="IANA Considerations">
      <t>This specification defines one new SIP URI parameter, as per the
      registry created by RFC 3969 <xref target="RFC3969" /><t>Parameter Name:
      sos</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></t>
    </section>

    <!-- Security Considerations -->

    <section anchor="sec-security" title="Security Considerations">
      <t>As an identifier, the "sos" parameter itself does not raise any
      particular security issues. The semantic described by the "sos"
      parameter are meant to be well-known so privacy considerations do not
      apply to the URN. The main possibility of attack involves use of the
      "sos" parameter to bypass the normal procedures in order to achieve
      fraudulent use of services or to bypass security procedures. The usage
      of this parameter as described in this document is purely for the
      purpose of the REGISTER message and hence in presence of user
      authentication it is ensured that the respective user can be held
      accountable. </t>

      <t>It is RECOMMENDED to log events of misuse of the "sos" URI parameter,
      for example by including it in a request or response not related to an
      emergency calls.</t>
    </section>

    <!-- Acknowledgements -->

    <section anchor="sec-acks" title="Acknowledgements">
      <t>The author would like to thank Keith Drage, Milo Orsic, Deb Barclay,
      John-Luc Bakker, Andrew Allen, Hiroshi Ishikawa, Sean Schneyer, Peter
      Leis, Georg Mayer, Marvin Bienn, Ricky Kaura, Steve Norreys, Laura
      Liess, AC Mahendran, Roozbeh Atarius, Ramachandran Subramanian and
      Sandeep Sharma, Brian Rosen, Hannes Tschofenig, Christer Holmberg and
      Henning Schulzrinne for the discussions and contributions that lead to
      this work.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <!--Key words for use in RFCs to Indicate Requirement Levels-->

      <?rfc include="reference.RFC.2119"?>

      <!--SIP-->

      <?rfc include="reference.RFC.3261"?>

      <!--ABNF-->

      <?rfc include="reference.RFC.2234"?>

      <!--IANA-->

      <?rfc include="reference.RFC.3969"?>
    </references>

    <references title="Informative References">
      <!-- Best Current Practice for Communications Services in support of Emergency Calling-->

      <?rfc include="reference.I-D.ietf-ecrit-phonebcp"?>

      <!-- A Uniform Resource Name (URN) for Emergency and Other Well-Known Services-->

      <?rfc include="reference.RFC.5031"?>

      <!--IP Multimedia Subsystem (IMS) emergency sessions-->

      <?rfc include="reference.3GPP.23.167"?>
    </references>
  </back>
</rfc>