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.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Table of Contents

1.  Introduction
2.  Requirements
3.  Registration template
4.  Top Level Alert URN Indication Definitions
    4.1.  PBX Tones
        4.1.1.  normal
        4.1.2.  external
        4.1.3.  internal
    4.2.  Public telephone network tones
        4.2.1.  ringing
        4.2.2.  busy
        4.2.3.  intrusion
        4.2.4.  record
    4.3.  Service Tones
        4.3.1.  call-waiting
        4.3.2.  forward
        4.3.3.  transfer-recall
        4.3.4.  auto-callback
        4.3.5.  hold-recall
        4.3.6.  crisis
        4.3.7.  priority
        4.3.8.  short
        4.3.9.  delayed
    4.4.  National Variant Indications for public telephone network tones
    4.5.  Combinations of URNs
5.  User Agent Behavior
6.  Proxy Behavior
7.  IANA Considerations
    7.1.  New alert-identifiers
    7.2.  Alert-category
    7.3.  Initial IANA Registration
        7.3.1.  Indications for PBX-tones
        7.3.2.  Additional Indications for PBX-tones
        7.3.3.  Indications for for public telephone network tones
        7.3.4.  Indications for national variant public telephone network tones
        7.3.5.  Indications for "service" alert-indications
        7.3.6.  Combination Rule for Alert URN Indications
8.  Internationalization Considerations
9.  Security Considerations
10.  Acknowledgements
11.  References
    11.1.  Normative References
    11.2.  Informative References
Appendix A.  An Appendix
§  Authors' Addresses

1.  Introduction

The Session Initiation Protocol (SIP) [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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: <file://ring.pcm>;alert=normal where ring.pcm is a dummy file or: Alert-Info: <file://normal.ring.pcm> or: Alert-Info: <sip:normal-ringtone@example.com> 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:

• Names for services such as call waiting or automatic callback, not tied to any particular rendering.
• 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.
• Names for country-specific tones.
• 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:

• Do not need to download it or deal with security issues associated with dereferencing.
• No formatting or compatibility issues.
• No security risk of rendering something unexpected and undesirable.
• 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".
• It is easier to make policy decisions about whether to use it or not.
• 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.

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 (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.) [RFC3406]

Namespace ID:

alert

Registration Information:

Registration version:

1

Registration date:

TBD

Declared registrant of the namespace:

Registering organization:

IETF

Designated contact:

Laura Liess

Designated contact email:

l.liess@telekom.de

Declaration of syntactic structure:

The Namespace Specific String (NSS) for the "alert" URNs is called alert-identifier and has a hierarchical structure. The left-most 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] (Braden, R., “Requirements for Internet Hosts - Application and Support,” October 1989.). 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.

The ABNF [RFC4234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.) 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 (IANA Considerations). 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 (IANA Considerations)). 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 (IANA Considerations).

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 (IANA Considerations).

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] (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.). 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] (Johnston, A., Soroushnejad, M., and V. Venkataramanan, “Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR),” March 2010.), 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.

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] (, “ITU-T E.180/Q.35 Technical characteristics of tones for the telephone service,” .) and [E.182] (, “ITU-T E.182 Application of tones and recorded announcements in telephone services,” .). 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.

4.3.1.  call-waiting

The call waiting Service [TS24.615] (, “3GPP TS 24.615 Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem,” .) 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] (Sparks, R., Johnston, A., and D. Petrie, “Session Initiation Protocol (SIP) Call Control - Transfer,” June 2009.) 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 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] (, “ISO 3166-1 English country names and code elements,” .) 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: <urn:alert:tone:za>

The particular rendering for many country specific ringing and busy tones is described in [TR 101041] (, “ETSI TR 101 041 European harmonization of network generated tones Part 1 and Part 2,” .) :

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: <urn:alert:tone:internal>, <urn:alert:tone:priority>. A priority call waiting tone could be indicated by Alert-Info: <urn:alert:service:call-waiting>, <urn:alert:tone:priority>. And finally, a short Albanian auto-callback tone could be indicated Alert-Info: <urn:alert:service:auto-callback>, <urn:alert:tone:short>, <urn:alert:tone:al>.

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: <http://www.example.com/sound/moo.wav>,
    <urn:alert:service:call-waiting>

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] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” October 1998.) 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 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.

 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
    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
    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
    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
    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
    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] (Hoffman, P., “Terminology Used in Internationalization in the IETF,” May 2003.) 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 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

11.2. Informative References

Appendix A.  An Appendix

Authors' Addresses