RFC 7462
URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)
Internet Engineering Task Force (IETF) L. Liess, Ed. Request for Comments: 7462 R. Jesske Updates: 3261 Deutsche Telekom AG Category: Standards Track A. Johnston ISSN: 2070-1721 Avaya D. Worley Ariadne P. Kyzivat Huawei March 2015 URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)Abstract
The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the User Agent (UA) as an alerting signal (e.g., a ring tone or ringback tone) when the user is alerted. This is done using the Alert-Info header field. However, the reference (typically a URL) addresses only a specific network resource with specific rendering properties. There is currently no support for standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome these limitations and support new applications, a new family of URNs for use in Alert-Info header fields (and situations with similar requirements) is defined in this specification. This document normatively updates RFC 3261, which defines the Session Initiation Protocol (SIP). It changes the usage of the Alert-Info header field defined in RFC 3261 by additionally allowing its use in any non-100 provisional response to INVITE. This document also permits proxies to add or remove an Alert-Info header field and to add or remove Alert-Info header field values.
Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7462. Copyright Notice Copyright (c) 2015 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
Table of Contents
1. Introduction ....................................................5 2. Requirements Language ...........................................7 3. Terminology .....................................................7 4. Updates to RFC 3261 .............................................7 4.1. Allow Alert-Info in Provisional Responses ..................7 4.2. Proxies May Alter Alert-Info Header Fields .................8 5. Requirements ....................................................8 6. Use Cases ......................................................10 6.1. PBX Ring Tones ............................................10 6.1.1. Normal .............................................10 6.1.2. External ...........................................10 6.1.3. Internal ...........................................11 6.1.4. Priority ...........................................11 6.1.5. Short ..............................................11 6.1.6. Delayed ............................................11 6.2. Service Tones .............................................11 6.2.1. Call Waiting .......................................11 6.2.2. Forward ............................................12 6.2.3. Transfer Recall ....................................12 6.2.4. Auto Callback ......................................12 6.2.5. Hold Recall ........................................12 6.3. Country-Specific Ringback Tone Indications for the Public Switched ...........................................12 7. URN Specification for the "alert" Namespace Identifier .........12 8. "alert" URN Values .............................................18 8.1. <alert-category> Values ...................................18 8.2. <alert-indication> Values .................................18 8.2.1. <alert-indication> Values for the <alert-category> "service" .........................19 8.2.2. <alert-indication> Values for the <alert-category> "source" ..........................19 8.2.3. <alert-indication> Values for the <alert-category> "priority" ........................19 8.2.4. <alert-Indication> Values for the <alert-category> "duration" ........................20 8.2.5. <alert-indication> Values for the <alert-category> "delay" ...........................20 8.2.6. <alert-indication> Values for the <alert-category> "locale" ..........................20 9. IANA Considerations ............................................20 9.1. URN Namespace Identifier "alert" ..........................20 9.2. 'Alert URN Identifiers' Registry ..........................20 9.2.1. Initial IANA Registration ..........................21 9.2.1.1. The "service" <alert-category> and <alert-identifier>s .......................22
9.2.1.2. The "source" <alert-category> and
<alert-identifier>s .......................23
9.2.1.3. The "priority" <alert-category>
and <alert-identifier>s ...................24
9.2.1.4. The "duration" <alert-category>
and <alert-identifier>s ...................24
9.2.1.5. The "delay" <alert-category> and
<alert-identifier>s .......................25
9.2.1.6. The "locale" <alert-category> and
<alert-identifier>s .......................25
9.3. 'Alert URN Providers' Registry ............................26
10. Extension Rules ...............................................26
10.1. General Extension Rules ..................................26
10.2. Private Extension Rules ..................................27
10.3. Examples .................................................28
10.3.1. Subsetting an Existing URN ........................28
10.3.2. A New Value within an <alert-category> ............29
10.3.3. A New <alert-category> ............................29
10.3.4. Subsetting a Private Extension URN ................29
11. Combinations of "alert" URNs ..................................30
11.1. Priority Rules ...........................................30
11.2. Multi-mode Signals .......................................31
12. Non-normative Algorithm for Handling Combinations of URNs .....32
12.1. Algorithm Description ....................................32
12.2. Examples of How the Algorithm Works ......................34
12.2.1. Example 1 .........................................34
12.2.2. Example 2 .........................................35
12.2.3. Example 3 .........................................37
12.2.4. Example 4 .........................................38
12.2.5. Example 5 .........................................39
13. User Agent Behaviour ..........................................40
14. Proxy Behaviour ...............................................41
15. Internationalization Considerations ...........................42
16. Security Considerations .......................................42
17. References ....................................................43
17.1. Normative References .....................................43
17.2. Informative References ...................................44
Acknowledgements ..................................................45
Authors' Addresses ................................................46
1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] includes a means to suggest to a User Agent (UA) a particular ringback tone or ring tone to be used during session establishment. In [RFC3261], this is done by including a URI, in the Alert-Info header field, that specifies a reference to the tone. The URI is most commonly the HTTP URL to an audio file. On the receipt of the Alert-Info header field, the UA may fetch the referenced ringback tone or ring tone and play it to the user. This mechanism hinders interoperability when there is no common understanding of the meaning of the referenced tone, which might be country- or vendor-specific. It can lead to problems for the user trying to interpret the tone and for the UA wanting to substitute its own tone (e.g., in accordance with user preferences) or provide an alternative alerting mode (e.g., for deaf and hard-of-hearing users). If the caller and the callee are from different countries, their understanding of the tones may differ significantly. Deaf or hard- of-hearing 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. Another limitation of using URLs of audio files is that the referenced tones are tied to particular renderings. There is no method to signal the semantic intention of the alert while enabling the recipient UA to choose the specific alert indication (such as a particular tone, vibration, or visual display) to use to signal the intention. Similarly, there is no method to signal particular rendering features (such as short duration, delay, or country- specific conventions). The issues with URLs that reference audio files can be avoided by using fixed URLs with specific meanings. However, this approach has its own interoperability issues. For example, consider the Private Branch Exchange (PBX) special ring tone for an external (to the PBX) caller. Different vendors use different approaches such as: Alert-Info: <file://ring.pcm>;alert=external where ring.pcm is a dummy file name, or: Alert-Info: <file://external.ring.pcm> Alert-Info: <sip:external-ringtone@example.com> As a result, the Alert-Info header field currently only works when the same vendor provides a PBX and UA, and only then if the same artificial proprietary URI convention is used.
To solve the described issues, this specification defines the new URN
namespace "alert" for the SIP Alert-Info header field that allows for
programmatic user interface adaptation and for conversion of
equivalent alerting tones in the Public Switched Telephone Network
(PSTN) when the client is a gateway. The work to standardize an
"alert" URN will increase SIP interoperability for this header field
by replacing proprietary conventions used today.
The "alert" namespace provides a syntax for several different
application spaces, for example:
o Names for service indications, such as call waiting or automatic
callback, not tied to any particular rendering.
o Names for common ring tones generated by PBX phones for cases such
as an internal enterprise caller, external caller, ringback tone
after a transfer failure or expiration of a hold timer, etc.
o Names for country-specific ringback tones.
o Names for things with specific renderings that aren't purely
audio. They might be static icons, video sequences, text, etc.
Some advantages of a URN rather than a URL of a downloadable
resource:
o There is no need to download it or deal with security issues
associated with dereferencing.
o There are no formatting or compatibility issues.
o There is 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 or not to use
it.
o It facilitates translation for the deaf and hard of hearing.
The downside is that if the recipient does not understand the URN,
then it will only be able to render a default ringback tone or ring
tone.
This document creates a new URN namespace and registry for alert indications and registers some initial values. In practice, this specification extends the usage of the Alert-Info header field in that it will cause the use of a new class of URIs and the use of multiple URIs. Backward compatibility issues are not expected, as devices that do not understand an "alert" URN should ignore it, and devices should not malfunction upon receiving multiple Alert-Info header field values (<alert-param>s in [RFC3261]) (which was syntactically permitted before, but rarely used).2. 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].3. Terminology
This specification uses a number of terms to refer to the roles involved in the use of alerting indications in SIP. A "specifier" sends an "alerting indication" (one or more URNs in an Alert-Info header field) to a "renderer", which then "renders" a "signal" or "rendering" based on the indication to a human user. A "category" is a characteristic whose "values" can be used to classify indications. This specification uses the terms "ring tone" and "ringback tone". A "ring tone" or "calling signal" (terminology used in [E182]) is a signal generated by the callee's end device, advising the callee about an incoming call. A "ringback tone" or "ringing tone" (terminology used in [E182]) is a signal advising the caller that a connection has been made and that a ring tone is being rendered to the callee.4. Updates to RFC 3261
4.1. Allow Alert-Info in Provisional Responses
This specification changes the usage of the Alert-Info header field defined in [RFC3261] by additionally allowing its use in any non-100 provisional response to INVITE. Previously, the Alert-Info header field was only permitted in 180 (Ringing) responses. But in telephony, other situations indicated by SIP provisional responses, such as 181 (Call Is Being Forwarded) and 182 (Call Is Being Queued), are often indicated by tones. Extending the applicability of the Alert-Info header field allows the telephony practice to be implemented in SIP.
To support this change, the following paragraph replaces the the first paragraph of Section 20.4 of [RFC3261]: When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the User Agent Server (UAS). When present in a non-100 provisional response, the Alert-Info header field specifies an alternative ringback tone to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature.4.2. Proxies May Alter Alert-Info Header Fields
A SIP proxy MAY add or remove an Alert-Info header field, and it MAY add or remove Alert-Info header field values, in a SIP request or a non-100 provisional response.5. Requirements
This section discusses the requirements for an alerting indication to transport the semantics of the alerting situation or the characteristics of the rendering. REQ-1: The mechanism will allow UAs and proxies to provide in the Alert-Info header field an alerting indication that describes the semantics of the signaling situation or the characteristics of the rendering and allows the recipient to decide how to render the received information to the user. REQ-2: The mechanism will allow the alerting indication to be specified "by name" rather than "by value", to enable local policy decisions whether or not to use it. REQ-3: The mechanism will enable alerting indications to represent a wide variety of signals, which have many largely orthogonal characteristics. REQ-4: The mechanism will enable the set of alerting indications to support extensibility by a wide variety of organizations that are not coordinated with each other. Extensions will be able to: add further values to any existing category add further categories that are orthogonal to existing categories semantically subdivide the meaning provided by any existing indication
REQ-5: The mechanism will be flexible, so new alerting indications
can be defined in the future, when SIP-applications evolve.
For example, "alert" URNs could identify specific media by
name, such as "Beethoven's Fifth", and the end device could
render some small part of it as a ring tone.
REQ-6: The mechanism will provide only an indication capability,
not a negotiation capability.
REQ-7: The mechanism will not require an alerting indication to
depend on context provided by a previous alerting indication
in either direction.
REQ-8: The mechanism will allow transmission in the Alert-Info
header field of SIP INVITE requests and provisional 1xx
responses excepting the 100 responses.
REQ-9: The mechanism will be able to accommodate both renderers
that are customized with a limited or uncommon set of
signals that they can render and renderers that are provided
with a set of signals that have uncommon semantics. (The
canonical example is a UA for the deaf and hard of hearing,
customized with an alternative set of signals, video or text
instead of audio. By REQ-6, the renderer has no way of
transmitting this fact to the specifier.)
REQ-10: The mechanism will allow an alerting indication to reliably
carry all extensions if the specifier and the renderer have
designs that are properly coordinated.
REQ-11: The mechanism will allow a renderer to select a tone that
approximates to that intended by the specifier if the
renderer is unable to provide the precise tone indicated.
REQ-12: The mechanism will support alerting indications relating to
services such as call waiting, call forwarding, transfer
recall, auto callback, and 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 definitions of URN values for
emergency calls are not a 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 PSTN 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 for this
situation are not a subject of this specification.)
REQ-18: The mechanism will ensure that if an UA receives "alert"
URNs or portions of an "alert" URN it does not understand,
it can ignore them.
REQ-19: The mechanism will allow storage of the actual encoding of
the rendering locally rather than fetching it.
REQ-20: The mechanism must provide a simple way to combine two or
more alerting indications to produce an alerting indication
that requests a combination of the intentions of the two
alerting indications, where any contradictions or conflicts
between the two alerting indications are resolved in favor
of the intention of the first alerting indication.
6. Use Cases
This section describes some use cases for which the "alert" URN
mechanism is needed today.
6.1. PBX Ring Tones
This section defines some commonly encountered ring tones on PBX or
business phones. They are as listed in the following subsections.
6.1.1. Normal
This tone indicates that the default or normal ring tone should be
rendered. This is essentially a no-operation "alert" URN and should
be treated by the UA as if no "alert" URN is present. This is most
useful when Alert-Info header field parameters are being used. For
example, in [RFC7463], an Alert-Info header field needs to be present
containing the "appearance" parameter, but no special ring tone needs
to be specified.
6.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.
6.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.6.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).6.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".6.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.6.2. Service Tones
These tones are used to indicate specific PBX and public network telephony services.6.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, a callee's UA (or proxy) that is aware of the call-waiting condition can add the call-waiting indication to the Alert-Info header field in the 180 (Ringing) response.
6.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.6.2.3. Transfer Recall
This feature is used when a blind transfer [RFC5589] has been performed by a server on behalf of the transferor and fails. Instead of failing the call, the server calls back the transferor, giving them another chance to transfer or otherwise deal with the call. This service tone is used to distinguish this INVITE from a normal incoming call.6.2.4. Auto Callback
This feature is used when a user has utilized a server to implement an automatic callback service [RFC6910]. When the user is available, the server calls back the user and utilizes this service tone to distinguish this INVITE from a normal incoming call.6.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 a normal incoming call.6.3. Country-Specific Ringback Tone Indications for the Public Switched 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.7. URN Specification for the "alert" Namespace Identifier
This section provides the registration template for the "alert" URN namespace identifier (NID) according to [RFC2141] and [RFC3406]. Namespace ID: alert Registration Information: Registration version: 1 Registration date: 2014-12-10
Declared registrant of the namespace:
Registering organization: Real-time Applications and
Infrastructure Area, IETF
Designated contact: RAI Area Director
Designated contact email: rai-ads@ietf.org
Declaration of syntactic structure:
The Namespace Specific String (NSS) for the "alert" URNs is called
an <alert-identifier> and has a hierarchical structure. The first
colon-separated part after "alert" is called the <alert-category>;
the parts to the right of that are <alert-ind-part>s, and together
form the <alert-indication>. The general form is
urn:alert:<alert-category>:<alert-indication>.
The following <alert-category> identifiers are defined in this
document: "service" , "priority" , "source" , "duration", "delay",
and "locale". The <alert-category> set can be extended in the
future, either by standardization or by private action. The
<alert-category>s describe distinct features of alerting signals.
Any "alert" URN defined in this specification is syntactically
valid for ring and ringback tones and can be used in SIP INVITE
requests or in provisional 1xx responses excepting the 100
response.
The ABNF [RFC5234] for the "alert" URNs is shown below:
alert-URN = "urn:alert:" alert-identifier
alert-identifier = alert-category ":" alert-indication
alert-category = alert-name
alert-indication = alert-ind-part *(":" alert-ind-part)
alert-ind-part = alert-name
alert-name = alert-label / private-name
private-name = alert-label "@" provider
provider = alert-label
alert-label = 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
<alert-label>s MUST comply with the syntax for Non-Reserved LDH
labels [RFC5890]. Registered URNs and components thereof MUST be
transmitted as registered (including case).
Relevant ancillary documentation: RFC 7462
Namespace considerations: This specification defines a URN namespace
"alert" for URNs representing signals or renderings that are
presented to users to inform them of events and actions. The
initial usage is to specify ring tones and ringback tones when
dialogs are established in SIP, but they can also be used for
other communication-initiation protocols (e.g., H.323), and more
generally, in any situation (e.g., web pages or endpoint device
software configurations) to describe how a user should be
signaled.
An "alert" URN does not describe a complete signal, but rather it
describes a particular characteristic of the event it is signaling
or a feature of the signal to be presented. The complete
specification of the signal is a sequence of "alert" URNs
specifying the desired characteristics/significance of the signal
in priority order, with the most important aspects specified by
the earlier URNs. This allows the sender of a sequence of URNs to
compose very detailed specifications from a restricted set of
URNs, and to clearly specify which aspects of the specification it
considers most important.
The initial scope of usage is in the Alert-Info header field, in
initial INVITE requests (to indicate how the called user should be
alerted regarding the call) and non-100 provisional (1xx)
responses to those INVITE requests (to indicate the ringback, how
the calling user should be alerted regarding the progress of the
call).
In order to ensure widespread adoption of these URNs for
indicating ring tones and ringback tones, the scheme must allow
replication of the current diversity of these tones. Currently,
these tones vary between the PSTNs of different nations and
between equipment supplied by different vendors. Thus, the scheme
must accommodate national variations and proprietary extensions in
a way that minimizes the information that is lost during
interoperation between systems that follow different national
variations or that are supplied by different vendors.
The scheme allows definition of private extension URNs that refine
and extend the information provided by standard URNs. Private
extension URNs can also refine and extend the information provided
by other private extension URNs. Private extensions can also
define entirely new categories of information about calls. We
expect these extensions to be used extensively when existing PBX
products are converted to support SIP operation.
The device that receives an Alert-Info header field containing a
sequence of "alert" URNs provides to the user a rendering that
represents the semantic content of the URNs. The device is given
great leeway in choosing the rendering, but it is constrained by
rules that maximize interoperability between systems that support
different sets of private extensions. In particular, earlier URNs
in the sequence have priority of expression over later URNs in the
sequence, and URNs that are not usable in their entirety (because
they contain unknown extensions or are incompatible with previous
URNs) are successively truncated in attempt to construct a URN
that retains some information and is renderable in the context.
Due to the practical importance of private extensions for the
adoption of URNs for alerting calls and the very specific rules
for private extensions and the corresponding processing rules that
allow quality interoperation in the face of private extensions,
the requirements of the "alert" URN scheme cannot be met by a
fixed enumeration of URNs and corresponding meanings. In
particular, the existing namespace "urn:ietf:params" does not
suffice (unless the private extension apparatus is applied to that
namespace).
There do not appear to be other URN namespaces that uniquely
identify the semantic of a signal or rendering feature. Unlike
most other currently registered URN namespaces, the "alert" URN
does not identify documents and protocol objects (e.g., [RFC3044],
[RFC3120], [RFC3187], [RFC3188], [RFC4179], [RFC4195], [RFC4198]),
types of telecommunications equipment [RFC4152], people, or
organizations [RFC3043].
The <alert-URN>s are hierarchical identifiers. An <alert-URN>
asserts some fact or feature of the offered SIP dialog, or some
fact or feature of how it should be presented to a user, or of how
it is being presented to a user. Removing an <alert-ind-part>
from the end of an <alert-URN> (which has more than one <alert-
ind-part>) creates a shorter <alert-URN> with a less specific
meaning; the set of dialogs to which the longer <alert-URN>
applies is necessarily a subset of the set of dialogs to which the
shorter <alert-URN> applies. (If the starting <alert-URN>
contains only one <alert-ind-part>, and thus the <alert-ind-part>
cannot be removed to make a shorter <alert-URN>, we can consider
the set of dialogs to which the <alert-URN> applies to be a subset
of the set of all dialogs.)
The specific criteria defining the subset to which the longer
<alert-URN> applies, within the larger set of dialogs, is
considered to be the meaning of the final <alert-ind-part>. This
meaning is relative to and depends upon the preceding <alert-
category> and <alert-ind-part>s (if any). The meanings of two
<alert-ind-part>s that are textually the same but are preceded by
different <alert-category>s or <alert-ind-part>s have no necessary
connection. (An <alert-category> considered alone has no meaning
in this sense.)
The organization owning the <provider> within a <private-name>
specifies the meaning of that <private-name> when it is used as an
<alert-ind-part>. (The organization owning a <provider> is
specified by the registry described in Section 9.3.)
The organization owning the <provider> within a <private-name> (in
either an <alert-category> or an <alert-ind-part>) specifies the
meaning of each <alert-ind-part>, which is an <alert-label> that
follows that <private-name> and that precedes the next <alert-ind-
part> which is a <private-name> (if any).
The meaning of all other <alert-ind-part>s (i.e., those that are
not <private-name>s and do not follow a <private-name>) is defined
by standardization.
Community considerations: The "alert" URNs are relevant to a large
cross-section of Internet users, namely those that initiate and
receive communication connections via the Session Initiation
Protocol. These users include both technical and non-technical
users, on a variety of devices and with a variety of perception
capabilities. The "alert" URNs will allow Internet users to
receive more information about offered calls and enable them to
better make decisions about accepting an offered call, and to get
better feedback on the progress of a call they have made.
User interfaces that utilize alternative sensory modes can better
render the ring and ringback tones based on the "alert" URNs
because the URNs provide more detailed information regarding the
intention of communications than is provided by current SIP
mechanisms.
Process of identifier assignment:
Assignment of standardized "alert" URNs is by insertion into the
IANA registry described in Section 9.2. This process defines the
meanings of <alert-ind-part>s that have standardized meanings, as
described in "Namespace Considerations".
A new URN MUST NOT be registered if it is equal by the comparison
rules to an already registered URN.
Private extensions are "alert" URNs that include <alert-ind-part>s
that are <private-name>s and <alert-label>s that appear after a
<private-name> (either as an <alert-category> or an <alert-
indication>). If such an <alert-ind-part> is a <private-name>,
its meaning is defined by the organization that owns the
<provider> that appears in the <private-name>. If the <alert-ind-
part> is an <alert-label>, its meaning is defined by the
organization that owns the <provider> that appears in the closest
<private-name> preceding the <alert-label>. The organization
owning a <provider> is specified by the registry described in
Section 9.3.
Identifier uniqueness and persistence considerations: An "alert" URN
identifies a semantic feature of a call or a sensory feature of
how the call alerting should be a rendered at the caller's or
callee's end device.
For standardized <alert-ind-part>s in URNs, uniqueness and
persistence of their meanings is guaranteed by the fact that they
are registered with IANA in accordance with the procedures of
Section 9.2; the feature identified by a particular "alert" URN is
distinct from the feature identified by any other standardized
"alert" URN.
Assuring uniqueness and persistence of the meanings of private
extensions is delegated to the organizations that define private
extension <alert-ind-part>s. The organization responsible for a
particular <alert-ind-part> in a particular "alert" URN is the
owner of a syntactically determined <provider> part within the
URN.
An organization SHOULD use only one <provider> value for all of
the <private-name>s it defines.
Process for identifier resolution: The process of identifier
resolution is the process by which a rendering device chooses a
rendering to represent a sequence of "alert" URNs. The device is
allowed great leeway in making this choice, but the process MUST
obey the rules of Section 11.1. The device is expected to provide
renderings that users associate with the meanings assigned to the
URNs within their cultural context. A non-normative example
resolution algorithm is given in Section 12.1.
Rules for lexical equivalence: "alert" URNs are compared according
to case-insensitive string equality.
Conformance with URN syntax: All "alert" URNs must conform to the
ABNF in the "Declaration of Syntactic Structure" in Section 7.
That ABNF is a subset of the generic URN syntax [RFC2141].
<alert-label>s are constrained to be Non-Reserved LDH labels
[RFC5890], that is, "ordinary ASCII labels". Future
standardization may allow <alert-label>s that are A-labels
[RFC5890], and so interpreters of "alert" URNs MUST operate
correctly (per Section 11.1) when given such URNs as input.
Validation mechanism: An "alert" URN containing no private
extensions can be validated based on the IANA registry of
standardized "alert" URNs. Validating an "alert" URN containing
private extensions requires obtaining information regarding the
private extensions defined by the organization that owns the
<provider> in the relevant <private-name>. The identity of the
organization can be determined from the IANA registry described in
Section 9.2. However, if an "alert" URN contains at least one
<alert-identifier> that precedes the first <private-name>, the
portion of the "alert" URN that precedes the first <private-name>
must itself be a valid standardized "alert" URN, which may be
validated as above.
Scope: The scope for this URN is public and global.
8. "alert" URN Values
8.1. <alert-category> Values
The following <alert-category> values are defined in this document:
- service
- source
- priority
- duration
- delay
- locale
8.2. <alert-indication> Values
This section describes the "alert" URN indication values for the
<alert-category>s defined in this document.
For each <alert-category>, a default <alert-indication> is defined,
which is essentially a no-operation "alert" URN and should be treated
by the UA as if no "alert" URN for the respective category is
present. "alert" URN default indications are most useful when Alert-
Info header field parameters are being used. For example, in
[RFC7463], an Alert-Info header field needs to be present containing the "appearance" parameter, but no special ringtone need be specified. The <private-name> syntax is used for extensions defined by independent organizations, as described in Section 10.2.8.2.1. <alert-indication> Values for the <alert-category> "service"
- normal (default) - call-waiting - forward - recall:callback - recall:hold - recall:transfer - <private-name> Examples: <urn:alert:service:call-waiting> or <urn:alert:service:recall:transfer>.8.2.2. <alert-indication> Values for the <alert-category> "source"
- unclassified (default) - internal - external - friend - family - <private-name> (These <alert-indication>s will rarely be provided by the sending UA; rather they will usually be inserted by a proxy acting on behalf of the recipient UA to inform the recipient UA about the origins of a call.) Examples: <urn:alert:source:external>.8.2.3. <alert-indication> Values for the <alert-category> "priority"
- normal (default) - low - high - <private-name> Examples: <urn:alert:priority:high>.
8.2.4. <alert-Indication> Values for the <alert-category> "duration"
- normal (default) - short - long - <private-name> Examples: <urn:alert:duration:short>.8.2.5. <alert-indication> Values for the <alert-category> "delay"
- none (default) - yes - <private-name> Examples: <urn:alert:delay:yes>.8.2.6. <alert-indication> Values for the <alert-category> "locale"
- default (default) - country:<ISO 3166-1 country code> - <private-name> The ISO 3166-1 country code [ISO3166-1] is used to inform the renderer on the other side of the call that a country-specific rendering should be used. For example, to indicate ringback tones from South Africa, the following URN would be used: <urn:alert:locale:country:za>.
(page 20 continued on part 2)
