SALUD L. Liess, Ed. Internet-Draft R. Jesske Updates: 3261 (if approved) Deutsche Telekom AG Intended status: Standards Track A. Johnston Expires: April 5, 2013 Avaya D. Worley Ariadne P. Kyzivat Huawei October 2, 2012 Alert-Info URNs for the Session Initiation Protocol (SIP) draft-ietf-salud-alert-info-urns-07 Abstract The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. This document normatively updates [RFC3261], the Session Initiation Protocol (SIP). It changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). Requirements Language 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 [RFC2119]. 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/. Liess, et al. Expires April 5, 2013 [Page 1] Internet-Draft Alert-Info URNs October 2012 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 5, 2013. Copyright Notice Copyright (c) 2012 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 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. Liess, et al. Expires April 5, 2013 [Page 2] Internet-Draft Alert-Info URNs October 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Alert-Info Header Field Usage Change . . . . . . . . . . . 6 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. PBX Ring Tones . . . . . . . . . . . . . . . . . . . . . . 9 3.1.1. normal . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. external . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.3. internal . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.4. priority . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.5. short . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1.6. delayed . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. Service Tones . . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. call-waiting . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. forward . . . . . . . . . . . . . . . . . . . . . . . 11 3.2.3. transfer-recall . . . . . . . . . . . . . . . . . . . 11 3.2.4. auto-callback . . . . . . . . . . . . . . . . . . . . 11 3.2.5. hold-recall . . . . . . . . . . . . . . . . . . . . . 11 3.3. Country-specific ringback tone indications for the public telephone network . . . . . . . . . . . . . . . . . 11 4. Namespace Registration Template . . . . . . . . . . . . . . . 12 5. Alert-Info URN Values Definitions . . . . . . . . . . . . . . 15 5.1. Alert-category Values Definitions . . . . . . . . . . . . 15 5.2. Alert-indication Values Definitions . . . . . . . . . . . 16 5.2.1. Alert-Info URN Indication Values for the alert-category 'service' . . . . . . . . . . . . . . . 16 5.2.2. Alert-Info URN Indication Values for the alert-category 'source' . . . . . . . . . . . . . . . 16 5.2.3. Alert-Info URN Indication Values for the alert-category 'priority' . . . . . . . . . . . . . . 17 5.2.4. Alert-Info URN Indication Values for the alert-category 'duration' . . . . . . . . . . . . . . 17 5.2.5. Alert-Info URN Indication Values for the alert-category 'delay' . . . . . . . . . . . . . . . . 17 5.2.6. Alert-Info URN Indication Values for the alert-category 'locale' . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 6.1. New alert identifiers . . . . . . . . . . . . . . . . . . 18 6.2. Initial IANA Registration . . . . . . . . . . . . . . . . 19 6.2.1. The "service" alert-category and alert-identifiers . . 19 6.2.2. The "source" alert-category and alert-identifiers . . 19 6.2.3. The "priority" alert-category and alert-identifiers . 20 6.2.4. The "duration" alert-category and alert-identifiers . 20 6.2.5. The "delay" alert-category and alert-identifiers . . 21 6.2.6. The "locale" alert-category and alert-identifiers . . 21 Liess, et al. Expires April 5, 2013 [Page 3] Internet-Draft Alert-Info URNs October 2012 7. Extensibility Rules . . . . . . . . . . . . . . . . . . . . . 22 7.1. General Extensibility Rules . . . . . . . . . . . . . . . 22 7.2. Extensions Rules for Independent Organizations . . . . . . 22 8. Combinations of Alert-Info URNs . . . . . . . . . . . . . . . 23 8.1. Priority Rules . . . . . . . . . . . . . . . . . . . . . . 23 8.2. Multi-mode signals . . . . . . . . . . . . . . . . . . . . 25 9. Non-normative Algorithm for Handling Combinations of URNs . . 25 9.1. Algorithm Description . . . . . . . . . . . . . . . . . . 25 9.2. Examples of how the algorithm works . . . . . . . . . . . 27 9.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 27 9.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 28 9.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 31 9.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 32 9.2.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . 33 10. User Agent Behaviour . . . . . . . . . . . . . . . . . . . . . 34 11. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . . . 35 12. Internationalization Considerations . . . . . . . . . . . . . 35 13. Security Considerations . . . . . . . . . . . . . . . . . . . 36 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 15.1. Normative References . . . . . . . . . . . . . . . . . . . 36 15.2. Informative References . . . . . . . . . . . . . . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Liess, et al. Expires April 5, 2013 [Page 4] Internet-Draft Alert-Info URNs October 2012 1. Introduction 1.1. Motivation The Session Initiation Protocol (SIP) [RFC3261] includes a means to suggest to a user agent (UA) a particular ringback tone or ring tone to be used during session establishment. In [RFC3261] this is done by including a URI in the Alert-Info header field, that specifies the tone. The URI is most commonly the HTTP URL to the audio file. On the receipt of the Alert-Info header field the user agent may fetch the referenced ringback tone or ring tone and play it to the user. This mechanism hinders interoperability when there is no common understanding of the meaning of the referenced tone, which might be country- or vendor-specific. It can lead to problems for the user trying to interpret the tone and for the UA wanting to substitute its own tone (e.g., in accordance with user preferences) or provide an alternative alerting mode (e.g., for hearing-impaired users). If caller and callee are from different countries, the understanding of the tones may vary significantly. Hearing impaired users may not sense the specific tone if it is provided as an audio file. The tone per se is also not useful for automata. There are currently interoperability issues around the use of the Alert-Info header field when not using an external ring file. For example, consider the PBX special ring tone for an external (to the PBX) caller. Different vendors use different approaches such as: Alert-Info: ;alert=normal where ring.pcm is a dummy file or: Alert-Info: or: Alert-Info: . As a result, Alert-Info currently only works when the same vendor provides PBX and UA, as only then is the same "fake" proprietary URI convention used. Another limitation of the current solution is that the referenced tones are tied to particular rendering. It is not possible to provide semantic indications or names for rendering characteristics that signals the intent and allows the recipient to decide how to render the received information in an appropriate way. To solve the described issues, this specification defines the new URN namespace 'alert' for the Alert-Info header field that allows for programmatic user interface adaptation and for conversion of equivalent alerting tones in the Public Switched Telephone Network (PSTN) when the client is a gateway. The work to standardize an Alert-Info URN will increase SIP interoperability for this header field by replacing proprietary conventions used today. Using the 'alert' namespace provides syntax for several different Liess, et al. Expires April 5, 2013 [Page 5] Internet-Draft Alert-Info URNs October 2012 application spaces, e. g.: o Names for service indications, such as call waiting or automatic callback, not tied to any particular rendering. o Names for common ring tones generated by PBX phones for cases such as an internal enterprise caller, external caller, ringback tone after a transfer failure or expiration of a hold timer, etc. o Names for country-specific ringback tones. o Names for things with specific renderings that aren't purely audio. They might be static icons, video sequences, text, etc. Some advantages of a URN rather than a URL of a downloadable resource: o Do not need to download it or deal with security issues associated with dereferencing. o No formatting or compatibility issues. o No security risk of rendering something unexpected and undesirable. o The tone can be stored locally in whatever format and at whatever quality level is appropriate, because it is specified "by name" rather than "by value". o It is easier to make policy decisions about whether to use it or not. o It facilitates translation for the hearing impaired. The downside is that if the recipient does not understand the URN then it will only be able to render a default ringback tone or ring tone. This document creates a new URN namespace and registry for alert indications and registers some initial values. 1.2. Alert-Info Header Field Usage Change This specification changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). In practice, this specification extends Alert-Info in that it will Liess, et al. Expires April 5, 2013 [Page 6] Internet-Draft Alert-Info URNs October 2012 cause the use of a new class of URIs and the use of multiple URIs. Backward compatibility issues are not expected, as devices that do not understand an Alert-Info URN should ignore it, and devices should not malfunction upon receiving multiple Alert-Info alert-params (which was syntactically permitted before, but rarely used). 1.3. Terminology This specification uses a number of terms to refer to the roles involved in the use of alerting indications in SIP. A "specifier" sends an "alerting indication" (one or more URNs in an Alert-Info header) to a "renderer" which then "renders" a "signal" or "rendering" based on the indication to a human user. A "category" is a characteristic whose "values" can be used to classify indications. This specification uses the terms "ring tone" and "ringback tone". A "ring tone" or "calling signal" (terminology used in [E182]) is a signal generated by the callee's end device, advising the callee about an incoming call. A "ringback tone" or "ringing tone" (terminology used in [E182]) is a signal advising the caller that a connection has been made and that a ring tone is being rendered to the callee. 2. Requirements This section discusses the requirements for an alerting indication to transport the semantics of the alerting situation or the characteristics of the rendering. REQ-1: The mechanism will allow user agents (UAs) and proxies to provide in the Alert-Info header field an alerting indication which describes the semantics of the signaling situation or the characteristics of the rendering and allows the recipient to decide how to render the received information to the user. REQ-2: The mechanism will allow the alerting indication to be specified "by name" rather than "by value", to enable local policy decisions whether to use it or not. REQ-3: The mechanism will enable alerting indications to represent a wide variety of signals, which have many largely-orthogonal characteristics. REQ-4: has been deleted. To avoid confusion, the number will not be reused. REQ-5: The mechanism will enable the set of alerting indications to Liess, et al. Expires April 5, 2013 [Page 7] Internet-Draft Alert-Info URNs October 2012 be able to support extensibility by a wide variety of organizations that are not coordinated with each other. Extensions will be able to: - add further values to any existing category - add further categories that are orthogonal to existing categories - semantically subdivide the meaning provided by any existing indication REQ-6: The mechanism will be flexible, so new alerting indications can be defined in the future, when SIP-applications evolve. E. g. Alert-Info URNs could identify specific media by name, such as "Beethoven's Fifth", and the end device could render some small part of it as a ring tone. REQ-7: The mechanism will provide only an indication capability, not a negotiation capability. REQ-8: The mechanism will not require an alerting indication to depend on context provided by a previous alerting indication in either direction. REQ-9: The mechanism will allow transmission in the Alert-Info header field of SIP INVITE requests and provisional 1xx responses excepting the 100 responses. REQ-10: The mechanism will be able to accommodate renderers that are customized with a limited or uncommon set of signals they can render and renderers that are provided with a set of signals that have uncommon semantics. (The canonical example is a UA for the hearing- impaired, customized with an uncomon set of signals, video or text instead of audio. By REQ-7, the renderer has no way of transmitting this fact to the specifier.) REQ-11: The mechanism will allow an alerting indication to reliably carry all extensions if the specifier and the renderer have designs that are properly coordinated. REQ-12: The mechanism will allow a renderer to select a tone that approximates to that intended by the specifier if the renderer is unable to provide the precise tone indicated. REQ-13: The mechanism will support alerting indications relating to services such as call waiting, forward, transfer-recall, auto- callback and hold-recall. Liess, et al. Expires April 5, 2013 [Page 8] Internet-Draft Alert-Info URNs October 2012 REQ-14: The mechanism will allow rendering common PBX ring tone types. REQ-15: The mechanism will allow rendering specific country ringback tones. REQ-16: The mechanism will allow rendering tones for emergency alerts. (Use cases and values definition are not subject of this specification.) REQ-17: The mechanism will allow rendering using other means than tones, e.g. text or images. REQ-18: The mechanism will allow TDM gateways to map ring/ringback tones from legacy protocols to SIP at the edge of a network, e.g. national ring tones as defined in TIA/EIA-41-D and 3GPP2 A.S0014. (Use cases and values definition are not subject of this specification.) REQ-19: The mechanism will ensure that if an UA receives Alert-Info URNs or portions of an Alert-Info URN it does not understand, it can ignore them. REQ-20 The mechanism will allow storage of the actual encoding of the rendering locally rather than fetching it. REQ-21: The mechanism must provide a simple way to combine two alerting indications to produce an alerting indication that requests a combination of the intentions of the two alerting indications, where any contradictions or conflicts between the two alerting indications are resolved in favor of the intention of the first alerting indication. 3. Use Cases This section describes some use cases for which the Alert-Info URN mechanism is needed today. 3.1. PBX Ring Tones This section defines some commonly encountered ring tones on PBX or business phones. They are as follows: 3.1.1. normal This tone indicates that the default or normal ring tone should be rendered. This is essentially a no-operation Alert-Info URN and Liess, et al. Expires April 5, 2013 [Page 9] Internet-Draft Alert-Info URNs October 2012 should be treated by the UA as if no Alert-Info URN is present. This is most useful when Alert-Info header field parameters are being used. For example, in [I-D.ietf-bliss-shared-appearances], an Alert- Info header field needs to be present containing the "appearance" parameter, but no special ring tone needs to be specified. 3.1.2. external This tone is used to indicate that the caller is external to the enterprise or PBX system. This could be a call from the PSTN or from a SIP trunk. 3.1.3. internal This tone is used to indicate that the caller is internal to the enterprise or PBX system. The call could have been originated from another user on this PBX or on another PBX within the enterprise. 3.1.4. priority A PBX tone needs to indicate that a priority level alert should be applied for the type of alerting specified (e.g. internal alerting). 3.1.5. short In this case the alerting type specified (e.g. internal alerting) should be rendered shorter than normal. In contact centers, this is sometimes referred to as "abbreviated ringing" or a "zip tone". 3.1.6. delayed In this case the alerting type specified should be rendered after a short delay. In some bridged line/shared line appearance implementations, this is used so that the bridged line does not ring at exactly the same time as the main line, but is delayed a few seconds. 3.2. Service Tones These tones are used to indicate specific PBX and public network telephony services. 3.2.1. call-waiting The Call Waiting Service [TS24.615] permits a callee to be notified of an incoming call while the callee is engaged in an active or held call. Subsequently, the callee can either accept, reject, or ignore the incoming call. There is an interest on the caller side to be Liess, et al. Expires April 5, 2013 [Page 10] Internet-Draft Alert-Info URNs October 2012 informed about the call waiting situation on the callee side. Having this information the caller can decide whether to continue waiting for callee to pickup or better to call some time later when it is estimated that the callee could have finished the ongoing conversation. To provide this information, the callee's UAS ( or proxy) aware of the call waiting condition can add the call-waiting indication to the Alert-Info header field in the 180 Ringing response. As call-waiting information may be subject to the callee's privacy concerns, the exposure of this information shall be done only if explicitly required by the callee. 3.2.2. forward This feature is used in a 180 Ringing response when a call forwarding feature has been initiated on an INVITE. Many PBX system implement a forwarding "beep" followed by normal ringing to indicate this. Note that a 181 response can be used in place of this URN. 3.2.3. transfer-recall This feature is used when a blind transfer [RFC5589] has been performed by a server on behalf of the transferor and fails. Instead of failing the call, the server calls back the transferor, giving them another chance to transfer or otherwise deal with the call. This service tone is used to distinguish this INVITE from any other normal incoming call. 3.2.4. auto-callback This feature is used when a user has utilized a server to implement an automatic callback service [I-D.ietf-bliss-call-completion]. When the user is available, the server calls back the user and utilizes this service tone to distinguish this from any other normal incoming call. 3.2.5. hold-recall This feature is used when a server implements a call hold timer on behalf of an endpoint. After a certain period of time of being on hold, the user who placed the call on hold is alerted to either retrieve the call or otherwise dispose of the call. This service tone is used to distinguish this case from any other normal incoming call. 3.3. Country-specific ringback tone indications for the public telephone network In the PSTN, different tones are used in different countries. End Liess, et al. Expires April 5, 2013 [Page 11] Internet-Draft Alert-Info URNs October 2012 users are accustomed to hear the callee's country ringback tone and would like to have this feature for SIP. 4. Namespace Registration Template This section describes the registration template for the 'alert' URN namespace identifier (NID) according to the [RFC2141] and [RFC3406] Namespace ID: alert Registration Information: Registration version: 1 Registration date: TBD Declared registrant of the namespace: Registering organization: IETF Designated contact: Laura Liess Designated contact email: l.liess@telekom.de Declaration of syntactic structure: The Namespace Specific String (NSS) for the "alert" URNs is called alert-identifier and has a hierarchical structure. The left-most