One document matched: draft-patel-ecrit-sos-parameter-09.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-09.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>InterDigital Communications </organization>

      <address>
        <postal>
          <street />

          <city />

          <region />
        </postal>

        <email>Milan.Patel@interdigital.com</email>
      </address>
    </author>

    <date month="July" year="2010" />

    <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 URI parameter
      is extensible to allow future values to be defined if required by other
      use cases that require specific SIP registrations to be distinctly
      identified. 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 beneficial are listed below: <t>- the UE is not registered with its
      home network;</t><t>- the UE 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 cannot 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 emergency calls in circumstances where other calls may not
      be permitted. When a UAC issues an emergency marked REGISTER request it
      indicates to the registrar that roaming and barring restrictions should
      not be applied for the registered address-of-record in order to
      successfully initiate an emergency session. </t>

      <t>Furthermore, distinguishing emergency registration from non-emergency
      registration allows the registrar to ensure that the contact address
      associated with previous registration of the address-of-record included
      in the emergency REGISTER request is not replaced. For incoming calls,
      for example, a PSAP call back to a previously made emergency call,
      addressed to the emergency registered address-of-record can be correctly
      routed to the contact address and UA from which the original emergency
      call was placed. In addition, any network based services or UA endpoint
      based services which may prevent the emergency call or PSAP call back
      from being successful can be disabled if it can be distinguished that
      the registered contact address and address-of-record pertain to
      emergency calls.</t>

      <t>This document concentrates on a use case defined by 3GPP as described
      above. However, the solution proposed does not preclude other systems
      that require emergency registration to occur prior to placing an
      emergency call. </t>

      <t>This document proposes a way to mark a REGISTER request 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", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in RFC 2119 <xref
      target="RFC2119" /></t>
    </section>

    <!--Requirements-->

    <section anchor="sec-req" title="Requirements">
      <t>Req: Where emergency registration is required prior to placing an
      emergency call, it shall be possible to distinguish emergency
      registration from non-emergency registration.</t>
    </section>

    <!-- solution-->

    <section anchor="sec-solution"
             title="The "reg-type" 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 "reg-type" is defined in this document. The
      "reg-type" 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. </t>

      <t>The "reg-type" URI parameter SHALL take a value of "sos" to indicate
      that the REGISTER request pertains to emergency registration. The
      "reg-type" URI parameter with value "sos" MUST NOT be considered as a
      replacement for the Service URN for emergency calls originated by a
      UA.</t>

      <t>Other use cases where specific instances of SIP registration need to
      be identified are also possible. One such case may be by an end-user
      registering their address-of-record with the specific purpose of making
      "test" calls within a network. Such cases not specific to the use case
      identified in this draft for identifying emergency registration are not
      dealt with in this document. However the "reg-type" URI parameter is
      extensible to allow other "reg-type" values to be defined in the
      future.</t>

      <section anchor="sec-register" title="REGISTER Request">
        <t>In networks where the UA sends a REGISTER request for emergency
        registration prior to placing an emergency call, the "reg-type" URI
        parameter with value "sos" 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;reg-type=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
        "reg-type" URI parameter with value "sos" shall be considered as
        emergency registered contact addresses. </t>

        <t>The "reg-type" URI parameter with value "sos" MUST NOT be included
        in non-REGISTER requests, and MUST NOT be included in REGISTER
        requests that do not pertain to emergency calls. </t>
      </section>

      <section anchor="sec-response" title="2xx Response to REGISTER Request">
        <t>If the registrar receives a REGISTER request that includes the
        "reg-type" URI parameter with value "sos" in the Contact header field,
        the registrar MUST include the "reg-type" URI parameter with value
        "sos" in the Contact header field in the 200 (OK) response sent by the
        registrar upon successful registration. The "reg-type" URI parameter
        with value "sos" is appended to the URI included in the Contact
        header.</t>
      </section>

      <section anchor="backwards-compatible"
               title="Backwards compatibility issues">
        <t>The backwards compatibility scenario considered in this document is
        where a legacy registrar does not support the "reg-type" URI parameter
        with value "sos". In this case, if the registrar receives a REGISTER
        request that includes the "reg-type" URI parameter with value "sos" in
        the Contact header field, the registrar proceeds with registration
        procedures and silently ignores the URI-parameter in accordance with
        RFC 3261<xref target="RFC3261" />. This ensures the user is registered
        and thus can successfully initiate an emergency call.</t>

        <t>The drawback of proceeding with registration is if the
        address-of-record is for example barred or has roaming restrictions
        applied, then these restrictions will not be lifted and thus
        registration will be unsuccessful. This can limit the UAC's ability to
        successfully place an emergency call.</t>

        <t>If registration is successful, the 200 (OK) response from a legacy
        registrar includes the "reg-type" URI parameter with value "sos" in
        the Contact header field. Thus the UA is unaware that the registrar
        does not support the “reg-type” URI parameter with value “sos”.
        Providing the registration was successful, the UA’s ability to place
        an emergency call is not compromised. The UA need not know that the
        registrar does not support the URI parameter.</t>

        <t>The consequence of the registrar not supporting the “reg-type” URI
        parameter with value “sos”, in addition to the drawback pertaining to
        restrictions applied to the address-of-record, are as follows:</t>

        <t>- the risk of the registrar overwriting previous registrations of
        the registered address-of-record, and thus disrupting any on-going
        non-emergency sessions associated with the UA, its address-of-record
        and previously registered contact address.</t>

        <t>- incoming calls, such as a PSAP call back (to a previously made
        emergency call) to the registered address-of-record might not be
        routed correctly to the UA that placed the emergency call, due to not
        suppressing any network based services such as call forwarding, or UA
        based services which can divert the call elsewhere, or if the
        address-of-record is associated to more than one contact address.</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 5234 <xref target="RFC5234" />.<t>The
      "reg-type" URI parameter is a "uri-parameter", as defined by RFC
      3261</t><xref target="RFC3261" />.<t>uri-parameter =/
      reg-type-param</t><t>reg-type-param = "reg-type=" ("sos" /
      genvalue)</t><t>genvalue = 1*(alphanum / "-" / "." )</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:
      reg-type</t><t>Predefined Values: sos</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 "reg-type" parameter itself does not raise any
      particular security issues. The semantic described by the "reg-type"
      parameter are meant to be well-known so privacy considerations do not
      apply to the URI parameter. The main possibility of attack involves use
      of the "reg-type" 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 request 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 "reg-type" URI
      parameter with value "sos", for example by including it in a request or
      response not related to an emergency call.</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 led 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.5234"?>

      <!--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>