Alert-Info URNs for the Session Initiation Protocol (SIP)
draft-ietf-salud-alert-info-urns-00

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. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification.

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

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

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 June 13, 2011.

Copyright Notice

Copyright (c) 2010 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.

Table of Contents

1.  Introduction
    1.1.  Motivation
    1.2.  Alert-Info Header Usage Change
    1.3.  Terminology
2.  Requirements
3.  Use Cases
    3.1.  PBX Ring Tones
        3.1.1.  normal
        3.1.2.  external
        3.1.3.  internal
        3.1.4.  priority
        3.1.5.  short
        3.1.6.  delayed
    3.2.  Service Tones
        3.2.1.  call-waiting
        3.2.2.  forward
        3.2.3.  transfer-recall
        3.2.4.  auto-callback
        3.2.5.  hold-recall
    3.3.  Country-specific ringback tone indications for the public telephone network
4.  Namespace Registration Template
5.  Alert-Info URN Values Definitions
    5.1.  Alert-category Values Definitions
    5.2.  Alert-indication Values Definitions
        5.2.1.  Alert-Info URN Indication Values for the alert-category 'service'
        5.2.2.  Alert-Info URN Indication Values for the alert-category 'source'
        5.2.3.  Alert-Info URN Indication Values for the alert-category 'priority'
        5.2.4.  Alert-Info URN Indication Values for the alert-category 'duration'
        5.2.5.  Alert-Info URN Indication Values for the alert-category 'delay'
        5.2.6.  Alert-Info URN Indication Values for the alert-category 'locale'
6.  Extensibility Rules
    6.1.  General Extensibility Rules
    6.2.  Extensions Rules for Independent Organizations
7.  Combinations of URNs
8.  Priority Rules within Combinations of URNs
9.  User Agent Behaviour
10.  Proxy Behaviour
11.  IANA Considerations
    11.1.  New alert identifiers
    11.2.  Initial IANA Registration
        11.2.1.  The "service" alert-category and alert-identifiers
        11.2.2.  The "source" alert-category and alert-identifiers
        11.2.3.  The "priority" alert-category and alert-identifiers
        11.2.4.  The "duration" alert-category and alert-identifiers
        11.2.5.  The "delay" alert-category and alert-identifiers
        11.2.6.  The "locale" alert-category and alert-identifiers
12.  Internationalization Considerations
13.  Security Considerations
14.  Acknowledgements
15.  References
    15.1.  Normative References
    15.2.  Informative References
§  Authors' Addresses

1.  Introduction

1.1.  Motivation

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 [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) 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 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: <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 used.

Another limitation of the current solution is that the referenced tones are tied to particular rendering. It is not possible to provide semantic indications or names for rendering characteristics that signals the intent and allows the recipient to decide how to render the received information in an appropriate way.

To solve the described issues, this specification defines the new URN namespace 'alert' for the Alert-Info header that allows for programmatic user interface adaptation and for conversion of equivalent alerting tones in the Public Switched Telephone Network (PSTN) when the client is a gateway. The work to standardize an Alert-Info URN will increase SIP interoperability for this header field by replacing proprietary conventions used today.

Using the 'alert' namespace provides syntax for several different application spaces, e. g.:

• Names for service indications, such as call waiting or automatic callback, not tied to any particular rendering.
• Names for common ring tones generated by PBX phones 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 ringback 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.

1.2.  Alert-Info Header Usage Change

This specification changes the usage of the SIP Alert-Info header defined in the [RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.). The Alert-Info header can be used in INVITE requests and in provisional 1xx responses excepting the 100 response. Backward compatibility issues are not expected, devices that do not understand an Alert-Info URN ignore it.

1.3.  Terminology

This specification uses a number of terms to refer to the roles played by participants in, and objects of, the SIP Alerting for User Devices. A "specifier" sends an "indication" or "identifier" (a URN in an Alert-Info header) to a "renderer" which then "renders" a "signal" or "rendering" based on the indication to a human user. A "category" is a characteristic whose "values" can be used to classify indications.

