DISPATCH L. Liess, Ed.
Internet-Draft D. Alexeitsev
Intended status: Standards Track R. Jesske
Expires: January 10, 2011 Deutsche Telekom AG
A. Johnston
A. Siddiqui
Avaya
July 9, 2010
Alert-Info URNs for the Session Initiation Protocol (SIP)
draft-liess-dispatch-alert-info-urns-02
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].
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 January 10, 2011.
Liess, et al. Expires January 10, 2011 [Page 1]
Internet-Draft Alert-Info URNs July 2010
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. PBX Tones . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1. normal . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2. external . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.3. internal . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.4. priority . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.5. short . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.6. delayed . . . . . . . . . . . . . . . . . . . . . . . 9
3.2. Service Tones . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. call-waiting . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. forward . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. transfer-recall . . . . . . . . . . . . . . . . . . . 9
3.2.4. auto-callback . . . . . . . . . . . . . . . . . . . . 10
3.2.5. hold-recall . . . . . . . . . . . . . . . . . . . . . 10
3.3. Country-specific ringback tone indications for the
public telephone network . . . . . . . . . . . . . . . . . 10
4. Namespace Registration Template . . . . . . . . . . . . . . . 10
5. Alert-Info URN Values Definitions . . . . . . . . . . . . . . 13
5.1. Alert-category Values Definitions . . . . . . . . . . . . 13
5.2. Alert-indication Values Definitions . . . . . . . . . . . 13
5.2.1. Alert-Info URN Indication Values for the
alert-category 'service' . . . . . . . . . . . . . . . 13
5.2.2. Alert-Info URN Indication Values for the
alert-category 'source' . . . . . . . . . . . . . . . 14
5.2.3. Alert-Info URN Indication Values for the
alert-category 'priority' . . . . . . . . . . . . . . 14
Liess, et al. Expires January 10, 2011 [Page 2]
Internet-Draft Alert-Info URNs July 2010
5.2.4. Alert-Info URN Indication Values for the
alert-category 'duration' . . . . . . . . . . . . . . 14
5.2.5. Alert-Info URN Indication Values for the
alert-category 'delay' . . . . . . . . . . . . . . . . 15
5.2.6. Alert-Info URN Indication Values for the
alert-category 'locale' . . . . . . . . . . . . . . . 15
6. Combinations of URNs . . . . . . . . . . . . . . . . . . . . . 16
7. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 16
8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. New alert identifiers . . . . . . . . . . . . . . . . . . 17
9.2. Initial IANA Registration . . . . . . . . . . . . . . . . 18
9.2.1. The "service" alert-category and alert-identifiers . . 18
9.2.2. The "source" alert-category and alert-identifiers . . 18
9.2.3. The "priority" alert-category and alert-identifiers . 19
9.2.4. The "duration" alert-category and alert-identifiers . 19
9.2.5. The "delay" alert-category and alert-identifiers . . 20
9.2.6. The "locale" alert-category and alert-identifiers . . 20
10. Internationalization Considerations . . . . . . . . . . . . . 21
11. Security Considerations . . . . . . . . . . . . . . . . . . . 21
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
13.1. Normative References . . . . . . . . . . . . . . . . . . . 21
13.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Liess, et al. Expires January 10, 2011 [Page 3]
Internet-Draft Alert-Info URNs July 2010
1. Introduction
1.1. Motivation
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: <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 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.:
Liess, et al. Expires January 10, 2011 [Page 4]
Internet-Draft Alert-Info URNs July 2010
o Names for service indications, such as call waiting or automatic
callback, not tied to any particular rendering.
o Names for common ring-tones generated by PBX phones for cases such
as an internal enterprise caller, external caller, ringback after
a transfer failure or expiration of a hold timer, etc.
o Names for country-specific ringback tones.
o Names for things with specific renderings that aren't purely
audio. They might be static icons, video sequences, text, etc.
Some advantages of a URN rather than a 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.
TBD-1: This specification does not change the usage of the SIP Alert-
Info-header defined in the RFC3261. The Alert-Info-header can be
used in INVITE requests and 180 Ringing responses.
1.2. 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. We say that a "specifier" sends an "indication" (a URN in
an Alert-Info header) to a "renderer" which then "renders" a "signal"
Liess, et al. Expires January 10, 2011 [Page 5]
Internet-Draft Alert-Info URNs July 2010
or "rendering" based on the indication to a human user. A "category"
is a characteristic whose "values" can be used to classify
indications.
2. Requirements
This section discusses the requirements for an identifier to
transport the semantics of the alerting situation or the
characteristics of the alerting signal.
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-6: The mechanism will be flexible, so new identifiers can be
Liess, et al. Expires January 10, 2011 [Page 6]
Internet-Draft Alert-Info URNs July 2010
defined in the future, when SIP-applications evolve. E. g. Alert-
Info URNs could identify specific media by name, such as "Beethoven's
Fifth", and the end device could render some small part of it as a
ring tone.
REQ-7: 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 180 Ringing 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-9, 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, call forwarding, 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.
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.
Liess, et al. Expires January 10, 2011 [Page 7]
Internet-Draft Alert-Info URNs July 2010
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 URNs
are needed today.
3.1. PBX 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], an Alert-
Info header field needs to be present containing the "appearance"
parameter, but no special ringtone 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).
Liess, et al. Expires January 10, 2011 [Page 8]
Internet-Draft Alert-Info URNs July 2010
3.1.5. short
In this case the alerting type specified (e.g. internal alerting)
should be rendered shorter than normal. In contact centers, this is
sometimes referred to as "abbreviated ringing" or a "zip tone".
3.1.6. delayed
In this case the alerting type specified should be rendered after a
short delay. In some bridged line/shared line appearance
implementations, this is used so that the bridged line does not ring
at exactly the same time as the main line, but is delayed a few
seconds.
3.2. Service Tones
These tones are used to indicate specific PBX and public network
telephony services.
3.2.1. call-waiting
The Call Waiting Service [TS24.615] permits a callee to be notified
of an incoming call while the callee is engaged in an active or held
call. Subsequently, the callee can either accept, reject, or ignore
the incoming call. There is an interest on the caller side to be
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] 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
Liess, et al. Expires January 10, 2011 [Page 9]
Internet-Draft Alert-Info URNs July 2010
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] and [RFC3406]
Namespace ID: alert
Registration Information:
Registration version: 1
Registration date: TBD
Declared registrant of the namespace:
Registering organization: IETF
Liess, et al. Expires January 10, 2011 [Page 10]
Internet-Draft Alert-Info URNs July 2010
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.
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 for ringback and
can be used in an INVITE or in a 180 response.
The alert-indications 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.
The ABNF [RFC5234] for the Alert -Info URNs is shown below:
alert-URN = "URN:alert:" alert-identifier
alert-identifier= alert-category ":" alert-indication
alert-category = let-dig [ *25let-dig-hyp let-dig ]
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
Liess, et al. Expires January 10, 2011 [Page 11]
Internet-Draft Alert-Info URNs July 2010
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 9. 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 9). 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 9.
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 9.
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.
Liess, et al. Expires January 10, 2011 [Page 12]
Internet-Draft Alert-Info URNs July 2010
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-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], 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)
Liess, et al. Expires January 10, 2011 [Page 13]
Internet-Draft Alert-Info URNs July 2010
- 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'
Liess, et al. Expires January 10, 2011 [Page 14]
Internet-Draft Alert-Info URNs July 2010
- 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] is used as a top-level
indication 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:za>.
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, Cisco
might want to define: urn:alert:source:private.com.cisco.customer
Adding new categories and adding alert-indication values other than
via the "private" mechanism is standards action.
Liess, et al. Expires January 10, 2011 [Page 15]
Internet-Draft Alert-Info URNs July 2010
6. 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: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 a 180 response. There can be at most
one instance of each alert-category in an Alert-Info header. 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 URN and the
kind of the received message (INVITE or 180-response). Typically,
the same UA will do the rendering of a particular Alert-Info URN
received in an INVITE differently from the rendering of the same
Alert-Info URN received in a 180 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 received Alert-Info URNs.
7. User Agent Behavior
Upon receiving a SIP INVITE 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 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.
8. 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 'alert'
Liess, et al. Expires January 10, 2011 [Page 16]
Internet-Draft Alert-Info URNs July 2010
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>
9. IANA Considerations
This section registers a new URN namespace identifier (NID) in
accordance with RFC 3406 with the registration template provided in
section Section 4 .
Below, the section Section 9.1 details how to register new 'alert'
URN identifiers. Descriptions of alert-indications for the 'alert'
URN identifiers defined in this document are given in section
Section 5.2 . Finally, Section 7.4 contains the initial registration
table.
9.1. New alert identifiers
Alert URN identifiers are identified by labels managed by IANA,
according to the processes outlined in [RFC5226] in a new registry
called "Alert URN Labels". Thus, creating a new 'alert' 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
Liess, et al. Expires January 10, 2011 [Page 17]
Internet-Draft Alert-Info URNs July 2010
Each alert-category or alert-indication label MUST NOT exceed 27
characters.
9.2. Initial IANA Registration
9.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
calee 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.
9.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.
Liess, et al. Expires January 10, 2011 [Page 18]
Internet-Draft Alert-Info URNs July 2010
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.
9.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.
9.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.
Liess, et al. Expires January 10, 2011 [Page 19]
Internet-Draft Alert-Info URNs July 2010
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.
9.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.
9.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
Liess, et al. Expires January 10, 2011 [Page 20]
Internet-Draft Alert-Info URNs July 2010
extensions.
10. 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.
11. 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.
12. 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.
13. References
13.1. Normative References
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
and Support", STD 3, RFC 1123, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Liess, et al. Expires January 10, 2011 [Page 21]
Internet-Draft Alert-Info URNs July 2010
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
13.2. Informative References
[I-D.ietf-bliss-shared-appearances]
Johnston, A., Soroushnejad, M., and V. Venkataramanan,
"Shared Appearances of a Session Initiation Protocol (SIP)
Address of Record (AOR)",
draft-ietf-bliss-shared-appearances-05 (work in progress),
March 2010.
[ISO 3166-1]
"ISO 3166-1 English country names and code elements", http
://www.iso.org/iso/
english_country_names_and_code_elements .
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in
the IETF", RFC 3536, May 2003.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5589] Sparks, R., Johnston, A., and D. Petrie, "Session
Initiation Protocol (SIP) Call Control - Transfer",
BCP 149, RFC 5589, June 2009.
[TS24.615]
"3GPP TS 24.615 Communication Waiting (CW) using IP
Multimedia (IM) Core Network (CN) subsystem".
Authors' Addresses
Laura Liess (editor)
Deutsche Telekom AG
Heinrich-Hertz Str 3-7
Darmstadt, Hessen 64295
Germany
Phone: +49-6151-6282761
Email: laura.liess.dt@gmail.com
Liess, et al. Expires January 10, 2011 [Page 22]
Internet-Draft Alert-Info URNs July 2010
Denis Alexeitsev
Deutsche Telekom AG
Friedrich-Ebert-Allee
Bonn 53113
Germany
Phone: +49-228-18112010
Email: d.alexeitsev@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.b.johnston@gmail.com
Anwar Siddiqui
Avaya
Milpitas, CA
United States
Phone:
Email: anwars@avaya.com
Liess, et al. Expires January 10, 2011 [Page 23]