Internet DRAFT - draft-holmberg-ecrit-emergency-callback-id
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-ecrit-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-emergency-callback-id.
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]