This specification uses the terms "ring tone" and "ringback tone". A "ring tone" or "calling signal" (terminology used in [ITU‑T E.182] (, “Application of tones and recorded announcements in telephone services,” .)) 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 [ITU‑T E.182] (, “Application of tones and recorded announcements in telephone services,” .)) 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 identifier to transport the semantics of the signaling situation or the characteristics of the rendering.

REQ-1: The mechanism will allow user agents (UAs) and proxies to provide in the Alert-Info SIP-header an 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 identifier to be specified "by name" rather than "by value", to enable local policy decisions whether to use it or not.

REQ-3: Indications must be able to represent a wide variety of signals, which have many largely-orthogonal characteristics.

REQ-4: Indications include subsets which have distinctly different semantics, that is, they form disjoint "value spaces". For example, some indications should describe the semantics of the signaling situation whereas others should describe the audio characteristics of the signal. This implies that there is no single set of categories that can be used as independent coordinates of the value-space of indications.

REQ-5: The set of indications must be able to support extensibility by a wide variety of organizations that are not coordinated with each other. Extensions must 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

- add further value spaces of indications whose semantics are not related to existing indications, and thus, whose categories differ from and do not interact with existing categories.

REQ-7: An indication is transmitted from a specifier to a renderer, which must base its rendering decision only on the indication. In particular, there is no multi-message negotiation process or carrying of context from one indication to the next.

REQ-8: The mechanism will allow transmission in the Alert-Info header of SIP INVITE requests and provisional 1xx responses excepting the 100 responses.

REQ-9: The renderer may be customized in ways that limit the set of signals that it can render, or it may be provided with a set of signals that have uncommon semantics. (The canonical example is a UA for the hearing-impaired.) (By REQ-7, the renderer has no way of transmitting this fact to the specifier.)

REQ-10: If the specifier and the renderer have designs that are properly coordinated, the indications must be able to reliably carry all extensions that are supported in the coordinated designs. In any other situation, it is not required from the renderer to perform the best possible rendering.

REQ-11: In any situation, the renderer must be able to perform close to the best possible rendering that it could do even the specifier had specific knowledge of the renderer's capabilities.

REQ-12: The mechanism will allow interoperability for services as call waiting, forward, transfer-recall, auto-callback, hold-recall.

REQ-13: The mechanism will allow rendering common PBX ring tone types.

REQ-14: The mechanism will allow rendering specific country ringback tones.

REQ-15: The mechanism will allow rendering tones for emergency alerts. (Use cases and values definition are not subject of this specification.)

REQ-16: The mechanism will allow rendering using other means than tones, e.g. text or images.

REQ-17: 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-18: The mechanism must ensure that an UA receiving Alert-Info URNs or portions of an Alert-Info URN it does not understand, it can ignore them.

REQ-19: The mechanism will allow storage of the actual encoding locally rather than fetching it.

3.  Use Cases

This section describes some use cases for which the Alert-Info URN mechanism is needed today.

3.1.  PBX Ring Tones

This section defines some commonly encountered ring tones on PBX or business phones. They are as follows:

3.1.1.  normal

This tone indicates that the default or normal ring tone should be rendered. This is essentially a no-operation Alert-Info URN and should be treated by the UA as if no Alert-Info URN is present. This is most useful when Alert-Info header field parameters are being used. For example, in [I‑D.ietf‑bliss‑shared‑appearances] (Johnston, A., Soroushnejad, M., and V. Venkataramanan, “Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR),” July 2010.), an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ring tone needs to be specified.

3.1.2.  external

This tone is used to indicate that the caller is external to the enterprise or PBX system. This could be a call from the PSTN or from a SIP trunk.

3.1.3.  internal

This tone is used to indicate that the caller is internal to the enterprise or PBX system. The call could have been originated from another user on this PBX or on another PBX within the enterprise.

3.1.4.  priority

A PBX tone needs to indicate that a priority level alert should be applied for the type of alerting specified (e.g. internal alerting).

3.1.5.  short

In this case the alerting type specified (e.g. internal alerting) should be rendered shorter than normal. In contact centers, this is sometimes referred to as "abbreviated ringing" or a "zip tone".

3.1.6.  delayed

In this case the alerting type specified should be rendered after a short delay. In some bridged line/shared line appearance implementations, this is used so that the bridged line does not ring at exactly the same time as the main line, but is delayed a few seconds.

