SALUD L. Liess, Ed. Internet-Draft R. Jesske Updates: 3261 (if approved) Deutsche Telekom AG Intended status: Standards Track A. Johnston Expires: January 12, 2014 Avaya D. Worley Ariadne P. Kyzivat Huawei July 11, 2013 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP) draft-ietf-salud-alert-info-urns-08 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 (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for 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 these limitations and support new applications, a new family of URNs for use in SIP Alert-Info header fields (and situations with similar requirements) 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 Liess, et al. Expires January 12, 2014 [Page 1] Internet-Draft Alert URNs July 2013 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 January 12, 2014. Copyright Notice Copyright (c) 2013 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 January 12, 2014 [Page 2] Internet-Draft Alert URNs July 2013 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. URN Specification for the "alert" namespace identifier . . . 12 5. "Alert" URN Values Definitions . . . . . . . . . . . . . . . . 18 5.1. Values Definitions . . . . . . . . . . . 18 5.2. Values Definitions . . . . . . . . . . 18 5.2.1. Values for the 'service' . . . . . . . . . . . . . . 19 5.2.2. Values for the 'source' . . . . . . . . . . . . . . 19 5.2.3. Values for the 'priority' . . . . . . . . . . . . . 19 5.2.4. Values for the 'duration' . . . . . . . . . . . . . 19 5.2.5. Values for the 'delay' . . . . . . . . . . . . . . . 20 5.2.6. Values for the 'locale' . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6.1. Registry . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2. Initial IANA Registration . . . . . . . . . . . . . . . . 21 6.2.1. The "service" and s . . . . . . . . . . . . . . . . . 21 6.2.2. The "source" and s . . . . . . . . . . . . . . . . . 22 6.2.3. The "priority" and s . . . . . . . . . . . . . . . . . 22 Liess, et al. Expires January 12, 2014 [Page 3] Internet-Draft Alert URNs July 2013 6.2.4. The "duration" and s . . . . . . . . . . . . . . . . . 23 6.2.5. The "delay" and s . . . . . . . . . . . . . . . . . 23 6.2.6. The "locale" and s . . . . . . . . . . . . . . . . . 23 7. Extension Rules . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. General Extension Rules . . . . . . . . . . . . . . . . . 24 7.2. Private Extension Rules . . . . . . . . . . . . . . . . . 24 7.3. Interpreting values . . . . . . . . . . . . . . 25 7.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 26 7.4.1. Subsetting an existing URN . . . . . . . . . . . . . . 26 7.4.2. A new value within an . . . . . . . . 27 7.4.3. A new . . . . . . . . . . . . . . . . 27 7.4.4. Subsetting a private extension URN . . . . . . . . . . 27 7.4.5. Default s . . . . . . . . . . . . . . . . . . . 28 8. Combinations of "alert " URNs . . . . . . . . . . . . . . . . 28 8.1. Priority Rules . . . . . . . . . . . . . . . . . . . . . . 28 8.2. Multi-mode signals . . . . . . . . . . . . . . . . . . . . 30 9. Non-normative Algorithm for Handling Combinations of URNs . . 30 9.1. Algorithm Description . . . . . . . . . . . . . . . . . . 30 9.2. Examples of how the algorithm works . . . . . . . . . . . 32 9.2.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 32 9.2.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 34 9.2.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 36 9.2.4. Example 4 . . . . . . . . . . . . . . . . . . . . . . 36 9.2.5. Example 5 . . . . . . . . . . . . . . . . . . . . . . 37 10. User Agent Behaviour . . . . . . . . . . . . . . . . . . . . . 38 11. Proxy Behaviour . . . . . . . . . . . . . . . . . . . . . . . 39 12. Internationalization Considerations . . . . . . . . . . . . . 39 13. Security Considerations . . . . . . . . . . . . . . . . . . . 40 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 15.1. Normative References . . . . . . . . . . . . . . . . . . . 40 15.2. Informative References . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Liess, et al. Expires January 12, 2014 [Page 4] Internet-Draft Alert URNs July 2013 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 if 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 UA 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" 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 January 12, 2014 [Page 5] Internet-Draft Alert URNs July 2013 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). Previously, the Alert-Info header field was only permitted in 180 (Ringing) responses. But in telephony, other situations indicated by SIP provisional responses, such as 181 (Call Is Being Forwarded) and 182 (Call Is Being Queued), are often indicated by tones. Extending the applicability of Alert-Info allows the telephony practice to be implemented in SIP. In practice, this specification extends Alert-Info in that it will cause the use of a new class of URIs and the use of multiple URIs. Liess, et al. Expires January 12, 2014 [Page 6] Internet-Draft Alert URNs July 2013 Backward compatibility issues are not expected, as devices that do not understand an "alert" 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 field) 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 be able to support extensibility by a wide variety of organizations Liess, et al. Expires January 12, 2014 [Page 7] Internet-Draft Alert URNs July 2013 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" 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. REQ-14: The mechanism will allow rendering common PBX ring tone types. REQ-15: The mechanism will allow rendering specific country ringback Liess, et al. Expires January 12, 2014 [Page 8] Internet-Draft Alert URNs July 2013 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" URNs or portions of an "alert" 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" 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" URN and should be treated by the UA as if no "alert" 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 Liess, et al. Expires January 12, 2014 [Page 9] Internet-Draft Alert URNs July 2013 no special ring tone needs to be specified. [Note to RFC Editor: Please update the information for this reference and change its tag from "I-D.ietf-bliss-shared-appearances" to the appropriate RFC number.] 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 January 12, 2014 [Page 10] Internet-Draft Alert URNs July 2013 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 [RFC6910]. 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 users are accustomed to hear the callee's country ringback tone and Liess, et al. Expires January 12, 2014 [Page 11] Internet-Draft Alert URNs July 2013 would like to have this feature for SIP. 4. URN Specification for the "alert" namespace identifier This section provides the registration template for the "alert" URN namespace identifier (NID) according to [RFC2141] and [RFC3406] Namespace ID: alert Registration Information: Registration version: 1 Registration date: TBD Declared registrant of the namespace: Registering organization: Real-time Applications and Infrastructure Area IETF Designated contact: RAI Area Director Designated contact email: rai at ietf.org Declaration of syntactic structure: The Namespace Specific String (NSS) for the "alert" URNs is called an and has a hierarchical structure. The first colon-separated part after "alert" is called the ; the parts to the right of that are s, and together form the . The general form is urn:alert::. The following identifiers defined in [RFCXXXX]: "service" , "priority" , "source" , "duration", "delay" and "locale". The set can be extended in the future, either by standardization or by private action. The s describe distinct features of alerting signals. RFC EDITOR NOTE: Please change XXXX in [RFCXXXX] by the new RFC number, when assigned. Any "alert" URN defined in this specification is syntactically valid for ring and ringback tones and can be used in INVITE requests or in provisional 1xx responses excepting the 100 response. Liess, et al. Expires January 12, 2014 [Page 12] Internet-Draft Alert URNs July 2013 s MUST comply with the syntax for Non Reserved LDH- labels [RFC5890]. s MUST comply with the syntax for Non Reserved LDH-labels or the syntax for A-labels [RFC5890]. Registered URNs and components thereof MUST be transmitted as registered (including case). A new URN MUST NOT be registered if it is equal by the comparison rules to an already registered URN. The ABNF [RFC5234] for the "alert" URNs is shown below: alert-URN = "urn:alert:" alert-identifier alert-identifier = alert-category ":" alert-indication alert-category = alert-name alert-indication = alert-ind-part *(":" alert-ind-part) alert-ind-part = alert-name alert-name = alert-label / private-name private-name = alert-label "@" provider provider = provider-id ["(" date ")"] provider-id = 1*(domain-label ".") domain-label alert-label = let-dig [ *let-dig-hyp let-dig ] domain-label = let-dig [ *let-dig-hyp let-dig ] let-dig-hyp = let-dig / "-" let-dig = ALPHA / DIGIT date = [CC] YY [ "-" MM ["-" DD] ] CC = DIGIT DIGIT YY = DIGIT DIGIT MM = ( "0" %x31-39 ) / ( "1" %x30-32 ) DD = ( "0" %x31-39 ) / ( %x31-32 DIGIT ) / "30" / "31" ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 Relevant ancillary documentation: [RFCXXXX] RFC EDITOR NOTE: Please change XXXX in [RFCXXXX] by the new RFC number, when assigned. Namespace considerations: This specification defines a URN namespace "alert" for URNs representing signals or renderings which are presented to users to inform them of events and actions. The initial usage is to specify ring tones and ringback tones when dialogs are established in SIP, but they can also be used for other commuication-initiation protocols (e.g., H.323), and more generally, in any situation (e.g., web pages or endpoint device software configurations) to describe how a user should be signaled. Liess, et al. Expires January 12, 2014 [Page 13] Internet-Draft Alert URNs July 2013 An "alert" URN does not describe a complete signal, but rather describes a particular characteristic of the event it is signaling or a feature of the signal to be presented. The complete specification of the signal is a sequence of "alert" URNs specifying the desired characteristics/significance of the signal in priority order, with the most important aspects specified by the earlier URNs. This allows the sender of a sequence of URNs to compose very detailed specifications from a restricted set of URNs, and to clearly specify which aspects of the specification it considers most important. The initial scope of usage is in the SIP Alert-Info header field, in initial INVITE requests (to indicate how the called user should be alerted regarding the call) and non-100 provisional (1xx) responses to those INVITE requests (to indicate the ringback, how the calling user should be alerted regarding the progress of the call). In order to assure widespread adoption of these URNs for indicating ring tones and ringback tones, the scheme must allow replication of the current diversity of these tones. Currently, these tones vary between the PSTNs of different nations and between equipment supplied by different vendors. Thus, the scheme must accommodate national variations and proprietary extensions in a way that minimizes the information that is lost during interoperation between systems that follow different national variations or that are supplied by different vendors. The scheme allows definition of private extension URNs that refine and extend the information provided by standard URNs. Private extension URNs can also refine and extend the information provided by other private extension URNs. Private extensions can also define entirely new categories of information about calls. We expect these extensions to be used extensively when existing PBX products are converted to support SIP operation. The device that receives an Alert-Info header field containing a sequence of "alert" URNs provides to the user a rendering that represents the semantic content of the URNs. The device is given great leeway in choosing the rendering, but it is constrained by rules that maximize interoperability between systems that support different sets of private extensions. In particular, earlier URNs in the sequence have priority of expression over later URNs in the sequence, and URNs that are not usable in their entirety (because they contain unknown extensions or are incompatible with previous URNs) are successively truncated in attempt to construct a URN that retains some information and is renderable in the context. Liess, et al. Expires January 12, 2014 [Page 14] Internet-Draft Alert URNs July 2013 Due to the practical importance of private extensions for the adoption of URNs for alerting calls and the very specific rules for private extensions and the corresponding processing rules that allow quality interoperation in the face of private extensions, the requirements of the "alert" URN schems cannot be met by a fixed enumeration of URNs and corresponding meanings. In particular, the existing namespace "urn:ietf:params" does not suffice (unless the private extension apparatus is applied to that namespace). [Note, to be deleted for the final version of this draft: Because the work on this draft has lasted for about four years, the new "alert" URN namespace is already used in finalized specifications of other SDOs (3GPP). There are already existing implementations in products and large carrier networks. is also specified for use in draft-ietf-bliss-shared-appearances.] There do not appear to be other URN namespaces that uniquely identify the semantic of a signal or rendering feature. Unlike most other currently registered URN namespaces, the "alert" URN does not identify documents and protocol objects (e.g., [RFC3044], [RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198]), types of telecommunications equipment [RFC4152], people or organizations [RFC3043]. The s are hierarchical identifiers. An asserts some fact or feature of the offered SIP dialog, or some fact or feature of how it should be presented to a user, or of how it is being presented to a user. Removing an from the end of an (which has more than one s) creates a shorter with a less specific meaning; the set of dialogs to which the longer applies is necessarily a subset of the set of dialogs to which the shorter applies. (If the starting contains only one , and thus the cannot be removed to make a shorter , we can consider the set of dialogs to which the applies to be a subset of the set of all dialogs.) The specific criteria defining the subset to which the longer applies, within the larger set of dialogs, is considered to be the meaning of the final . This meaning is relative to and depends upon the preceding and s (if any). The meanings of two s that are textually the same but are preceded by different s or s have no necessary connection. (An considered alone has no Liess, et al. Expires January 12, 2014 [Page 15] Internet-Draft Alert URNs July 2013 meaning.) The organization owning the within a specifies the meaning of that when it is used as an . (The organization owning a is determined by the rules in Section 7.2.) The organization owning the within a (in either an or an ) specifies the meaning of each which is an that follows that and that precedes the next which is a (if any). The meaning of all other s (i.e., those that are not s and do not follow a ) is defined by standardization. Community considerations: The "alert" URNs are relevant to a large cross-section of Internet users, namely those that initiate and receive communication connections via the Session Initiation Protocol. These users include both technical and non-technical users, on a variety of devices and with a variety of perception capabilities. The "alert" URNs will allow Internet users to receive more information about offered calls and enable them to better make decisions about accepting an offered call, and to get better feedback on the progress of a call they have made. User interfaces for perception-impaired users can better render the ring and ringback tones based on the "alert" URNs because the URNs provide more detailed information regarding the intention of communications than is provided by current SIP mechanisms. Process of identifier assignment: Assignment of standardized "alert" URNs is by insertion into the IANA registry described in Section 6. This process defines the meanings of s that have standardized meanings, as described in "Namespace Considerations". Private extensions are "alert" URNs that include s that are s and s that appear after a s (either as an or an ). If such an is a , its meaning is defined by the organization that owns the that appears in the . If the is an , its meaning is defined by the organization that owns the that appears in the closest private-name> preceeding the . The rules for determining the organization that owns a are given in Liess, et al. Expires January 12, 2014 [Page 16] Internet-Draft Alert URNs July 2013 Section 7.2. Identifier uniqueness and persistence considerations: An "alert" URN identifies a semantic feature of a call or a sensory feature of how the call alerting should be a rendered at the caller's or callee's end device. For standardized in URNs, uniqueness and persistence of their meanings is guaranteed by the fact that they are registered with IANA in accordance with the procedures of Section 6; the feature identified by a particular "alert" URN is distinct from the feature identified by any other standardized "alert" URN. Assuring uniqueness and persistence of the meanings of private extensions is delegated to the organizations that define private extension . The organization responsible for a particular in a particular "alert" URN is the owner of a syntactically-determined part within the URN. Once an organization obtains ownership of a particular , it retains ownership of it for all time, as described in Section 7.2. An organization SHOULD use only one value for all of the s it defines. Process for identifier resolution: The process of identifier resolution is the process by which a rendering device chooses a rendering to represent a sequence of "alert" URNs. The device is allowed great leeway in making this choice, but the process must obey the rules of Section 8.1. The device is expected to provide renderings that users associate with the meanings assigned to the URNs within their cultural context. A non-normative example resolution algorithm is given in Section 9.1. Rules for lexical equivalence: "alert" URNs are compared according to case-insensitive string equality, except that every part is treated as if the component is present and has all omitted components as specified by the defaults in Section 7.3, viz., an omitted defaults to "2013-01-01", an omitted defaults to "20", and an omitted or
defaults to "01". Conformance with URN syntax: All "alert" URNs must conform to the BNF in the 'Declaration of syntactic structure', which is a subset of the generic URN syntax. Note that "internationalized" DNS labels may appear in s, in which case they must appear as A-labels, that is, as transformed by Punycode. s, that is, components that are not DNS labels, are Liess, et al. Expires January 12, 2014 [Page 17] Internet-Draft Alert URNs July 2013 constrained to be Non Reserved LDH-labels, that is, "ordinary ASCII labels". Future standardization may allow s that are A-labels, and so interpreters of "alert" URNs must operate correctly when given such URNs as input. Validation mechanism: An "alert" URN containing no private extensions can be validated based on the IANA registry of standardized "alert" URNs. Validating an "alert" URN containing private extensions requires obtaining information regarding the private extensions defined by the organization that owns the in the relevant . The identity of the organization can be determined from public registries of historical ownership of domain names, in accordance with the procedures of Section 7.2. However, if an "alert" URN contains at least one that precedes the first , the portion of the "alert" URN that precedes the first must itself be a valid standardized "alert" URN, which may be validated as above. Scope: The scope for this URN is public and global. 5. "Alert" URN Values Definitions 5.1. Values Definitions Following values are defined in this document: - service - source - priority - duration - delay - locale 5.2. Values Definitions This section describes the "alert" URN indication values for the alert-categories defined in this document. For each , a default is defined, which is essentially a no-operation"alert" URN and should be treated by the UA as if no "alert" URN for the respective category is present. "alert" URN default indications are 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 ringtone need be specified. Liess, et al. Expires January 12, 2014 [Page 18] Internet-Draft Alert URNs July 2013 The "" syntax is used for extensions defined by independent organizations, as described in Section 7.2. 5.2.1. Values for the 'service' - normal (default) - call-waiting - forward - recall:callback - recall:hold - recall:transfer - Examples: or . 5.2.2. Values for the 'source' - unclassified (default) - internal - external - friend - family - Examples: . 5.2.3. Values for the 'priority' - normal (default) - low - high - Examples: . 5.2.4. Values for the 'duration' - normal (default) - short - long - Examples: . Liess, et al. Expires January 12, 2014 [Page 19] Internet-Draft Alert URNs July 2013 5.2.5. Values for the 'delay' - none (default) - yes - Examples: . 5.2.6. Values for the 'locale' - default (default) - country: - The ISO 3166-1 country code [ISO3166-1] is used to inform the renderer on the other side of the call that a country-specific rendering should be used. For example, to indicate ringback tones from South Africa, the following URN would be used: . 6. IANA Considerations This section registers a new URN namespace identifier (NID), "alert", in accordance with RFC 3406 with the registration template provided in Section 4. 6.1. Registry Standard "alert" URNs are identified by s managed by IANA, according to the processes outlined in [RFC5226], in a new registry called "Alert URN Identifiers". Thus, creating a new standard "alert" URN requires IANA action. The registry contains: (1) values, (2) values, composed of an followed by an , in turn composed of one or more s, and (3) patterns for values (e.g., for the "locale" in Section 6.2.6). The policy for adding a new standard is 'Standards Action'. The policy for adding s or patterns of s within a particular may differ for each and MUST be defined by the document defining the corresponding . and values which contain s are not managed by IANA. The process of identifier Liess, et al. Expires January 12, 2014 [Page 20] Internet-Draft Alert URNs July 2013 assignement is described in Section 4. 6.2. Initial IANA Registration This document defines the s 'service', 'source', 'priority', 'duration', 'delay' and 'locale'. The policy for adding an for any of these s is Standards Action. The entries to be added to the registration table have the following format: / Reference Description ; --------------------------------------------------------------- foo RFCxyz Description of the 'foo' ; foo:bar RFCabc Description of the 'foo:bar' RFC EDITOR NOTE: Please change XXXX in [RFCXXXX] by the new RFC number, when assigned. 6.2.1. The "service" and s The following table contains the initial IANA registration for the "service" and s. The value of this indicator is set to a value different from "normal" if the caller or callee is informed that a specific telephony service has been initiated. / Reference Description ----------------------------------------------------------- service [RFCXXXX] Specific telephony service used in this call service:normal [RFCXXXX] Normal ring/ringback rendering (default value) service:call-waiting [RFCXXXX] Call waiting was initiated at the other side of the call service:forward [RFCXXXX] Call has been forwarded service:recall:callback [RFCXXXX] Recall due to callback service:recall:hold [RFCXXXX] Recall due to call hold service:recall:transfer [RFCXXXX] Recall due to transfer Liess, et al. Expires January 12, 2014 [Page 21] Internet-Draft Alert URNs July 2013 6.2.2. The "source" and s The following table contains the initial IANA registration for the "source" and . The value of this indicator provides information about the user at the other side of the call. / Reference Description ----------------------------------------------------------- source [RFCXXXX] Classification of the other party to the call source:unclassified [RFCXXXX] Unclassified ring/ringback rendering (default value) source:internal [RFCXXXX] User at the other side of the call is internal to the enterprise or PBX system source:external [RFCXXXX] User at the other side of the call is external to the enterprise or PBX system source:friend [RFCXXXX] User at the other side of the call is a friend source:family [RFCXXXX] User at the other side of the call is a family member 6.2.3. The "priority" and s The following table contains the initial IANA registration for the "priority" and s. The value of this indicator provides information about the priority the alerted user should give to the call. / Reference Description ----------------------------------------------------------- priority [RFCXXXX] Priority of the call priority:normal [RFCXXXX] Normal ring/ringback rendering (default value) priority:low [RFCXXXX] Low priority call. priority:high [RFCXXXX] High priority call Liess, et al. Expires January 12, 2014 [Page 22] Internet-Draft Alert URNs July 2013 6.2.4. The "duration" and s The following table contains the initial IANA registration for the "duration" and s. The value of this indicator provides information about the duration of the alerting signals compared to the default alerting signals. / Reference Description ----------------------------------------------------------- duration [RFCXXXX] Duration of alerting signal alerting signal duration:normal [RFCXXXX] Normal ring/ringback rendering (default value) duration:short [RFCXXXX] Shorter than normal duration:long [RFCXXXX] Longer than normal 6.2.5. The "delay" and s The following table contains the initial IANA registration for the "delay" and s. The value of this indicator provides information about about whether the presentation of the alerting signal should be delayed compared to the default presentation process. For more details see Section 3.1.6. / Reference Description ----------------------------------------------------------- delay [RFCXXXX] Delay of rendering of alerting of alerting signal delay:none [RFCXXXX] Immediate alerting (default value) delay:yes [RFCXXXX] Delayed alerting 6.2.6. The "locale" and s The following table contains the initial IANA registration for the "locale" and s. The value of this indicator provides information suggests that alerting signals characteristic of the specified location should be used. Liess, et al. Expires January 12, 2014 [Page 23] Internet-Draft Alert URNs July 2013 / Reference Description ----------------------------------------------------------- locale [RFCXXXX] Location-specific alerting signals locale:default [RFCXXXX] Alerting not location specific (default value) locale:country: [RFCXXXX] Alerting according to the conventions of the specified country 7. Extension Rules 7.1. General Extension Rules The set of "alert" URNs is extensible. An extension "at the top level" creates an new (which represents a new alerting characteristic), an extension "at the second level" creates a new value for an existing , an extension "at the third level" creates a subdivision of an existing (that has one ), etc. URNs allow (in principle) indefinite subdivision of existing values, although most of the standard "alert" URNs have only one level of subdivision and a few have two levels of subdivision. Designers of extensions should take care to derive the new URN from the most specific base URN which has the correct meaning; a new URN should have no semantic overlap with any sibling URN, i.e., there can be no calls to which both URNs could apply. The process for defining new standard "alert" URNs is described in Section 6.1. Currently, all such definitions require Standards Action. The process for defining new "alert" URNs via the private extension mechanism is described in Section 7.2 is Standards Action. 7.2. Private Extension Rules The "" syntax is used to create private extensions, extensions that are not registered with IANA. The "" has the form of an "" (which has the same syntax as an ordinary ASCII DNS label), followed by "@" and then a that designates the organization defining the extension. A private extension URN is created by using a as either an or an . Liess, et al. Expires January 12, 2014 [Page 24] Internet-Draft Alert URNs July 2013 If the is used as an , the characteristic of the alerting signal that the describes is defined by the organization. If the is used as the first , the organization defines an alternative value for the standardized of the URN. If the is used as the second or later , the organization defines the meaning of the URN as a subset of the meaning of the shorter URN resulting when the (and any subsequent s) are removed. Within a URN, all components that follow a but are before any following s are additional private extensions whose meaning is defined by the organization defining the . A URN that contains a private extension can be further subdivided by the private extension of a different organization: the second organization adds a component containing a that is valid for the second organization. The meaning of a or an that is defined privately (because of a preceding ) is only fixed within the context provided by the sequence of preceding s; these components have no meaning in isolation and there is no necessary relationship between the meaning of textually identical s that are preceded by different sequences of s. . Creating private extension "alert" URNs is not a standards action and they are not registered with IANA. Adding new categories and adding values via the "private extension" mechanism is not a standards action. Once an organization obtains the right to use a particular for constructing s, it will retain that right forever, unless it transfers that right to another organization. The organization defining a private extension is responsible for ensuring persistence of the meaning of the private extension, and for ensuring that the private extension does not duplicate any standard URN or any private extension that the organization is aware of. (In either case, the organization SHOULD use the existing URN for its purposes.) 7.3. Interpreting values The organization that defines a particular is determined by the within the . An that follows a is defined by the organization Liess, et al. Expires January 12, 2014 [Page 25] Internet-Draft Alert URNs July 2013 determined by the within the . The organization determined by a is the organization that was the registered owner of the contained (which is a fully-qualified domain name) on the given date (interpreted according to the following default rules). If the is omitted, it defaults to "2013-01-01". If the century part is omitted, it defaults to "20". If the month part or the day part
is omitted, it defaults to "01". In addition, if an organization is the first registrant of a domain name (over all time), it may use any preceding when it registered the domain name. More specifically: On every date on which an organization is the registered owner of a domain name, the organization acquires an intellectual property right to define the meaning of s and s that are governed by a value specifying that domain name and that date (directly or by defaults). If an organization is the first registrant of a domain name, on the date it obtains the registration, it also acquires those rights for all values specifying that domain name and any date before the date of registration. Unless otherwise arranged, these intellectual property rights transfer if the organization transfers the right to use the domain name. However, if the organization's registration expires and another organization acquires registration of the domain name de novo, the first organization retains the rights that it possessed regarding that domain name. 7.4. Examples 7.4.1. Subsetting an existing URN A company owning the domain name somecompany.example.com can define distinctive versions of : urn:alert:service:call-waiting:abc@somecompany.example.com urn:alert:service:call-waiting:def@somecompany.example.com It can create a more specialized URN that applies to a subset of the situations to which the first URN above applies: urn:alert:service:call-waiting:abc@somecompany.example.com:xyz Because "xyz" follows "abc@somecompany.example.com" (and there is no intervening ), its meaning is defined by the owner of the "somecompany.example.com" (whose implicit date is "2013-01-01"). Liess, et al. Expires January 12, 2014 [Page 26] Internet-Draft Alert URNs July 2013 7.4.2. A new value within an A company owning the domain name somecompany.example.com can define URNs in the "service" category to express a new service that is not covered by any of the standardized URNs: urn:alert:service:ghi@somecompany.example.com However, before defining such a URN, the organization should verify that the set of calls to which the URN applies is not a subset of the set of calls for some existing URN. If it is a subset, the extension URN should be a subdivision of the existing URN. 7.4.3. A new A company owning the domain name somecompany.example.com can define an extension named "jkl@somecompany.example.com" with two values "a1" and "a2": urn:alert:jkl@somecompany.example.com:a1 urn:alert:jkl@somecompany.example.com:a2 7.4.4. Subsetting a private extension URN The company designated by "a.example.com(2013)" wants to define a set of URNs that specify the different ring patterns used by a "distinctive ring" service to alert for incoming calls that are directed to different directory numbers. These ring patterns are composed of groups of ring sounds that have particular patterns of lengths. The company can create a private "distinctive@a.example.com", and within it assign three 'alert' URNs that indicate the three different ring patterns used by the company's service: urn:alert:distinctive@a.example.com:long-long urn:alert:distinctive@a.example.com:short-long-short urn:alert:distinctive@a.example.com:short-short-long Later, the company designated by "b.example.com(2013)" wants to define an additional 'alert' URN for the ring pattern "short short", which it uses to support a fourth directory number for a phone instrument. The company can create a to be used with the "distinctive@a.example.com" : Liess, et al. Expires January 12, 2014 [Page 27] Internet-Draft Alert URNs July 2013 urn:alert:distinctive@a.example.com:short-short@b.example.com 7.4.5. Default s The United States Army has had possession of the domain name "army.mil" since at least 1990. Thus, it can use the following values (among many others): army.mil(1990) army.mil(2013-03) army.mil(2013-03-29) It can also use the following values, which all have the same meaning: army.mil army.mil(13) army.mil(13-01) army.mil(13-01-01) army.mil(2013) army.mil(2013-01) army.mil(2013-01-01) (Note that per Section 4 , an organization SHOULD use only one value for all of the s it defines.) 8. Combinations of "alert " URNs 8.1. Priority Rules This section describes combination rules for the case when all the Alert-Info header fields only contain "alert" URNs. Other combinations of URIs in the Alert-Info header fields of the same SIP message are not defined in this specification. In many cases, more than one URN will be needed to fully define a particular tone. This is done by including multiple "alert" URNs, in one or more Alert-Info header fields in a request or a response. For example, an internal, priority call could be indicated by Alert-Info: , A priority call waiting tone could be indicated by Alert-Info: , The sender of the Alert-Info header field may include an arbitrary list of "alert" URNs, even if they are redundant or contradictory. An earlier URN has priority over any later contradictory URN. This allows any element to modify a list of URNs to require a feature Liess, et al. Expires January 12, 2014 [Page 28] Internet-Draft Alert URNs July 2013 value (by adding a URN at the beginning of the list) or to suggest a feature value (by adding a URN at the end of the list). The receiving UA matches the received "alert" URN combination with the signal(s) it is able to render. The implementation is free to ignore an "alert" URN if it does not recognize the URN, or if it is incapable of rendering its effect in the context. Similarly, it can remove a final series of one or more s of an "alert" URN to create a "more generic" URN which it recognizes and whose meaning it can render in the context. The exact way in which a UA renders a received combination of "alert" URNs is left as an implementation issue. However, the implementation MUST comply to following rules: a. Each "alert" URN has precedence over all URNs that follow it, and its interpretation is subordinate to all URNs that precede it. b. If the UA cannot implement the effect of a URN (because it does not recognize the URN or the URN's effect is precluded by preceding URNs), the UA repeatedly removes the final of the URN until either (i) the resulting URN is recognized and can be given effect by some signal (without reducing the degree of expression of any preceding URN), or (ii) the resulting URN is reduced to having no in which case, that URN in the series cannot be given effect, and so is ignored. c. In case that after processing all the received URNs, the UA can generate more than one signal that are equally effective at expressing the URNs (under the preceding rules), one of those signals is selected. When selecting from the set of equally effective signals, no signal should be chosen if a less-specific signal is also in the set. (Specificity is to be judged based on the defined meanings of the signals to the user.) (E.g., if each signal is considered to express certain s of certain , one signal is less-specific than a second signal if the first signal's s are a subset or are prefixes of the second signal's s.) However, a more-specific signal may be chosen if the choice is based on information derived from the containing SIP message. E.g., a signal implying may be chosen if the SIP message contains the header field "Priority: urgent". Liess, et al. Expires January 12, 2014 [Page 29] Internet-Draft Alert URNs July 2013 In all situations, the set of signals that can be rendered and their significances may change based on user preferences and local policy. In addition, the chosen signal may change based on the status of the UA. E.g., if a call is active on the UA, all audible signals may become unavailable, or audible signals may be available only if is specified. 8.2. Multi-mode signals There are cases when the device can render two signal modes (e.g., audio and visual, or video or text) at the same time. Formally, the device must be considered as making its choice from the set of all combined signals that it can render (pairs of one signal from the first mode and one signal from the second mode), and that choice must conform to the above rules. However, it can be proven that if the device makes its rendering choice for each of the two modes independently, with each choice separately conforming to the above rules, its combined choice conforms to the above rules, when it is regarded as a choice from among all possible combinations. In such a situation, it may simplify implementation to make each choice separately. It is an implementation decision whether to chose from among combined signals, or to combine choices made from each signal mode. 9. Non-normative Algorithm for Handling Combinations of URNs The following text is a non-normative example of an algorithm for handling combinations of URNs that complies with the rules in Section 7 and Section 8. Thus, it demonstrates that the rules are consistent and implementable. (Of course, a device may use any other algorithm which complies with Section 7 and Section 8.) 9.1. Algorithm Description For each (feature) known by the implementation, there is a "feature tree" of the known s for that , with the sequence of s in an specifying the path in the tree from the root to the node representing the . For this description, we will name each tree and its root node by the name, and name each non-root node by the . Each URN thus corresponds to one non-root node in one feature tree. For example, there is a tree named "source", whose root node is also named "source", and which has the children source:internal, source: Liess, et al. Expires January 12, 2014 [Page 30] Internet-Draft Alert URNs July 2013 external, source:friend, and source:family. The URN is placed at the node "source:external" in the "source" tree. If the implementation understands , there is a node source:foo@example.com that is a child of node "source". If the implementation understands , there is a node source:external:bar@example.com that is a child of node source: external. (Of course, there are an infinite number of potential additional nodes in the tree for private values, but we don't have to represent those nodes explicitly unless the device has a signal representing the private value.) We assign similar locations to signals, but each signal has a position in *every* tree, describing the specific combination of meanings that it carries. If a signal has a simple meaning, such as "external source", its place in the "source" tree is source:external, showing that it carries the "external source" meaning, but its place in every other feature tree is at the root node, meaning that it has no particular meaning for those features. A signal that has a complex meaning may have non-root positions in more than one feature tree. For example, an "external, high priority" signal would be placed at source:external and priority:high in those trees, but be at the root in all other feature trees. In order to assure that the algorithm always selects at least one signal, we require that there is a "default" signal, whose position in every feature tree is at the root. This default signal will never be excluded from the set of acceptable signals for any set of URNs, but will be the lowest-priority signal for any set of URNs. The algorithm proceeds by considering each URN in the received Alert- Info header fields from left to right, while revising a set of signals. The set of signals starts as the entire set of signals available to the device. Each URN excludes some signals from the set, and *sorts* the signals that remain in the set according to how well they represent the URN. (The details of these operations are described below.) The first URN is the "major sort", and has the most influence on the position of a signal in the set. The second URN is a "minor sort", in that it arranges the orders of the signals that are tied within the first sort, the third URN arranges the orders of the signals that are tied within the first two sorts, etc. At the end of the algorithm, a final, "most minor" sort is done, which orders the signals which remain tied under all the sorts driven by the URNs. This final sort places the least specific signals (within their tied groups) *first*. (If one signal's position in Liess, et al. Expires January 12, 2014 [Page 31] Internet-Draft Alert URNs July 2013 each feature tree is ancestral or the same as a second signal's position in that tree, the first signal is "less specific" than the second signal. Other cases are left to the implementation to decide.) Once all the URNs are processed and the sorting of the signals that have not been excluded is done, the device selects the first signal in the set. Here is how a single sort step proceeds, examining a single URN to modify the set of signals (by excluding some signals and further sorting the signals that remain): o The URN specifies a specific node in a specific feature tree. o All signals in the set that are, within that feature tree, positioned at the URN's node, or at an ancestor node of the URN's node, are kept. All other signals are removed from the set (because they have meanings that are incompatible with the URN's meaning). o Each group of signals that are tied under the previous sorts are further sorted into groups based on how much of the URN's meaning they represent: those which are positioned at the node of the URN are tied for first position, those which are positioned at the parent node of the URN are tied for second position, etc., and those which are positioned at the root node of the feature tree are tied for last position. 9.2. Examples of how the algorithm works The following examples show how the algorithm described in the previous section works: 9.2.1. Example 1 The device has a set of 4 alerting signals. We list their primary meanings, and the locations that they are placed in the feature trees: Signal 1 Meaning: external Locations: - source:external - priority (that is, the root node of the priority tree) Signal 2 Liess, et al. Expires January 12, 2014 [Page 32] Internet-Draft Alert URNs July 2013 Meaning: internal Locations: - source:internal - priority Signal 3 Meaning: low Locations: - source - priority:low Signal 4 Meaning: high Locations: - source - priority:high To which we add: Signal 5 Meaning: default Locations: - source - priority If the device receives , then the sort is: Signals at source:internal: (this is, first place) urn:alert:source:internal Signals at source: (tied for second place) urn:alert:priority:low urn:alert:priority:high default And these signals are excluded from the set: urn:alert:source:external So in this example, the sorting algorithm properly gives first place to . Liess, et al. Expires January 12, 2014 [Page 33] Internet-Draft Alert URNs July 2013 9.2.2. Example 2 Let us add to the set of signals in Example 1 ones that express combinations like "internal, high priority", but let us specifically exclude the combination "internal, low priority" so as to set up some tricky examples. This enlarges our set of signals: Signal 1 Meaning: default Locations: - source - priority Signal 2 Meaning: external Locations: - source:external - priority Signal 3 Meaning: internal Locations: - source:internal - priority Signal 4 Meaning: low Locations: - source - priority:low Signal 5 Meaning: high Locations: - source - priority:high Signal 6 Meaning: external high Locations: Liess, et al. Expires January 12, 2014 [Page 34] Internet-Draft Alert URNs July 2013 - source:external - priority:high Signal 7 Meaning: external low Locations: - source:external - priority:low Signal 8 Meaning: internal high Locations: - source:internal - priority:high If the device receives , then the sort is: Signals at source:internal: (that is, tied for first place) - internal - internal high Signals at source: (tied for second place) - low - high - default Signals excluded from the set: - external - external low - external high Two signals are tied for the first place, but the final sort orders them: - internal - internal high because it puts the least-specific signal first. So the signal "internal" is chosen. Liess, et al. Expires January 12, 2014 [Page 35] Internet-Draft Alert URNs July 2013 9.2.3. Example 3 The same device receives , . The first sort (due to ) is: Signals at source:external: - external - external low - external high Signals at source: - low - high - default Signals excluded: - internal - internal high The second sort (due to ) puts signals at priority:low before signals at priority, and excludes signal at priority:high: - external low - external - low - default Excluded: - external high - high - internal - internal high So, we choose "external low". 9.2.4. Example 4 Suppose the same device receives , . Note that there is no signal that corresponds to this combination. The first sort is based on source:internal, and results in this Liess, et al. Expires January 12, 2014 [Page 36] Internet-Draft Alert URNs July 2013 order: - internal - internal high - low - high - default Excluded: - external - external low - external high The second sort is based on priority:low, and results in this order: - internal - low - default Excluded: - internal high - high - external low - external - external high So we choose the signal "internal". 9.2.5. Example 5 Let us set up a simple set of signals, with three signals giving priority: Signal 1 Meaning: default Locations: - priority Signal 2 Meaning: low Locations: - priority:low Signal 3 Liess, et al. Expires January 12, 2014 [Page 37] Internet-Draft Alert URNs July 2013 Meaning: high Locations: - priority:high Notice that we've used the "default" signal to cover "normal priority". That is so the signal will cover situations where no priority URN is present, as well as the ones with . So we're deliberately failing to distinguish "priority:normal" from the default priority. If the device receives , the sort is: - low - default Excluded: - high and signal "low" is chosen. Similarly, if the device receives , signal "high" is chosen. If the device receives , the sort is: - default Excluded: - low - high and signal "default" is chosen. If no "priority" URN is received, "default" will be put before "low" and "high" by the final sort, and so it will be chosen. 10. User Agent Behaviour A SIP UA MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service. Upon receiving a SIP INVITE request or a SIP provisional response with an Alert-Info header field that contains a combination of Alert- Liess, et al. Expires January 12, 2014 [Page 38] Internet-Draft Alert URNs July 2013 Info URNs, the User Agent (UA) attempts to match the received Alert- Info URNs combination with a signal it can render. The process the UA uses MUST conform to the rules described in Section 8. (A non- normative algorithm example for the process is described in Section 9.) The User Agent (UA) MUST produce a reasonable rendering regardless of the combination of URIs (of any schemes) in the Alert-Info header field. 11. Proxy Behaviour A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header field in a SIP request or a provisional 1xx response (excepting a 100 response) when it needs to provide additional information about the call or about the provided service. The following example shows a typical example of a 180 Ringing provisional response that has been modified by a proxy. The response sent by the UAS to the proxy was very similar, but had no Alert-Info header field. The proxy has added Alert-Info header field values specifying both a network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service. This allows the UAC to render the network audio resource, or to choose a rendering based on the URN, or to perform some combination of these actions. Due to section 10, the UAC must produce some reasonable rendering in this situation. SIP/2.0 180 Ringing Alert-Info: , To: Bob ;tag=a6c85cf From: Alice ;tag=1928301774 Call-ID: a84b4c76e66710 Contact: CSeq: 314159 INVITE Via: SIP/2.0/UDP server10.biloxi.example.com; branch=z9hG4bK4b43c2ff8.1 Content-Length: 0 12. Internationalization Considerations The labels are protocol elements [RFC6365] and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 6. Liess, et al. Expires January 12, 2014 [Page 39] Internet-Draft Alert URNs July 2013 The URNs > select renderings that are conventional in the specified country. Domain names that appear as parts of "alert" URNs can be internationalized, in that they can contain A-labels. 13. Security Considerations As an identifier, the alert URN does not appear to raise any particular security issues. The indications described by the "alert" URN are meant to be well-known. However, the provision of specific indications may raise privacy issues, e.g. indications about the source of the message or about services initiated at the other side. Such provision SHALL always be explicitly authorised by the party (caller or callee) the information in the "alert" URN refers to. Proxies may choose to suppress undesired indications, e.g. from untrusted sources, while allowing them from trusted sources. 14. Acknowledgements The authors wish to thank Denis Alexeitsev, the editor of the initial draft in BLISS, Anwar Siddiqui for his contributions to the draft, and Adam Roach, Dean Willis, Martin Huelsemann, Shida Schubert, John Elwell and Tom Taylor for their comments and suggestions. 15. References 15.1. Normative References [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 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. Liess, et al. Expires January 12, 2014 [Page 40] Internet-Draft Alert URNs July 2013 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. 15.2. Informative References [E182] "Application of tones and recorded announcements in telephone services", http://www.itu.int/rec/T-REC-E.182-199803-I/en . [I-D.ietf-bliss-shared-appearances] Johnston, A., Soroushnejad, M., and V. Venkataramanan, "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)", draft-ietf-bliss-shared-appearances-15 (work in progress), January 2013. [ISO3166-1] "ISO 3166-1 English country names and code elements", http ://www.iso.org/iso/ english_country_names_and_code_elements . [RFC3043] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001. [RFC3044] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001. [RFC3120] Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC 3120, June 2001. [RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001. [RFC3188] Hakala, J., "Using National Bibliography Numbers as Uniform Resource Names", RFC 3188, October 2001. [RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005. [RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as Liess, et al. Expires January 12, 2014 [Page 41] Internet-Draft Alert URNs July 2013 Uniform Resource Names (URN)", RFC 4179, October 2005. [RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005. [RFC4198] Tessman, D., "A Uniform Resource Name (URN) Namespace for Federated Content", RFC 4198, November 2005. [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in Internationalization in the IETF", BCP 166, RFC 6365, September 2011. [RFC6910] Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev, "Completion of Calls for the Session Initiation Protocol (SIP)", RFC 6910, April 2013. [TS24.615] "3GPP TS 24.615 Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem". Authors' Addresses Laura Liess (editor) Deutsche Telekom AG Heinrich-Hertz Str 3-7 Darmstadt, Hessen 64295 Germany Phone: +49 6151 5812761 Email: laura.liess.dt@gmail.com Liess, et al. Expires January 12, 2014 [Page 42] Internet-Draft Alert URNs July 2013 Roland Jesske Deutsche Telekom AG Heinrich-Hertz Str. 3-7 Darmstadt, Hessen 64295 Germany Phone: +49 6151 5812766 Email: r.jesske@telekom.de Alan Johnston Avaya Inc. St. Louis, MO United States Phone: Email: alan.b.johnston@gmail.com Dale R. Worley Ariadne Internet Services, Inc. 738 Main St. Waltham, MA 02451 US Phone: +1 781 647 9199 Email: worley@ariadne.com Paul Kyzivat Huawei United States Email: pkyzivat@alum.mit.edu Liess, et al. Expires January 12, 2014 [Page 43]