One document matched: draft-patel-ecrit-sos-parameter-00.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-00.txt"
     ipr="full3978">
  <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="September" year="2008" />

    <area>RAI</area>

    <workgroup>ECRIT Working Group</workgroup>

    <keyword>Emergency</keyword>

    <keyword>Session Initiation Protocol</keyword>

    <abstract>
      <t>This memo describes requirements and protocol conventions for a new
      SIP (Session Initiation Protocol) URI parameter intended for marking SIP
      requests and responses related to emergency services. This proposal
      addresses issues that exist in the current 3rd Generation Partnership
      Project IP Multimedia Subsystem (IMS) Emergency services solution, but
      is not precluded from being used by other SIP-based emergency services
      solutions. It is not intended as a replacement for the service URN.</t>
    </abstract>
  </front>

  <middle>
    <!-- Introduction -->

    <section anchor="sec-intro" title="Introduction">
      <t>This document describes a number of requirements addressing issues
      that exist in the 3GPP IMS emergency services solution, and a proposed
      solution for marking SIP requests related to emergency services.
      SIP-based emergency calls can be distinguished by the presence of the
      Service URN as defined in I-D-ietf-ecrit-phonebcp <xref
      target="I-D.ietf-ecrit-phonebcp" /> and RFC 5031 <xref
      target="RFC5031" />. The emergency services solution in the 3GPP IP
      Multimedia Subsystem (IMS), as described 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 which can be useful in specific scenarios such as roaming. Marking
      of the emergency registration is a requirement described in this
      document that can not be fulfilled by the use of Service URN. A further
      requirement for proposing a new method for marking requests related to
      emergency calls is to identify the call back from a PSAP. Identification
      of the call back can aid in suppressing network-based and UA-based
      services. A further requirement for proposing a new method for marking
      responses is the case where a UE did not recognize the request as an
      emergency service request. Identification of the session as a emergency
      service session can aid in suppressing UA-based services or preventing
      transmission of a BYE request as required in some jurisdictions. The
      requirements for marking emergency call related messages are explored in
      this document and a new URI parameter is proposed to fulfill these
      requirements. </t>
    </section>

    <!-- Conventions -->

    <section anchor="sec-conv" title="Conventions">
      <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-requirements" title="Requirements">
      <section anchor="sec-general" title="General">
        <t>This section defines the requirements for introducing a new URI
        parameter to be used for marking emergency call related SIP
        requests.</t>
      </section>

      <section anchor="sec-requirements-for-indication"
               title="Requirements for additional emergency indication">
        <t>[REQ 1] Indication in REGISTER request:</t>

        <t>3GPP requires that a UE performs emergency registration under
        specific circumstances, such as roaming, as described in 3GPP TS
        23.167 <xref target="3GPP.23.167" />. Marking the REGISTER request to
        indicate an emergency registration is necessary to inform the
        registrar that the contact address and AOR being registered is to be
        used for emergency calls, and roaming and barring restrictions should
        not be applied for the registered AOR. A call back from a PSAP would
        be routed to the registered contact address. Further requirements for
        the emergency registration are specified in 3GPP TS 23.167 <xref
        target="3GPP.23.167" />.</t>

        <t>[REQ 2] Indication of IMS Emergency call origination:</t>

        <t>The Service URN in the Request URI is considered to be the primary
        method for marking the INVITE request for emergency call initiation.
        However, it is considered necessary to add another marking to the
        emergency request, particularly if the Service URN in the Request-URI
        is replaced by a network entity (in the case of 3GPP, such actions are
        performed at the Emergency Call Session Control Function (E-CSCF)).
        This can result in inappropriate handling at SIP entities prior to
        interworking the SIP request to ISUP at a PSTN gateway UA at the edge
        of the SIP network for routing towards the PSAP in the PSTN.</t>

        <t>[REQ 3] Indicating to the UA that an emergency call has been
        initiated:</t>

        <t>In the case that the UA is not emergency aware or no service URN
        for the requested emergency type is known, it will not populate the
        emergency INVITE with the service URN. Upon the network identifying
        the Request URI as an emergency number, the Request URI can be
        replaced with the Service URN. The UA is still unaware that an
        emergency call was initiated. A backwards indication to the UA from
        the network can ensure proper handling of the emergency call at the
        UA, i.e. no services such as call hold are applied to the emergency
        call.</t>

        <t>[REQ 4] Marking the PSAP call back:</t>

        <t>Identifying a call back from a PSAP can allow the network to apply
        special handling of the call back. Network-based services can be
        suppressed and the call can be routed to the contact address from
        which the emergency call was initiated. Additionally, special handling
        of the call back can occur at the UA.</t>

        <t>PhoneBCP <xref target="I-D.ietf-ecrit-phonebcp" />suggests one
        possible method by which a call back can be identified, based upon the
        domain of the PSAP which answers the outgoing emergency call. This is
        possible if the PSAP is located in an IP network and is capable of
        communicating using SIP signaling. However, if the PSAP is located in
        the PSTN, attempting to identify the call back based upon the PSAP
        domain name is not possible.</t>

        
      </section>
    </section>

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

      <section anchor="sec-solution-body" title="Proposed URI parameter">
        <t>A new URI parameter "sos" is defined in this document. The "sos"
        parameter is appended to an AOR consistent with RFC 3261 <xref
        target="RFC3261" />. It is proposed that use of this URI parameter is
        restricted to the Contact header for request and responses 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>

      <section anchor="sec-use-of-sos"
               title="Proposed use of "sos" parameter">
        <section anchor="sec-register" title="REGISTER request">
          <t>It is proposed that when the UA sends a REGISTER request for
          emergency registration, the "sos" URI parameter SHALL be appended to
          the AOR in the Contact header. This serves as an indication to the
          registrar that the request is for emergency registration.</t>

          <t>The "sos" URI parameter SHALL be present in the Contact header in
          the 200 (OK) response sent upon successful registration, thus
          indicating to the UA that this contact address will be included in
          the Contact header of an INVITE for emergency call initiation.</t>
        </section>

        <section anchor="sec-emergency-initiation"
                 title="Requests for emergency call initiation">
          <t>When an emergency aware UA initiates an emergency call, the UA
          SHOULD include the "sos" URI parameter, appended to the contact
          address, in the Contact header in the INVITE request.</t>

          <t>An entity in the network that specifically handles emergency
          calls (in the case of 3GPP this is the E-CSCF), SHOULD append the
          "sos" URI parameter to the contact address in the Contact header in
          the event that the "sos" URI parameter is not present in the Contact
          header.</t>

          <t>This serves as an indication that this is an emergency call even
          in the case when the Service URN is removed by a network entity.</t>
        </section>

        <section anchor="sec-call-back" title="Call back from PSAP">
          <t>The call back from the PSAP SHOULD include the "sos" URI
          parameter in the Contact header of the INVITE request. If the PSAP
          is SIP capable, then the "sos" URI parameter SHOULD be included by
          the PSAP. If the PSAP is located in the PSTN, the PSTN gateway UA at
          the edge of the SIP network SHOULD append the "sos" parameter to the
          contact address in the Contact header of the generated INVITE
          request that is routed back to the emergency caller. This serves as
          an indication to network entities and to the UE to apply special
          call handling such as to suppress services that would normally be
          applied to a terminating call.</t>
        </section>

        <section anchor="sec-responses" title="SIP responses">
          <t>The "sos" URI parameter MAY be included in provisional responses
          and 2xx responses to initial INVITE request for emergency call. This
          can serve as an indication to a UA that is not "emergency aware"
          that an emergency call has been initiated, thus allowing the UA to
          provide special handling of such a call. Suppressing call hold or
          multi-party call initiation during the emergency call to the PSAP
          are examples of special handling. It is RECOMMENDED that in such a
          response, the "sos" URI parameter is included in the Contact header,
          appended to contact address.</t>
        </section>
      </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>The "sos" URI parameter does not appear to raise any particular
      security issue. Misuse of the "sos" URI parameter, by including it in a
      request or response not related to an emergency call SHOULD be monitored
      by a network entity.</t>
    </section>

    <!-- Acknowledgements -->

    <section anchor="sec-acks" title="Acknowledgements">
      <t>The author would like to thank Keith Drage, Milo Orsic, 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
      for the discussions and contributions that lead to this work.</t>
    </section>
  </middle>

  <back>
    <references title="Normative 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"?>

      <!--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>
  </back>
</rfc>