3.2.  Service Tones

These tones are used to indicate specific PBX and public network telephony services.

3.2.1.  call-waiting

The Call Waiting Service [TS24.615] (, “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 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 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 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 user.

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

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

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 would like to have this feature for SIP.

4.  Namespace Registration Template

This section describes the registration template for the 'alert' URN namespace identifier (NID) according to the [RFC2141] (Moats, R., “URN Syntax,” May 1997.) and [RFC3406] (Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, “Uniform Resource Names (URN) Namespace Definition Mechanisms,” October 2002.)

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 the right-side of the alert-identifier, the alert-indication, by a colon. The general form is urn:alert:{alert-category}:{alert-indication}.

In this specification, following alert-categories identifiers are described: "service" , "priority" , "source" , "duration", "delay" and "locale". The alert-category set can be extended in the future.

The categories are orthogonal. Any Alert-Info 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.

The alert-indications are hierarchical identifiers, consisting of one label or a sequence of labels separated by periods. 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.

The ABNF [RFC5234] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” January 2008.) for the Alert -Info URNs is shown below:

     alert-URN       = "URN:alert:" alert-identifier
     alert-identifier= alert-category ":" alert-indication
     alert-category  = name
     alert-indication= name *("." name)
     name = 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-Info URN. The assignment of identifiers is described in Section 11 (IANA Considerations). The Alert-Info 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-Info URN identifies a logical service or tone, specified in the alert-indication registration (see Section 11 (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 11 (IANA Considerations).

Identifier persistence considerations:

The Alert-Info 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 11 (IANA Considerations).

Process for identifier resolution:

'Alert-Info URNs are statically resolved according to the IANA registry.

Rules for lexical equivalence:

Alert-Info 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-Info URNs at IANA.

Scope:

The scope for this URN is public and global.

5.  Alert-Info URN Values Definitions

5.1.  Alert-category Values Definitions

Following alert-category values are defined in this document:

- service

- source

- priority

- duration

- delay

- locale

5.2.  Alert-indication Values Definitions

This section describes the Alert-Info URN indication values for the alert-categories defined in this document.

For each alert-category, a default indication is defined, which is essentially a no-operation Alert-Info URN and should be treated by the UA as if no Alert-Info URN for the respective category is present. Alert-Info URN default indications are 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),” July 2010.), an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ringtone need be specified.

5.2.1.  Alert-Info URN Indication Values for the alert-category 'service'

- normal (default)

- call-waiting

- forward

- recall.callback

- recall.hold

- recall.transfer

- private.<private-name>

Examples: urn:alert:service:call-waiting or urn:alert:service:recall.transfer.

5.2.2.  Alert-Info URN Indication Values for the alert-category 'source'

- unclassified (default)

- internal

- external

- friend

- family

- private.<private-name>

Examples: urn:alert:source:external.

5.2.3.  Alert-Info URN Indication Values for the alert-category 'priority'

- normal (default)

- low

- high

- private.<private-name>

Examples: urn:alert:priority:high.

5.2.4.  Alert-Info URN Indication Values for the alert-category 'duration'

- normal (default)

- short

- long

- private.<private-name>

Examples: urn:alert:duration:short.

5.2.5.  Alert-Info URN Indication Values for the alert-category 'delay'

- none (default)

- yes

- private.<private-name>

Examples: urn:alert:delay:yes .

5.2.6.  Alert-Info URN Indication Values for the alert-category 'locale'

- default (default)

- country.<ISO 3166-1 country code>

- private.<private-name>

The ISO 3166-1 country code [ISO 3166‑1] (, “ISO 3166-1 English country names and code elements,” .) is used to inform the UA 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: <urn:alert:locale:country.za>.

6.  Extensibility Rules

6.1.  General Extensibility Rules

TBD

6.2.  Extensions Rules for Independent Organizations

The "private.<private-name>" syntax is for extensions specific to independent organizations. The "<private-name>" is used in the form of a "reverse FQDN" such as is used for Java package names. This gives a way of assigning unique names without the need for a new registry. The namespace for each alert category is independent. Those assigning new names must ensure they are in a position to assign names uniquely for the FQDN they choose. For example, a private company might want to define: urn:alert:source:private.com.example.customer

