[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 draft-holmberg-ecrit-emergency-callback-id

ECRIT Working Group                                          C. Holmberg
Internet-Draft                                                  Ericsson
Intended status: Standards Track                        October 24, 2011
Expires: April 26, 2012


  Session Initiation Protocol (SIP) emergency call back identification
              draft-holmberg-emergency-callback-id-00.txt

Abstract

   This specification define a new type of Globally Routable User Agent
   URI (GRUU) [RFC5627], called emergency GRUU (eGRUU).  When a User
   Agent (UA) provides makes an emergency call, it can provide the eGRUU
   to a PSAP, which can then use it to make a PSAP callback call.  The
   specification also defines a new URI parameter, "psapcb", which can
   be used to indicate that a URI can be used for PSAP callback calls.
   A registrar will provide the URI parameter as part of the generated
   eGRUU value.  Later, when a PSAP makes a PSAP callback call the URI,
   including the "psapcb" URI parameter, can be used by SIP entities to
   identity callback calls.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on April 26, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents



Holmberg                 Expires April 26, 2012                 [Page 1]


Internet-Draft               Emergency GRUU                 October 2011


   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Applicability and Limitation . . . . . . . . . . . . . . . . .  3
   4.  Overview of operation  . . . . . . . . . . . . . . . . . . . .  4
   5.  RFC 5627 Support . . . . . . . . . . . . . . . . . . . . . . .  4
   6.  User Agent Behavior  . . . . . . . . . . . . . . . . . . . . .  5
     6.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  5
     6.2.  Generating a REGISTER Request  . . . . . . . . . . . . . .  5
     6.3.  Learning eGRUUs from REGISTER Responses  . . . . . . . . .  6
     6.4.  Constructing a Self-Made eGRUU . . . . . . . . . . . . . .  6
     6.5.  Using One's Own eGRUU  . . . . . . . . . . . . . . . . . .  6
       6.5.1.  Considerations for Multiple AORs . . . . . . . . . . .  7
     6.6.  Dereferencing an eGRUU . . . . . . . . . . . . . . . . . .  7
     6.7.  Rendering eGRUUs on a User Interface . . . . . . . . . . .  7
   7.  Registrar Behavior . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  General  . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.2.  Processing a REGISTER Request  . . . . . . . . . . . . . .  8
     7.3.  Generating a REGISTER Response . . . . . . . . . . . . . .  8
     7.4.  Timing Out a Registration  . . . . . . . . . . . . . . . .  8
     7.5.  Creation of an eGRUU . . . . . . . . . . . . . . . . . . .  9
     7.6.  Registration Event Support . . . . . . . . . . . . . . . .  9
     7.7.  PSAP callback call . . . . . . . . . . . . . . . . . . . .  9
   8.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  ABNF . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
   10. Message Flow Examples  . . . . . . . . . . . . . . . . . . . . 10
     10.1. Example  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   12. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
     12.1. General  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     12.2. Header Field Parameter . . . . . . . . . . . . . . . . . . 10
     12.3. URI Parameter  . . . . . . . . . . . . . . . . . . . . . . 10
     12.4. SIP option-tag . . . . . . . . . . . . . . . . . . . . . . 11
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 12
     15.2. Informational References . . . . . . . . . . . . . . . . . 12
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12



Holmberg                 Expires April 26, 2012                 [Page 2]


Internet-Draft               Emergency GRUU                 October 2011


1.  Introduction

   EDITOR'S NOTE: We can probably add text from an existing draft here,
   once we decide how to move forward documentation wise.

   This specification define a new type of Globally Routable User Agent
   URI (GRUU) [RFC5627], called emergency GRUU (eGRUU).  When a User
   Agent (UA) provides makes an emergnecy call, it can provide the eGRUU
   to a PSAP, which can then use it to make a PSAP callback call.  The
   specification also defines a new URI parameter, "psapcb", which can
   be used to indicate that a URI can be used for PSAP callback calls.
   A registrar will provide the URI parameter as part of the generated
   eGRUU value.  Later, when a PSAP makes a PSAP callback call the URI,
   including the "psapcb" URI parameter, can be used by SIP entities to
   identity callback calls.


2.  Terminology

   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 [RFC2119].

   The terms defined in RFC 5627 apply, with the following additional
   terms defined in this specification:

   Public Safety Answering Point (PSAP): A call center responsible for
   answering calls to an emergency telephone number (referred to as
   emergency call), and dispatching them to the appropriate emergency
   services (e.g. police, firefighting or ambulance).

   PSAP callback: A call made back from a PSAP to a user who previously
   made an emergency call, in case the emergency call dropped, or the
   PSAP needs additional information associated with the emergency call.


3.  Applicability and Limitation

   If a PSAP callback call comes from a Public Switched Telephony
   Network (PSTN), or from another interworking network, the UAC
   representing the PSAP will normally be located in a network
   interworking gateway controller, such as a in a Media Gateway
   Controller (MGC).  The interworking gateway will normally not have
   knowledge of the eGRUU, neither will it be able to determine that the
   call is a PSAP callback call.






Holmberg                 Expires April 26, 2012                 [Page 3]


Internet-Draft               Emergency GRUU                 October 2011


4.  Overview of operation

   The procedures defined in section 3 of RFC 5627 apply also to an
   eGRUU, with the following limitations:

   - An eGRUU MUST be constructed following the same principles and
   rules that apply for constructing a public GRUU.

   OPEN ISSUE: It still needs to be decided whether an eGRUU should be
   constructed as a public GRUU, or whether a temporary GRUU is more
   appropriate.

   - A UA MUST obtain an eGRUU either as part of a REGISTER transaction,
   or via some locally specified administrative mechanism.  A UA MUST
   NOT construct an eGRUU locally.

   - A UA that wants to obtain an eGRUU via its REGISTER request MUST,
   in addition to providingan instance ID in the "+sip.instance" Contact
   header field parameter of the request, also include an "egruu"
   option-tag in the Supported header field.

   NOTE: The "egruu" option-tag will only request for an eGRUU.  If a UA
   also wants to obtain a gruu type defined in RFC 5627, it needs to
   include an "gruu" option-tag in addition to the "egruu" option-tag.

   - A UA, when not acting a PSAP, MUST NOT use an eGRUU in any other
   requests than in an initial INVITE requests for a call that the UA
   determines to be an emergency call.

   - A UA, when acting a PSAP, MUST NOT use an eGRUU in any other
   requests than in an initial INVITE requests for a PSAP callback call.

   - A UA MUST NOT use the "psapcb" URI parameter in any other requests
   than in an initial INVITE requests for a call that the UA determines
   to be an emergency call.

   - Unless a UA is acting as a PSAP, initiating a PSAP callback call,
   it MUST NOT dereference an eGRUU.


5.  RFC 5627 Support

   An entity that requests, or generates, an eGRUU MUST support the
   procedures defined in RFC 5627.  However, the "egruu" option-tag only
   requests an eGRUU.  If a UA, in addtion to the eGRUU, also wants to
   request a gruu type defined in 5627, it also needs to use the "gruu"
   option-tag, as defined in RFC 5627.




Holmberg                 Expires April 26, 2012                 [Page 4]


Internet-Draft               Emergency GRUU                 October 2011


   The UA, registrar and proxy procedures in this specification are
   based on the procedures defined in sections 4, 5 and 6 of RFC 5627,
   with the deviations explicitly described.


6.  User Agent Behavior

6.1.  General

   This section defines the normative behavior for user agents.

6.2.  Generating a REGISTER Request

   The general procedures, not associated with a specific type of GRUU,
   in section 4.1 of RFC 5627 also apply to an eGRUU.

   When a UA compliant to this specification generates a REGISTER
   request (initial or refresh), it MUST include an "egruu" option-tag
   in the Supported header field in the request.  This informs the
   registrar for the domain that the UA supports the eGRUU mechanism.

   A UA MUST NOT insert an "emg-gruu" header field in the Contact header
   field of a REGISTER request.

   If the Call-ID changes in a register refresh, the server will
   invalidate all eGRUUs associated with that UA instance; the only
   valid one will be the new one returned in that REGISTER response.
   When the mechanism defined in RFC 5626 [RFC5626] is used, this rule
   applies to the reg-ids: If the Call-ID changes for the registration
   refresh for a particular reg-id, the server will invalidate all
   eGRUUs associated with that UA instance as a whole.  Consequently, if
   a UA wishes its previously obtained eGRUUs to remain valid, it MUST
   utilize the same Call-ID in REGISTER refreshes.

   A UA SHOULD NOT request a new eGRUU during the lifetime of a
   registration, as the eGRUU might be used by an PSAP making a PSAP
   callback call using the previous eGRUU value.  However, it MAY change
   the Call-ID in a refresh if invalidation is the desired objective.

   If a UA wishes to guarantee that the REGISTER request is not
   processed unless the domain supports and uses this extension, it MAY
   include a Require header field in the request with a value that
   contains the "egruu" option-tag.  This is in addition to the presence
   of the Supported header field, also containing the "egruu" option-
   tag.  The use of the Proxy-Require header field is not necessary and
   is NOT RECOMMENDED.





Holmberg                 Expires April 26, 2012                 [Page 5]


Internet-Draft               Emergency GRUU                 October 2011


6.3.  Learning eGRUUs from REGISTER Responses

   The general procedures, not associated with a specific type of GRUU,
   in section 4.2 of RFC 5627 also apply to an eGRUU.

   If the REGISTER response is a 2xx, each Contact header field that
   contains the "+sip.instance" Contact header field parameter can also
   contain an "emg-gruu" Contact header field parameter.  This header
   field parameter conveys the eGRUU for the UA instance.  The eGRUU
   will be valid for the duration of the registration (that is, through
   refreshes).  The UA can receive a new eGRUU in each successful
   REGISTER response.  If a UA changed its Call-ID in this REGISTER
   request, or did not include an "egruu" option-tag in the Supported
   header field, compared to a previous REGISTER request for the same
   contact or reg-id, the UA MUST discard all eGRUUs learned through
   prior REGISTER responses.  A UA MAY retain zero, one, some, or all of
   the eGRUUs that it is provided during the time over which at least
   one contact or reg-id remains continuously registered.  If a UA
   stores any eGRUUs for use during its registration, it needs to be
   certain that the registration does not accidentally lapse due to
   clock skew between the UA and registrar.  Consequently, the UA MUST
   refresh its registration such that the REGISTER refresh transaction
   will either complete or timeout prior to the expiration of the
   registration.  For default transaction timers, this would be at least
   32 seconds prior to expiration, assuming the registration expiration
   is larger than 64 seconds.  If the registration expiration is less
   than 64 seconds, the UA SHOULD refresh its registration halfway prior
   to expiration.

   Note that, when the mechanism defined in RFC 5626 is in use, and the
   UA is utilizing multiple flows for purposes of redundancy, the eGRUUs
   remain valid as long as at least one flow is registered.  Thus, even
   if the registration of one flow expires, the eGRUUs learned
   previously remain valid.

   The mechanism defined in RFC 3680 [RFC3680] and RFC 5628 [RFC5628]can
   not be used for eGRUUs, as RFC 5628 does not define a mechanism for
   conveying eGRUU information.

6.4.  Constructing a Self-Made eGRUU

   A UA MUST NOT construct a self-made eGRUU.

6.5.  Using One's Own eGRUU

   The procedures defined in section 4.4 of RFC 5627 apply also to an
   eGRUU, with the limitations defined in this section.




Holmberg                 Expires April 26, 2012                 [Page 6]


Internet-Draft               Emergency GRUU                 October 2011


   When a UAC sends an initial SIP INVITE request [RFC3261] for an
   emergency call, it MUST insert the eGRUU in the Contact header field
   of the request.  The UAC MUST use the same eGRUU value that it has
   obtained for the registration associated with the emergency call.

   OPEN ISSUE: It still needs to be decided whether a UA can use the
   "psapcb" parameter if it does not support, or is able to retrieve,
   eGRUU.

   A UA MUST NOT insert an eGRUU in the Contact header field of a SIP
   response, or in any other SIP request than an initial INVITE request
   for calls that it determines as emergency calls.

   NOTE: There might be cases where the UAC does not know that the call
   it is establishing is an emergency call, and will therefor not
   include an eGRUU in the initial SIP INVITE request for the call.  In
   some networks suchs calls will be determined as an emergency call by
   the network.

6.5.1.  Considerations for Multiple AORs

   The procedures in section 4.4.1 of RFC 5627 also apply to an eGRUU.

6.6.  Dereferencing an eGRUU

   The procedures in section 4.5 of RFC 5627 also apply to an eGRUU.

   When a UA, representing a PSAP, sends an initial SIP INVITE request
   for an PSAP callback call, it MUST insert the eGRUU that it received
   in the associated emergency call in the Request-URI [RFC3261] of the
   request.

   NOTE: If the Contact header field of an initial SIP INVITE request
   for an emergency call did not contain a "psabcb" parameter, a UA,
   representing a PSAP, can insert the "psapcb" parameter in the
   Request-URI of the initial SIP INVITE request for an PSAP callback
   call.

   If a UA does not represent a PSAP, making a PSAP callback call, it
   MUST NOT insert an eGRUU and a "psapcb" parameter in the Request-URI
   of the intial SIP INVITE request for the call.

6.7.  Rendering eGRUUs on a User Interface

   An eGRUU MUST NOT be rendered to a user.  The reasons is to prevent a
   user from e.g. using the eGRUU for non-emergency calls.





Holmberg                 Expires April 26, 2012                 [Page 7]


Internet-Draft               Emergency GRUU                 October 2011


7.  Registrar Behavior

7.1.  General

   This section defines the normative behavior for registrars.

7.2.  Processing a REGISTER Request

   A REGISTER request might contain a Require header field with an
   "egruu" option-tag; this indicates that the registrar has to
   understand the eGRUU extension in order to process the request.  It
   does not require the registrar to create an eGRUU, however.

   Next, the registrar MUST check the Contact header fields, and compare
   the contact URIs with the AOR, as defined in section 5.1 of RFC 5627.

   Next, the registrar MUST create a new eGRUU for the AOR and instance,
   according to the procedures in section 7.5 of this specification.

   If the contact contained a "emg-gruu" Contact header field parameter,
   the header field parameter MUST be ignored by the registrar.  A UA
   cannot suggest or otherwise provide an eGRUU to the registrar.

7.3.  Generating a REGISTER Response

   When generating the 200 (OK) response to the REGISTER request, the
   procedures of step 8 of Section 10.3 of RFC 3261 are followed.
   Furthermore, the registrar includes the instance ID in the Contact
   header field, as defined in section 5.2 of RFC 5627.

   If the REGISTER request contained a Supported header field that with
   an "egruu" option-tag, and the registrar has an eGRUU assigned to the
   instance ID and AOR, the registrar MUST add an "emg-gruu" Contact
   header field parameter to that Contact header field.  The value of
   the "emg-gruu" header field parameter MUST contain and MUST contain
   the most recently created eGRUU for that AOR and instance ID.

   The registrar MUST NOT include an "egruu" option-tag in the Require
   or Supported header field of the response.

7.4.  Timing Out a Registration

   The procedures in section 5.3 of RFC 5627 that apply to public gruus
   also apply to an eGRUU.







Holmberg                 Expires April 26, 2012                 [Page 8]


Internet-Draft               Emergency GRUU                 October 2011


7.5.  Creation of an eGRUU

   The procedures in section 5.4 of RFC 5627 that apply to public gruus
   also apply to an eGRUU, with the following addition:

   The eGRUU value MUST contain a SIP-URI [RFC3261], which includes a
   "psapcb" SIP-URI parameter.

7.6.  Registration Event Support

   The procedures defined in section 5.5 of RFC 5627 also apply to an
   eGRUU.

7.7.  PSAP callback call

   When a registrar receives an initial SIP INVITE request for a call,
   and the Request-URI of the request contains an eGRUU (including a
   "psapcb" parameter) that the registrar has previously assigned to the
   called user, the registrar can decide that the call is a PSAP
   callback call.

   NOTE: A registrar might give special treatment to a call identified
   as a PSAP callback call.  Such treatment is outside the scope of this
   specification.


8.  Proxy Behavior

   The procedures defined in section 6 of RFC 5627 also apply to an
   eGRUU.


9.  Grammar

9.1.  ABNF

   This specification defines a new Contact header field parameter,
   "emg-gruu", by extending the grammar for "contact-params" as defined
   in RFC 3261.  It also defines a new URI parameter, "psapcb", by
   extending the grammar for "uri-parameter" as defined in RFC 3261.
   The ABNF [RFC5234] is as follows:

   contact-params =/ emg-gruu

   emg-gruu = "emg-gruu" EQUAL quoted-string

   uri-parameter =/ psap-callback-parameter




Holmberg                 Expires April 26, 2012                 [Page 9]


Internet-Draft               Emergency GRUU                 October 2011


   psap-callback-parameter = "psapcb"


10.  Message Flow Examples

10.1.  Example

   TBD

    Add example flow

                        Figure 1: Example call flow


11.  Security Considerations

   The security considerations defined in RFC 5627 also apply to eGRUUs.


12.  IANA Considerations

12.1.  General

   This specification defines a new Contact header field parameter, a
   new and URI parameter, and a new SIP option-tag.

12.2.  Header Field Parameter

   This specification defines a new header field parameter, as per the
   registry created by RFC 3968 [RFC3968].  The required information is
   as follows:


           Header field in which the parameter can appear:  Contact
       Name of the Parameter:  emg-gruu
       Predefined Values:  none
       RFC Reference:  RFC XXXX [[NOTE TO IANA: Please replace
           XXXX with the RFC number of this specification]]

12.3.  URI Parameter

   This specification defines a new SIP URI parameter, as per the
   registry created by RFC 3968 [RFC3968].  The required information is
   as follows:


           Name of the Parameter:  psapcb
           Predefined Values:  none



Holmberg                 Expires April 26, 2012                [Page 10]


Internet-Draft               Emergency GRUU                 October 2011


           RFC Reference:  RFC XXXX [[NOTE TO IANA: Please replace
           XXXX with the RFC number of this specification]]

12.4.  SIP option-tag

   This specification registers a new SIP option tag, as per the
   guidelines in Section 27.1 of RFC 3261 [RFC3261].  The required
   information is as follows:


           Name:  egruu

       Description:  This option-tag is used to identify the
             emergency Globally Routable User Agent URI (eGRUU)
             extension. When used in a Supported header, it
             indicates that a User Agent understands the
             extension.  When used in a Require header field
             of a REGISTER request, it indicates that the
             registrar is not expected to process the
             registration unless it supports the eGRUU
             extension.


13.  Acknowledgements

   The original idea of using a token based mechanism to associate PSAP
   callback calls with emergency calls was presented by Cullen Jennings.

   Thanks to Fredrik Lindholm, Jan Holm and Ivo Sedlacek for their
   comments and feedbacks on the initial draft.

   Thanks to everyone who took part, and provided input and feedback, in
   the discussions at the IETF#81 meeting.


14.  Change Log

   [RFC EDITOR NOTE: Please remove this section when publishing]

   Changes from draft-holmberg-ecrit-callback-00
   o  Draft file name changed to draft-holmberg-ecrit-egruu
   o  New type of GRUU, instead of a feature tag, is used as callback
      identifier


15.  References





Holmberg                 Expires April 26, 2012                [Page 11]


Internet-Draft               Emergency GRUU                 October 2011


15.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3968]  Camarillo, G., "The Internet Assigned Number Authority
              (IANA) Header Field Parameter Registry for the Session
              Initiation Protocol (SIP)", BCP 98, RFC 3968,
              December 2004.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5627]  Rosenberg, J., "Obtaining and Using Globally Routable User
              Agent URIs (GRUUs) in the Session Initiation Protocol
              (SIP)", RFC 5627, October 2009.

15.2.  Informational References

   [RFC3680]  Rosenberg, J., "A Session Initiation Protocol (SIP) Event
              Package for Registrations", RFC 3680, March 2004.

   [RFC5626]  Jennings, C., Mahy, R., and F. Audet, "Managing Client-
              Initiated Connections in the Session Initiation Protocol
              (SIP)", RFC 5626, October 2009.

   [RFC5628]  Kyzivat, P., "Registration Event Package Extension for
              Session Initiation Protocol (SIP) Globally Routable User
              Agent URIs (GRUUs)", RFC 5628, October 2009.


Author's Address

   Christer Holmberg
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   Email: christer.holmberg@ericsson.com






Holmberg                 Expires April 26, 2012                [Page 12]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/