DISPATCH D. Alexeitsev Internet-Draft L. Liess Intended status: Standards Track R. Jesske Expires: April 22, 2010 Deutsche Telekom AG A. Johnston A. Siddiqui Avaya October 19, 2009 Alert-Info URNs for the Session Initiation Protocol (SIP) draft-liess-dispatch-alert-info-urns-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 22, 2010. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Alexeitsev, et al. Expires April 22, 2010 [Page 1] Internet-Draft Alert-Info URNs October 2009 Abstract The Session Initiation Protocol (SIP) supports the capability to provide a reference to the alternative ringback tone (RBT) for caller, or ring tone (RT) for callee using the Alert-Info header. However, the reference addresses only the network resources with specific rendering properties. There is currently no support for predefined standard identifiers for ringback tones or semantic indications without tied rendering. To overcome this limitations and support new applications a family of the URNs is defined in this specification. 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]. Alexeitsev, et al. Expires April 22, 2010 [Page 2] Internet-Draft Alert-Info URNs October 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Registration template . . . . . . . . . . . . . . . . . . . . 7 4. Top Level Alert URN Indication Definitions . . . . . . . . . . 10 4.1. PBX Tones . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. normal . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2. external . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. internal . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Public telephone network tones . . . . . . . . . . . . . . 11 4.2.1. ringing . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.2. busy . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.3. intrusion . . . . . . . . . . . . . . . . . . . . . . 11 4.2.4. record . . . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Service Tones . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. call-waiting . . . . . . . . . . . . . . . . . . . . . 12 4.3.2. forward . . . . . . . . . . . . . . . . . . . . . . . 12 4.3.3. transfer-recall . . . . . . . . . . . . . . . . . . . 12 4.3.4. auto-callback . . . . . . . . . . . . . . . . . . . . 12 4.3.5. hold-recall . . . . . . . . . . . . . . . . . . . . . 12 4.3.6. crisis . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.7. priority . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.8. short . . . . . . . . . . . . . . . . . . . . . . . . 13 4.3.9. delayed . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. National Variant Indications for public telephone network tones . . . . . . . . . . . . . . . . . . . . . . 13 4.5. Combinations of URNs . . . . . . . . . . . . . . . . . . . 14 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 14 6. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7.1. New alert-identifiers . . . . . . . . . . . . . . . . . . 15 7.2. Alert-category . . . . . . . . . . . . . . . . . . . . . . 15 7.3. Initial IANA Registration . . . . . . . . . . . . . . . . 16 7.3.1. Indications for PBX-tones . . . . . . . . . . . . . . 16 7.3.2. Additional Indications for PBX-tones . . . . . . . . . 16 7.3.3. Indications for for public telephone network tones . . 16 7.3.4. Indications for national variant public telephone network tones . . . . . . . . . . . . . . . . . . . . 16 7.3.5. Indications for "service" alert-indications . . . . . 22 7.3.6. Combination Rule for Alert URN Indications . . . . . . 22 8. Internationalization Considerations . . . . . . . . . . . . . 22 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. An Appendix . . . . . . . . . . . . . . . . . . . . . 24 Alexeitsev, et al. Expires April 22, 2010 [Page 3] Internet-Draft Alert-Info URNs October 2009 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Alexeitsev, et al. Expires April 22, 2010 [Page 4] Internet-Draft Alert-Info URNs October 2009 1. Introduction The Session Initiation Protocol (SIP) [RFC3261] allows for user agent servers (UAS) and proxies to provide the specific ringback or ring tone to the user agent (UA). In RFC 3261 this is done by including a URI reference in the Alert-Info header field, that points to the tone. The URI reference is most commonly the HTTP URI to the audio file. On the receipt of the Alert-Info header the user agent may fetch the referenced ringback or ring tone and play it to the user. This mechanism does not ensure interoperability when there is no common understanding of the referenced content (different countries or vendors, hearing impaired) or when the user wants his own tones configured in the end device. If caller and callee are from the 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 ringtone 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 proxy and UA, as only then is the same "fake" proprietary URI convention is used. Another limitation of the current solution is that the referenced tones are tied to particular rendering. It is not possible to provide a semantic indication 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 that can be understood by an automaton, would allow for programmatic handling including user interface adaptation, or conversion to equivalent protocol parameters 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. Using 'alert' namespace provides syntax for several different application spaces: Alexeitsev, et al. Expires April 22, 2010 [Page 5] Internet-Draft Alert-Info URNs October 2009 o Names for services such as call waiting or automatic callback, not tied to any particular rendering. o Names for common ring-tones generated by PBX phone for cases such as an internal enterprise caller, external caller, ringback after a transfer failure or expiration of a hold timer, etc. o Names for country-specific 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 URI reference to 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 or ring-tone. To provide the general awareness about the Alert-Info URNs this document provides IANA template for registering the URNs and defines several typical identifiers. 2. Requirements This section discusses the requirements for an identifier to transport the semantic of a specific ring or ringback tone. REQ-1: The mechanism will allow user agents (UAs) and proxies to o provide a semantic indication in the Alert-Info SIP-header that signals the intent of the rendering and allows the recipient to decide how to render the received information. Alexeitsev, et al. Expires April 22, 2010 [Page 6] Internet-Draft Alert-Info URNs October 2009 REQ-2: The mechanism will allow to ensure interoperability for services as call waiting, forward, call forwarding, transfer-recall, auto-callback, hold-recall, crisis. REQ-3: The mechanism will allow to render common PBX ring tone types. REQ-4: The mechanism will allow to render specific country ring- and busy-tones. REQ-5: The mechanism will allow to render tones for emergency alerts. REQ-6: The mechanism will allow rendering using other means than tones, e.g. text or images. REQ-7: The mechanism will allow rendering to be semantic, not biased towards a a particular representation which might not be suitable for all devices or users. REQ-7: The mechanism will allow to store the actual encoding locally rather than fetching it. REQ-9: The mechanism will allow the identifier to be specified "by name" rather than "by value", to enable local policy decisions whether to use it or not . REQ-10: The mechanism will be flexible and can be used for use cases not described in this specification . REQ-11: The mechanism will allow transmission in SIP requests and responses. 3. Registration template Below is the registration template for the 'alert' URN scheme according to the RFC 3406 [RFC3406] Namespace ID: alert Registration Information: Registration version: 1 Registration date: TBD Alexeitsev, et al. Expires April 22, 2010 [Page 7] Internet-Draft Alert-Info URNs October 2009 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 label is called "alert-category" and is separated from right-side of the alert-identifier, the alert-indication, by a semicolon. In this specification, two categories of alert-identifiers are described: the "tone" alert-identifiers and the "service" alert- identifiers. The "tone" alert-identifier has the general form: urn:alert:tone:{tone-indication} where the tone-indication identifies the semantic of a tone. The "service" alert-identifier has the general form: urn:alert:service:{service-indication} where the service-indication is a unique identifier for a service as call-waiting or transfer-recall. The tone-indication and service-indication are hierarchical identifiers, consisting of one label or a sequence of labels separated by periods. The left-most label is the most significant one and is called 'top-level indication' , while names to the right are called 'sub-indication'. The set of allowable characters is the same as that for domain names [RFC1123]. Labels are case-insensitive, but MUST be specified in all lower-case. Labels can be removed right-to-left excepting the left-most label; the resulting tone-indication or service-indication is still valid, referring to a more generic tone-indication or service- indication. In other words, if a tone 'x.y.z' exists, the tones 'x' and 'x.y' are also valid tones. Each alert indication identifier SHALL explicitly define it's validity respective the sub-indications. Alexeitsev, et al. Expires April 22, 2010 [Page 8] Internet-Draft Alert-Info URNs October 2009 The ABNF [RFC4234] for the "tone" and "service" alert URNs is shown below: alert-URN = "URN:alert:" alert-identifier alert-identifier= alert-category ":" alert-indication alert-category = "tone"/" "service" alert-indication= top-level *("." sub-indication) top-level = let-dig [ *25let-dig-hyp let-dig ] sub-indication = let-dig [ *let-dig-hyp let-dig ] let-dig-hyp = let-dig / "-" let-dig = ALPHA / DIGIT ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 Relevant ancillary documentation: None Community considerations: The alert URN is believed to be relevant to a large cross-section of Internet users, including both technical and non-technical users, on a variety of devices and with a variety of perception capabilities. The 'alert' URN will allow Internet users to receive more information and enable them to better make decisions about accepting an offered call, or get better feedback on the progress of a call they have made. User interfaces for the perception impaired users can better render the ringback indication based on the 'alert' URN. The assignment of identifiers is described in Section 7. The 'alert' URN does not prescribe a particular resolution mechanism, but it is assumed that a number of different entities could operate and offer such mechanisms. Namespace considerations: There do not appear to be other URN namespaces that serve the same need of uniquely identifying 'alert' communication and information services. Identifier uniqueness considerations: An 'alert' URN identifies a logical service or tone, specified in the 'alert' indication registration (see Section 7). Resolution of the registered URN will return a particular instance of the alert identifier. Alert identifier URNs MUST be unique for each unique indication; this is guaranteed through the registration of each alert indication within this namespace, described in Section 7. Alexeitsev, et al. Expires April 22, 2010 [Page 9] Internet-Draft Alert-Info URNs October 2009 Identifier persistence considerations: The 'alert' URN for the same indication is expected to be persistent, as long as it is registered with IANA. Process of identifier assignment: The process of identifier assignment is described in Section 7. Process for identifier resolution: 'alert' URNs are statically resolved according to the IANA registry. Rules for lexical equivalence: 'alert' URNs are compared according to case-insensitive string equality. Conformance with URN syntax: The BNF in the 'Declaration of syntactic structure' above constrains the syntax for this URN scheme. Validation mechanism: Validation determines whether a given string is currently a validly-assigned URN [RFC3406]. Static validation is performed based on the currently registered 'alert' URNs at IANA. Scope: The scope for this URN is public and global. 4. Top Level Alert URN Indication Definitions This section describes the use cases that are supported by the 'alert' URNs. 4.1. PBX Tones This section defines some commonly encountered ring-tones on PBX or business phones. They are as follows: 4.1.1. normal This tone indicates that the default or normal ring-tone should be rendered. 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 ringtone need be specified. If no special alerting is to be used, urn:alert:tone:normal should be used. Alexeitsev, et al. Expires April 22, 2010 [Page 10] Internet-Draft Alert-Info URNs October 2009 4.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. For this case, urn:alert:tone:external should be used. 4.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. For this case, the urn:alert:tone:internal should be used. 4.2. Public telephone network tones This section defines some commonly encountered tones in the public telephone service, according to the [E.180] and [E.182]. They are as follows. 4.2.1. ringing This tone indicates that the default or normal ring-tone should be rendered. For this case, urn:alert:tone:ringing should be used. 4.2.2. busy This tone indicates that a tone should be rendered that indicates to the caller that the callee is busy. For this case, urn:alert:tone:busy should be used. 4.2.3. intrusion This tone indicates that a tone should be rendered that indicates to the participants in a call that the privacy of the conversation has been breached. For this case, urn:alert:tone:intrusion should be used. 4.2.4. record This tone indicates that a tone should be rendered which advises the caller when to begin a message which will be recorded. For this case, urn:alert:tone:record should be used. 4.3. Service Tones These tones are used to indicate specific PBX and telephony services. Alexeitsev, et al. Expires April 22, 2010 [Page 11] Internet-Draft Alert-Info URNs October 2009 4.3.1. call-waiting The call waiting Service [TS24.615] permits a callee to be notified of an incoming call whilst the media resources are not available for the incoming call and 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 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 URN to the Alert-Info header. 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 user. The urn:alert:service:call-waiting should be used for this case. 4.3.2. forward This feature is used in a 180 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. The urn:alert:service:forward should be used for this case. Note that a 181 response can be used in place of this URN. 4.3.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. The urn:alert:service:transfer-recall should be used for this case. 4.3.4. auto-callback This feature is used when a user has utilized a server to implement an automatic callback service. 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. The urn:alert:service:auto-callback should be used for this case. 4.3.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 Alexeitsev, et al. Expires April 22, 2010 [Page 12] Internet-Draft Alert-Info URNs October 2009 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. The urn:alert:service:hold-recall should be used for this case. 4.3.6. crisis This feature is used for emergency announcements sent over PBX systems such as building evacuations, alarms, etc. This service tone is used to distinguish this case from any other normal incoming call. The urn:alert:service:crisis should be used for this case. 4.3.7. priority This sub-level is used to indicate that a priority level alert should be applied for the type of alerting specified. For example, urn:alert:tone:priority would be used to generate priority alerting. 4.3.8. short This sub-level is used to indicate that the alert type specified should be rendered shorter than normal. In contact centers, this is sometimes referred to as "abbreviated ringing" or a "zip tone". For example, urn:alert:tone:short would generate a shorter than normal ring-tone. 4.3.9. delayed This sub-level is used to indicate that the alerting type specified show 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. For example, urn:alert:tone:delayed would generate an external ring-tone, delayed by a few seconds. 4.4. National Variant Indications for public telephone network tones In the PSTN, different tones are used in different countries. End users are accustomed to hear the callee's country ringing or busy tone. The ISO 3166-1 country code [ISO 3166-1] is used as a top-level to indicate which country specific tone should be rendered. For example, to indicate tones from South Africa, the following URN would be used: The particular rendering for many country specific ringing and busy Alexeitsev, et al. Expires April 22, 2010 [Page 13] Internet-Draft Alert-Info URNs October 2009 tones is described in [TR 101041] : 4.5. Combinations of URNs In some cases, more than one URN will need to be specified to fully define a particular tone. This is done by including multiple URNs. For example, an internal, priority call could be indicated by Alert- Info: , . A priority call waiting tone could be indicated by Alert-Info: , . And finally, a short Albanian auto-callback tone could be indicated Alert-Info: , , . 5. User Agent Behavior Upon receiving a SIP request or a SIP 180 Ringing response with an Alert-Info header that contains a single or multiple 'alert' URNs, the User Agent (UA) attempts to match the received URNs with the known indications. If no match is found, the User Agent (UA) ignores the received 'alert' URNs and proceeds with the normal operation. If the one or multiple URNs matches a known indication, the User Agent (UA) renders the indication(s) to the user according to the tone or service identifier in the received alert URN. The User Agent (UA) is responsible for the non disturbing rendering if multiple indications and network resources are to be rendered simultaneously. 6. Proxy Behavior A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header in a SIP request or a 180 Ringing provisional response when it needs to provide additional information about the call or about the provided service. A SIP Proxy SHOULD NOT add a mixture of the 'alert' URNs and URIs to the Alert-Info header that may cause disturbing rendering interference at the recepient's User Agent (UA). Following example shows both the network audio resource referenced by the HTTP URI and the URN indication for the call-waiting service transported by the Alert-Info header in a 180 Ringing provisional response. Alert-Info: , Alexeitsev, et al. Expires April 22, 2010 [Page 14] Internet-Draft Alert-Info URNs October 2009 7. IANA Considerations This section registers a new URN scheme with the registration template provided in section Registration Template. Below, the section 7.1 details how to register new alert-identifiers. Descriptions of alert-indications for the first two alert-identifiers described in this document , service and tone, are given in Section 7.2 and Section 7.3, respectively. Finally, Section 7.4 contains the initial registration table. 7.1. New alert-identifiers Alert URNs are identified by labels managed by IANA, according to the processes outlined in [RFC2434] in a new registry called "Alert URN Labels". Thus, creating a new alert-identifier requires IANA action. The policy for adding a new alert-identifier category is 'Standards Action'. (This document defines the alert-identifier categories 'service' and 'tone'.) The policy for assigning labels to alert top- level indications or sub-indications and the rules to combine top- level indications and sub-indications may differ for each alert- identifier category and MUST be defined by the document describing the coresponding alert indications. The entries in the registration table have the following format: Category/ Reference Description Top-Indication/ Sub-Indication -------------------------------------------------------------------- foo RFC XXXX Description of the 'foo' alert-category bar RFC YYYY Description of the 'bar' alert-indication of the foo alert-category Each alert-category or alert-indication label MUST NOT exceed 27 characters. 7.2. Alert-category This section defines the alert-identifier registration within the IANA registry defined in Section 7.1, using the alert-category labels 'service' and 'tone'. The 'tone' alert-category label provides information about ringing tones generated by a UAS and rendered to the callee in response to an INVITE. The 'service' alert-category label describes tones that should be generated by the UAC or UAS and rendered to the caller or calee upon Alexeitsev, et al. Expires April 22, 2010 [Page 15] Internet-Draft Alert-Info URNs October 2009 receipt of a 180 response or a request. The normal rendering is audio, however there can be other renderings applicable if needed by the user interface specifics. 7.3. Initial IANA Registration 7.3.1. Indications for PBX-tones The following table contains the initial IANA registration for "tone" top-level alert URN indications for PBX-tones. Top-level Indication Reference Description -------------------------------------------------------- normal RFC XXXX Normal ring-tone internal RFC XXXX Internal PBX caller PBX ring-tone external RFC XXXX External PBX caller PBX ring-tone 7.3.2. Additional Indications for PBX-tones The following table contains the initial IANA registration for "tone" top-level alert URN indications for PBX-tones. Top-level Indication Reference Description -------------------------------------------------------- priority RFC XXXX Priority ring-tone short RFC XXXX Short ring-tone delayed RFC XXXX Delayed ring-tone 7.3.3. Indications for for public telephone network tones The following table contains the initial IANA registration for "tone" top-level alert URN indications for public telephone network tones. Top-level Indication Reference Description -------------------------------------------------------- ringing RFC XXXX Normal ring-tone busy RFC XXXX Busy tone intrusion RFC XXXX Privacy of the conversation has been breached record RFC XXXX Recording begin 7.3.4. Indications for national variant public telephone network tones The following list contains the initial IANA registration for alert URN indications for national variant public telephone network tones. Alexeitsev, et al. Expires April 22, 2010 [Page 16] Internet-Draft Alert-Info URNs October 2009 Top-level Indication Reference Description -------------------------------------------------------- af RFC XXXX AFGHANISTAN ax RFC XXXX ALAND ISLANDS al RFC XXXX ALBANIA dz RFC XXXX ALGERIA as RFC XXXX AMERICAN SAMOA ad RFC XXXX ANDORRA ao RFC XXXX ANGOLA ai RFC XXXX ANGUILLA aq RFC XXXX ANTARCTICA ag RFC XXXX ANTIGUA AND BARBUDA ar RFC XXXX ARGENTINA am RFC XXXX ARMENIA aw RFC XXXX ARUBA au RFC XXXX AUSTRALIA at RFC XXXX AUSTRIA az RFC XXXX AZERBAIJAN bs RFC XXXX BAHAMAS bh RFC XXXX BAHRAIN bd RFC XXXX BANGLADESH bb RFC XXXX BARBADOS by RFC XXXX BELARUS be RFC XXXX BELGIUM bz RFC XXXX BELIZE by RFC XXXX BENIN bm RFC XXXX BERMUDA bt RFC XXXX BHUTAN bo RFC XXXX BOLIVIA, PLURINATIONAL STATE OF ba RFC XXXX BOSNIA AND HERZEGOVINA bw RFC XXXX BOTSWANA bv RFC XXXX BOUVET ISLAND br RFC XXXX BRAZIL io RFC XXXX BRITISH INDIAN OCEAN TERRITORY bn RFC XXXX BRUNEI DARUSSALAM bg RFC XXXX BULGARIA bf RFC XXXX BURKINA FASO bi RFC XXXX BURUNDI kh RFC XXXX CAMBODIA cm RFC XXXX CAMEROON ca RFC XXXX CANADA cv RFC XXXX CAPE VERDE ky RFC XXXX CAYMAN ISLANDS cf RFC XXXX CENTRAL AFRICAN REPUBLIC td RFC XXXX CHAD cl RFC XXXX CHILE cn RFC XXXX CHINA cx RFC XXXX CHRISTMAS ISLAND Alexeitsev, et al. Expires April 22, 2010 [Page 17] Internet-Draft Alert-Info URNs October 2009 cc RFC XXXX COCOS (KEELING) ISLANDS co RFC XXXX COLOMBIA km RFC XXXX COMOROS cg RFC XXXX CONGO cd RFC XXXX CONGO, THE DEMOCRATIC REPUBLIC OF THE ck RFC XXXX COOK ISLANDS cr RFC XXXX COSTA RICA ci RFC XXXX COTE D'IVOIRE hr RFC XXXX CROATIA cu RFC XXXX CUBA cy RFC XXXX CYPRUS cz RFC XXXX CZECH REPUBLIC dk RFC XXXX DENMARK dj RFC XXXX DJIBOUTI dm RFC XXXX DOMINICA do RFC XXXX DOMINICAN REPUBLIC ec RFC XXXX ECUADOR eg RFC XXXX EGYPT sv RFC XXXX EL SALVADOR gq RFC XXXX EQUATORIAL GUINEA er RFC XXXX ERITREA ee RFC XXXX ESTONIA et RFC XXXX ETHIOPIA fk RFC XXXX FALKLAND ISLANDS (MALVINAS) fo RFC XXXX FAROE ISLANDS fj RFC XXXX FIJI fi RFC XXXX FINLAND fr RFC XXXX FRANCE gf RFC XXXX FRENCH GUIANA pf RFC XXXX FRENCH POLYNESIA tf RFC XXXX FRENCH SOUTHERN TERRITORIES ga RFC XXXX GABON gm RFC XXXX GAMBIA ge RFC XXXX GEORGIA de RFC XXXX GERMANY gh RFC XXXX GHANA gi RFC XXXX GIBRALTAR gr RFC XXXX GREECE gl RFC XXXX GREENLAND gd RFC XXXX GRENADA gp RFC XXXX GUADELOUPE gu RFC XXXX GUAM gt RFC XXXX GUATEMALA gg RFC XXXX GUERNSEY gn RFC XXXX GUINEA gw RFC XXXX GUINEA-BISSAU gy RFC XXXX GUYANA ht RFC XXXX HAITI Alexeitsev, et al. Expires April 22, 2010 [Page 18] Internet-Draft Alert-Info URNs October 2009 hm RFC XXXX HEARD ISLAND AND MCDONALD ISLANDS va RFC XXXX HOLY SEE (VATICAN CITY STATE) hn RFC XXXX HONDURAS hk RFC XXXX HONG KONG hu RFC XXXX HUNGARY is RFC XXXX ICELAND in RFC XXXX INDIA id RFC XXXX INDONESIA ir RFC XXXX IRAN, ISLAMIC REPUBLIC OF iq RFC XXXX IRAQ ie RFC XXXX IRELAND im RFC XXXX ISLE OF MAN il RFC XXXX ISRAEL it RFC XXXX ITALY jm RFC XXXX JAMAICA jp RFC XXXX JAPAN je RFC XXXX JERSEY jo RFC XXXX JORDAN kz RFC XXXX KAZAKHSTAN ke RFC XXXX KENYA ki RFC XXXX KIRIBATI kp RFC XXXX KOREA, DEMOCRATIC PEOPLE'S REPUBLIC OF kr RFC XXXX KOREA, REPUBLIC OF kw RFC XXXX KUWAIT kg RFC XXXX KYRGYZSTAN la RFC XXXX LAO PEOPLE'S DEMOCRATIC REPUBLIC lv RFC XXXX LATVIA lb RFC XXXX LEBANON ls RFC XXXX LESOTHO lr RFC XXXX LIBERIA ly RFC XXXX LIBYAN ARAB JAMAHIRIYA li RFC XXXX LIECHTENSTEIN lt RFC XXXX LITHUANIA lu RFC XXXX LUXEMBOURG mo RFC XXXX MACAO mk RFC XXXX MACEDONIA, THE FORMER YUGOSLAV REPUBLIC OF mg RFC XXXX MADAGASCAR mw RFC XXXX MALAWI my RFC XXXX MALAYSIA mv RFC XXXX MALDIVES ml RFC XXXX MALI mt RFC XXXX MALTA mh RFC XXXX MARSHALL ISLANDS mq RFC XXXX MARTINIQUE mr RFC XXXX MAURITANIA mu RFC XXXX MAURITIUS yt RFC XXXX MAYOTTE mx RFC XXXX MEXICO Alexeitsev, et al. Expires April 22, 2010 [Page 19] Internet-Draft Alert-Info URNs October 2009 fm RFC XXXX MICRONESIA, FEDERATED STATES OF md RFC XXXX MOLDOVA, REPUBLIC OF mc RFC XXXX MONACO mn RFC XXXX MONGOLIA me RFC XXXX MONTENEGRO ms RFC XXXX MONTSERRAT ma RFC XXXX MOROCCO mz RFC XXXX MOZAMBIQUE mm RFC XXXX MYANMAR na RFC XXXX NAMIBIA nr RFC XXXX NAURU np RFC XXXX NEPAL nl RFC XXXX NETHERLANDS an RFC XXXX NETHERLANDS ANTILLES nc RFC XXXX NEW CALEDONIA nz RFC XXXX NEW ZEALAND ni RFC XXXX NICARAGUA ne RFC XXXX NIGER ng RFC XXXX NIGERIA nu RFC XXXX NIUE nf RFC XXXX NORFOLK ISLAND mp RFC XXXX NORTHERN MARIANA ISLANDS no RFC XXXX NORWAY om RFC XXXX OMAN pk RFC XXXX PAKISTAN pw RFC XXXX PALAU ps RFC XXXX PALESTINIAN TERRITORY, OCCUPIED pa RFC XXXX PANAMA pg RFC XXXX PAPUA NEW GUINEA py RFC XXXX PARAGUAY pe RFC XXXX PERU ph RFC XXXX PHILIPPINES pn RFC XXXX PITCAIRN pl RFC XXXX POLAND pt RFC XXXX PORTUGAL pr RFC XXXX PUERTO RICO qa RFC XXXX QATAR re RFC XXXX REUNION ro RFC XXXX ROMANIA ru RFC XXXX RUSSIAN FEDERATION rw RFC XXXX RWANDA bl RFC XXXX SAINT BARTH?LEMY sh RFC XXXX SAINT HELENA kn RFC XXXX SAINT KITTS AND NEVIS lc RFC XXXX SAINT LUCIA mf RFC XXXX SAINT MARTIN pm RFC XXXX SAINT PIERRE AND MIQUELON vc RFC XXXX SAINT VINCENT AND THE GRENADINES Alexeitsev, et al. Expires April 22, 2010 [Page 20] Internet-Draft Alert-Info URNs October 2009 ws RFC XXXX SAMOA sm RFC XXXX SAN MARINO st RFC XXXX SAO TOME AND PRINCIPE sa RFC XXXX SAUDI ARABIA sn RFC XXXX SENEGAL rs RFC XXXX SERBIA sc RFC XXXX SEYCHELLES sl RFC XXXX SIERRA LEONE sg RFC XXXX SINGAPORE sk RFC XXXX SLOVAKIA si RFC XXXX SLOVENIA sb RFC XXXX SOLOMON ISLANDS so RFC XXXX SOMALIA za RFC XXXX SOUTH AFRICA gs RFC XXXX SOUTH GEORGIA AND THE SOUTH SANDWICH ISLANDS es RFC XXXX SPAIN lk RFC XXXX SRI LANKA sd RFC XXXX SUDAN sr RFC XXXX SURINAME sj RFC XXXX SVALBARD AND JAN MAYEN sz RFC XXXX SWAZILAND se RFC XXXX SWEDEN ch RFC XXXX SWITZERLAND sy RFC XXXX SYRIAN ARAB REPUBLIC tw RFC XXXX TAIWAN, PROVINCE OF CHINA tj RFC XXXX TAJIKISTAN tz RFC XXXX TANZANIA, UNITED REPUBLIC OF th RFC XXXX THAILAND tl RFC XXXX TIMOR-LESTE tg RFC XXXX TOGO tk RFC XXXX TOKELAU to RFC XXXX TONGA tt RFC XXXX TRINIDAD AND TOBAGO tn RFC XXXX TUNISIA tr RFC XXXX TURKEY tm RFC XXXX TURKMENISTAN tc RFC XXXX TURKS AND CAICOS ISLANDS tv RFC XXXX TUVALU ug RFC XXXX UGANDA ua RFC XXXX UKRAINE ae RFC XXXX UNITED ARAB EMIRATES gb RFC XXXX UNITED KINGDOM us RFC XXXX UNITED STATES um RFC XXXX UNITED STATES MINOR OUTLYING ISLANDS uy RFC XXXX URUGUAY uz RFC XXXX UZBEKISTAN vu RFC XXXX VANUATU va RFC XXXX VATICAN CITY STATE Alexeitsev, et al. Expires April 22, 2010 [Page 21] Internet-Draft Alert-Info URNs October 2009 ve RFC XXXX VENEZUELA, BOLIVARIAN REPUBLIC OF vn RFC XXXX VIET NAM vg RFC XXXX VIRGIN ISLANDS, BRITISH vi RFC XXXX VIRGIN ISLANDS, U.S. wf RFC XXXX WALLIS AND FUTUNA eh RFC XXXX WESTERN SAHARA ye RFC XXXX YEMEN zm RFC XXXX ZAMBIA zw RFC XXXX ZIMBABWE 7.3.5. Indications for "service" alert-indications The following table contains the initial IANA registration for "service" alert-indications. Top-level Indication Reference Description -------------------------------------------------------- call-waiting RFC XXXX Call waiting service indication forward RFC XXXX Call forwarding service indication transfer-recall RFC XXXX Transfer Recall service indication auto-callback RFC XXXX Auto Callback service indication hold-recall RFC XXXX Hold Recall service indication crisis RFC XXXX Crisis alerting indication Editor's Note: RFC XXXX should be replaced with this specification. 7.3.6. Combination Rule for Alert URN Indications Alert URN Indications from the same group should not be combined. 8. Internationalization Considerations The alert-identifier labels are protocol elements [RFC3536] and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 6. 9. 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, so privacy considerations do not apply to the URN. Provision of the specific indications from callee to caller may raise privacy issues. Such provision SHALL always be explicitly authorised Alexeitsev, et al. Expires April 22, 2010 [Page 22] Internet-Draft Alert-Info URNs October 2009 by the callee. 10. Acknowledgements The draft is based on the ideas expressed by Paul Kyzivat on the BLISS WG mailing list. The authors wish to thank Dean Willis, Adam Roach, Paul Kyzivat, Martin Huelsemann, Shida Schubert, John Elwell and Tom Taylor for their comments and suggestions. 11. References 11.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. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. 11.2. Informative References [E.180] "ITU-T E.180/Q.35 Technical characteristics of tones for the telephone service", http://www.itu.int/rec/T-REC-E.180-199803-I/en . [E.182] "ITU-T E.182 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) Alexeitsev, et al. Expires April 22, 2010 [Page 23] Internet-Draft Alert-Info URNs October 2009 Address of Record (AOR)", draft-ietf-bliss-shared-appearances-03 (work in progress), July 2009. [ISO 3166-1] "ISO 3166-1 English country names and code elements", http ://www.iso.org/iso/ english_country_names_and_code_elements . [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003. [RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session Initiation Protocol (SIP) Call Control - Transfer", BCP 149, RFC 5589, June 2009. [TR 101041] "ETSI TR 101 041 European harmonization of network generated tones Part 1 and Part 2". [TS24.615] "3GPP TS 24.615 Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem". Appendix A. An Appendix Authors' Addresses Denis Alexeitsev Deutsche Telekom AG Friedrich-Ebert-Allee Bonn 53113 Germany Phone: +49-228-18112010 Email: d.alexeitsev@telekom.de Alexeitsev, et al. Expires April 22, 2010 [Page 24] Internet-Draft Alert-Info URNs October 2009 Laura Liess Deutsche Telekom AG Heinrich-Hertz Str 3-7 Darmstadt, Hessen 64295 Germany Phone: +49-6151-6282761 Email: l.liess@telekom.de Roland Jesske Deutsche Telekom AG Heinrich-Hertz Str 3-7 Darmstadt, Hessen 64295 Germany Phone: +49-6151-6282766 Email: r.jesske@telekom.de Alan Johnston Avaya St. Louis, MO United States Phone: Email: alan@sipstation.com Anwar Siddiqui Avaya Milpitas, CA United States Phone: Email: anwars@avaya.com Alexeitsev, et al. Expires April 22, 2010 [Page 25]