Adding new categories and adding alert-indication values other than via the "private" mechanism is standards action.

7.  Combinations of URNs

This chapter only describes combination rules for the case when all the Alert-Info headers only contain Alert-Info URNs. Combinations of URNs and URIs in the Alert-Info headers of the same SIP-message are not defined in this specification.

In many cases, more than one URNs will be needed to fully define a particular tone. This is done by including multiple Alert-Info URNs, in one or more Alert-Info headers in a request or a response. For example, an internal, priority call could be indicated by Alert-Info: <urn:alert:source:internal>, <urn:alert:priority:high>. A priority call waiting tone could be indicated by Alert-Info: <urn:alert:service:call-waiting>, <urn:alert:priority:high>.

The categories are orthogonal. Any Alert-Info URN defined in this specification is syntactically valid for ring and for ringback and can be used in an INVITE or in provisional 1xx responses excepting the 100 response. There MUST be at most one instance of each alert-category in the Alert-Info header(s) of a request or response. In principle any combination of Alert-Info URNs with different "alert-category" is valid and can be used for either ring or ringback, though some combinations may not make sense.

The receiving UA should make the decision about what to render to the user and what device it is rendered on depending on the value of the Alert-Info header(s) content and of the kind of the received message (INVITE or provisional response). Typically, the same UA will do the rendering of one or more particular Alert-Info header(s) content received in an INVITE differently from the rendering of the same Alert-Info header(s) content received in a provisional response.

The exact way in which the various categories are combined for rendering is left as an implementation issue. The implementation is free to ignore any or all parts of the received Alert-Info URNs.

8.  Priority Rules within Combinations of URNs

TBD

9.  User Agent Behaviour

Upon receiving a SIP INVITE request or a SIP provisional response with an Alert-Info header that contains a single or multiple Alert-Info URNs, the User Agent (UA) attempts to match the received Alert-Info URNs with the known indications or indication combinations. The User Agent (UA) ignores the Alert-Info URNs for which no match is found and proceeds with the normal operation. If one or multiple URNs match(es) a known indication or a known indication combination, the User Agent (UA) renders the indication or the indication combination to the user accordingly. The User Agent (UA) is responsible for the non disturbing rendering if multiple indications and network resources are to be rendered simultaneously.

10.  Proxy Behaviour

A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header in a SIP request or a provisional 1xx response excepting 100 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 Alert-Info URNs and URIs to the Alert-Info header that may cause disturbing rendering interference at the recipient'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>

11.  IANA Considerations

This section registers a new URN namespace identifier (NID) in accordance with RFC 3406 with the registration template provided in Section 4 (Namespace Registration Template) .

11.1.  New alert identifiers

Alert URN identifiers are identified by labels managed by IANA, according to the processes outlined in [RFC5226] (Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” May 2008.) in a new registry called "Alert URN Labels". Thus, creating a new Alert-Info URN identifier requires IANA action. The policy for adding a new alert category is 'Standards Action'. (This document defines the alert categories 'service', 'source', 'priority', 'duration', 'delay' and 'locale'. ) The policy for assigning labels to alert-indications and the rules to combine them may differ for each alert-category and MUST be defined by the document describing the corresponding alert category. The entries in the registration table have the following format:

   alert-category/      Reference    Description
   alert-identifier
   ---------------------------------------------------------------
   foo                  RFCxyz       Description of the 'foo'
                                     alert-category
   foo:bar              RFCabc       Description of the 'foo:bar'
                                     alert-identifier

Each alert-category or alert-indication label MUST NOT exceed 27 characters.

11.2.  Initial IANA Registration

11.2.1.  The "service" alert-category and alert-identifiers

The following table contains the initial IANA registration for the "service" alert-category and alert-identifiers. 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 which has been initiated.

alert-category/                Reference  Description
alert-identifier
-----------------------------------------------------------
service                        RFC XXXX  Alert-category for "service"
                                         alert-identifiers.
service:normal                 RFC XXXX  Normal ring /rinback
                                         rendering (default value).
service:call-waiting           RFC XXXX  Call waiting was
                                         initiated at the other side
                                         of the call.
