Session Initiation Protocol (SIP) emergency call back identification

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) , 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.

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

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.

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.

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

This section defines the normative behavior for user agents.

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

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 and RFC 5628 can not be used for eGRUUs, as RFC 5628 does not define a mechanism for conveying eGRUU information.

A UA MUST NOT construct a self-made eGRUU.

The procedures defined in section 4.4 of RFC 5627 apply also to an eGRUU, with the limitations defined in this section. When a UAC sends an initial SIP INVITE request 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.

The procedures in section 4.4.1 of RFC 5627 also apply to 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 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.

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.

This section defines the normative behavior for registrars.

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.

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.

The procedures in section 5.3 of RFC 5627 that apply to public gruus also apply to 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 , which includes a "psapcb" SIP-URI parameter.

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

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.

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

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 is as follows: contact-params =/ emg-gruu emg-gruu = "emg-gruu" EQUAL quoted-string uri-parameter =/ psap-callback-parameter psap-callback-parameter = "psapcb"

TBD

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

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

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

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

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

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.

[RFC EDITOR NOTE: Please remove this section when publishing] Changes from draft-holmberg-ecrit-callback-00 Draft file name changed to draft-holmberg-ecrit-emergency-callback-id. New type of GRUU, instead of a feature tag, is used as callback identifier.