service:forward                RFC XXXX  Call has been forwarded.
service:recall.calback         RFC XXXX  Recall due to callback.
service:recall.hold            RFC XXXX  Recall due to call hold.
service:recall.transfer        RFC XXXX  Recall due to callback.
service:private.<private-name> RFC XXXX  Reserved for private
                                         extensions.

11.2.2.  The "source" alert-category and alert-identifiers

The following table contains the initial IANA registration for the "source" alert-category and alert-identifiers. The value of this indicator provides information about the user at the other side of the call.

alert-category/              Reference  Description
alert-identifier
-----------------------------------------------------------
source                        RFC XXXX  Alert-category for "source"
                                        alert-identifiers
source:unclassified           RFC XXXX  Unclassified ring /rinback
                                        rendering (default value)
source:internal               RFC XXXX  User at the other side of
                                        the call is internal to the
                                        enterprise or PBX system.
source:external               RFC XXXX  User at the other side of
                                        the call is internal to the
                                        enterprise or PBX system.
source:friend                 RFC XXXX  User at the other side of
                                        the call is a friend.
source:family                 RFC XXXX  User at the other side of
                                        the call is a family member.
source:private.<private-name> RFC XXXX  Reserved for private
                                        extensions.

11.2.3.  The "priority" alert-category and alert-identifiers

The following table contains the initial IANA registration for the "priority" alert-category and alert-identifiers. The value of this indicator provides information about the priority the alerted user should give to the call.

alert-category/                 Reference  Description
alert-identifier
-----------------------------------------------------------
priority                        RFC XXXX  Alert-category for
                                         "priority" alert-
                                          identifiers.
priority:normal                 RFC XXXX  Normal ring /rinback
                                          rendering (default value).
priority:low                    RFC XXXX  Low priority call.
priority:high                   RFC XXXX  High priority call.
priority:private.<private-name> RFC XXXX  Reserved for private
                                          extensions.

11.2.4.  The "duration" alert-category and alert-identifiers

The following table contains the initial IANA registration for the "duration" alert-category and alert-identifiers. The value of this indicator provides information about the duration of the alerting signals compared to the default alerting signals.

alert-category/                 Reference  Description
alert-identifier
-----------------------------------------------------------
duration                        RFC XXXX  Alert-category for "duration"
                                          alert-identifiers
duration:normal                 RFC XXXX  Normal ring /rinback
                                          rendering (default value)
duration:short                  RFC XXXX  Shorter than normal
duration:long                   RFC XXXX  Longer than normal
duration:private.<private-name> RFC XXXX  Reserved for private
                                          extensions.

11.2.5.  The "delay" alert-category and alert-identifiers

The following table contains the initial IANA registration for the "delay" alert-category and alert-identifiers. The value of this indicator provides information about the delay of the alerting signals.

alert-category/              Reference  Description
alert-identifier
-----------------------------------------------------------
delay                        RFC XXXX  Alert-category for "delay"
                                       alert-identifiers
delay:none                   RFC XXXX  Immediate alerting
                                       (default value)
delay:yes                    RFC XXXX  Delayed alerting
delay:private.<private-name> RFC XXXX  Reserved for private
                                       extensions.

11.2.6.  The "locale" alert-category and alert-identifiers

The following table contains the initial IANA registration for the "locale" alert-category and alert-identifiers. The value of this indicator provides information about the location of the user at the other side of the call.

alert-category/               Reference  Description
alert-identifier
-----------------------------------------------------------
locale                        RFC XXXX  Alert-category for "locale"
                                        alert-identifiers
locale:default                RFC XXXX  Alerting not location
                                        specific
                                        (default value)
locale:country.<ISO 3166-1 country code>
                              RFC XXXX  Country-specific alerting
locale:private.<private-name> RFC XXXX  Reserved for private
                                        extensions.

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

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

14.  Acknowledgements

The draft is based on the ideas expressed by Paul Kyzivat on the BLISS WG mailing list. The authors wish to thank Paul Kyzivat and Dale Worley for their major contributions to this draft and also Adam Roach, Dean Willis, Martin Huelsemann, Shida Schubert, John Elwell and Tom Taylor for their comments and suggestions.

15.  References

15.1. Normative References

15.2. Informative References

Authors' Addresses