One document matched: draft-alexeitsev-bliss-alert-info-urns-02.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3261 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc1123 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1123.xml">
<!ENTITY rfc2141 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY rfc3406 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3406.xml">
<!ENTITY rfc4234 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4234.xml">
<!ENTITY rfc2434 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2434.xml">
<!ENTITY rfc3536 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3536.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-alexeitsev-bliss-alert-info-urns-02" ipr="pre5378Trust200902">
<front>
<title abbrev="Alert-Info URNs">Alert-Info URNs for the Session Initiation
Protocol (SIP)</title>
<author fullname="Denis Alexeitsev" initials="D." surname="Alexeitsev">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Friedrich-Ebert-Allee</street>
<city>Bonn</city>
<code>53113</code>
<country>Germany</country>
</postal>
<phone>+49-228-18112010</phone>
<email>d.alexeitsev@telekom.de</email>
</address>
</author>
<author fullname="Laura Liess" initials="L." surname="Liess">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Heinrich-Hertz Str 3-7</street>
<city>Darmstadt</city>
<code>64295</code>
<region>Hessen</region>
<country>Germany</country>
</postal>
<phone>+49-6151-6282761</phone>
<email>l.liess@telekom.de</email>
</address>
</author>
<author fullname="Roland Jesske" initials="R." surname="Jesske">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Heinrich-Hertz Str 3-7</street>
<city>Darmstadt</city>
<code>64295</code>
<region>Hessen</region>
<country>Germany</country>
</postal>
<phone>+49-6151-6282766</phone>
<email>r.jesske@telekom.de</email>
</address>
</author>
<author fullname="Martin Huelsemann" initials="M." surname="Huelsemann">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street>Heinrich-Hertz Str 3-7</street>
<city>Darmstadt</city>
<code>64295</code>
<region>Hessen</region>
<country>Germany</country>
</postal>
<phone>+49-6151-6282765</phone>
<email>martin.huelsemann@telekom.de</email>
</address>
</author>
<author fullname="Alan Johnston" initials="A." surname="Johnston">
<organization>Avaya</organization>
<address>
<postal>
<city>St. Louis</city>
<code>63124</code>
<region>MO</region>
<country>United States</country>
</postal>
<phone></phone>
<email>alan@sipstation.com</email>
</address>
</author>
<date month="July" year="2009"/>
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>BLISS</workgroup>
<keyword>SIP</keyword>
<keyword>Alert-Info</keyword>
<keyword>URN</keyword>
<abstract>
<t>The Session Initiation Protocol (SIP) supports the capability to
provide a reference to the alternative ringback tone (RBT) for caller,
or ring tone (RT) for callee using the Alert-Info header. However, the
reference addresses only the network resources with specific rendering
properties. There is currently no support for predefined standard
identifiers for ringback tones or semantic indications without tied
rendering. To overcome this limitations and support new applications a
family of the URNs is defined in this specification.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref target="RFC2119"></xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>The Session Initiation Protocol (SIP) <xref target="RFC3261"></xref>
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.
Current solution is sufficient for human users that share the same
understanding of the tones. However 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. Another limitation of the current solution is that the
referenced tones are tied to particular rendering. It is not possible to
provide a semantic indication that signals the intent and allows the
recipient to decide how to render the received information in an
appropriate way.</t>
<t>To solve the described issues and support new applications this
specification defines the new URN namespace 'alert' for the Alert-Info
header that can be understood by an automaton, would allow for
programmatic handling, including user interface adaptation, or
conversion to equivalent protocol parameters in the Public Switched
Telephone Network (PSTN) when the client is a gateway.</t>
<t>Using 'alert' namespace provides syntax for several different
application spaces:<list style="symbols">
<t>Names for common ring-tones generated by PBX phone for cases such
as an internal enterprise caller, external caller, ringback after a
transfer failure or expiration of a hold timer, etc.</t>
<t>Names for services such as call waiting or automatic callback,
not tied to any particular rendering.</t>
<t>Names for things with specific renderings that aren't purely
audio. They might be static icons, video sequences, text, etc.</t>
</list></t>
<t>Some advantages of a URN rather than a URI reference to a
downloadable resource:</t>
<t><list style="symbols">
<t>Do not need to download it or deal with security issues
associated with dereferencing.</t>
<t>No formatting or compatibility issues.</t>
<t>No security risk of rendering something unexpected and
undesirable.</t>
<t>The tone can be stored locally in whatever format and at whatever
quality level is appropriate.</t>
</list>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.</t>
</section>
<section title="Registration template">
<t>Below is the registration template for the 'alert' URN scheme
according to the <xref target="RFC3406">RFC 3406</xref></t>
<t><list style="hanging">
<t hangText="Namespace ID:">alert</t>
<t hangText="Registration Information:"/>
<list sytle="hanging">
<t hangText="Registration version:">1</t>
<t hangText="Registration date:">TBD</t>
</list>
<t hangText="Declared registrant of the namespace:"/>
<list style="hanging">
<t hangText="Registering organization:">IETF</t>
<t hangText="Designated contact:">Laura Liess</t>
<t hangText="Designated contact email:">l.liess@telekom.de</t>
</list>
<t hangText="Declaration of syntactic structure:"/>
<t>Namespace Specific String (NSS) in the for the "alert" URNs is
called alert-identifier and has a hierarchical structure. The
left-most label is called "alert-category" and is separated from
right-side of the alert-identifier, the alert-indication, by a
semicolon. In this specification, two categories of
alert-identifiers are described: the "tone" alert-identifiers and
the "service" alert-identifiers.</t>
<t>The "tone" alert-identifier has the general form:</t>
<list>
<t>urn:alert:tone:{tone-indication}</t>
</list>
<t>where the tone-indication identifies the semantic of a tone.</t>
<t/>
<t style="hanging">The "service" alert-identifier has the general
form:</t>
<list>
<t>urn:alert:service:{service-indication}</t>
</list>
<t>where the service-indication is a unique identifier for a service
as call-waiting or transfer-recall.</t>
<t>The tone-indication and service-indication are hierarchical
identifiers, consisting of one label or a sequence of labels
separated by periods. The left-most label is the most significant
one and is called 'top-level indication' , while names to the right
are called 'sub-indication'. The set of allowable characters is the
same as that for domain names <xref target="RFC1123"/>. Labels are
case-insensitive, but MUST be specified in all lower-case.</t>
<t>Labels can be removed right-to-left excepting the left-most
label; the resulting tone-indication or service-indication is still
valid, referring to a more generic tone-indication or
service-indication. In other words, if a tone 'x.y.z' exists, the
tone 'x' and 'x.y' are also valid tone. Each alert indication
identifier SHALL explicitly define it's validity respective the
sub-indications.</t>
<t/>
<t>The ABNF <xref target="RFC4234"/> for the "tone" and "service"
alert URNs is shown below:</t>
<t>
<figure>
<artwork><![CDATA[
alert-URN = "URN:alert:" alert-identifier
alert-identifier= alert-category ":" alert-indication
alert-category = "tone"/"service"
alert-indication= top-level *("." sub-indication)
top-level = let-dig [ *25let-dig-hyp let-dig ]
sub-indication = let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp = let-dig / "-"
let-dig = ALPHA / DIGIT
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
]]></artwork>
</figure>
</t>
<t hangText="Relevant ancillary documentation:">None</t>
<t hangText="Community considerations:">The alert URN is believed to
be relevant to a large cross-section of Internet users, including
both technical and non-technical users, on a variety of devices and
with a variety of perception capabilities. The 'alert' URN will
allow Internet users to receive more information and enable them to
better make decisions about accepting an offered call, or get better
feedback on the progress of a call they have made. User interfaces
for the perception impaired users can better render the ringback
indication based on the 'alert' URN. The assignment of identifiers
is described in the IANA Considerations (<xref target="IANA"/>).
The 'alert' URN does not prescribe a particular resolution
mechanism, but it is assumed that a number of different entities
could operate and offer such mechanisms.</t>
<t hangText="Namespace considerations:">There do not appear to be
other URN namespaces that serve the same need of uniquely
identifying 'alert' communication and information services.</t>
<t hangText="Identifier uniqueness considerations:">An 'alert' URN
identifies a logical service or tone, specified in the 'alert'
indication registration (see IANA Considerations (<xref target="IANA"/>)). 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 (<xref target="IANA"/>).</t>
<t hangText="Identifier persistence considerations:">The 'alert' URN
for the same indication is expected to be persistent, as long as it
is registered with IANA.</t>
<t hangText="Process of identifier assignment:">The process of
identifier assignment is described in the IANA Considerations (<xref target="IANA"/>).</t>
<t hangText="Process for identifier resolution:">'alert' URNs are
statically resolved according to the IANA registry.</t>
<t hangText="Rules for lexical equivalence:">'alert' URNs are
compared according to case-insensitive string equality.</t>
<t hangText="Conformance with URN syntax:">The BNF in the
'Declaration of syntactic structure' above constrains the syntax for
this URN scheme.</t>
<t hangText="Validation mechanism:">Validation determines whether a
given string is currently a validly-assigned URN <xref target="RFC3406"/>. Static validation is performed based on the
currently registered 'alert' URNs at IANA.</t>
<t hangText="Scope:">The scope for this URN is public and
global.</t>
</list></t>
</section>
<section title="Top Level Alert URN Indication Definitions">
<t>This section describes the use cases that are supported by the
'alert' URNs.</t>
<section title="PBX Tones">
<t>This section defines some commonly encountered ring-tones on PBX or
business phones. They are as follows:</t>
<section title="normal">
<t>This tone indicates that the default or normal ring-tone should
be rendered. This is most useful when Alert-Info header field
parameters are being used. For example, in <xref target="I-D.ietf-bliss-shared-appearances"/>, an
Alert-Info header field needs to be present containing the "appearance" parameter, but no special ringtone need be specified. If no special alerting is to be used, urn:alert:tone:normal
should be used.</t>
</section>
<section title="external">
<t>This tone is used to indicate that the caller is external to the
enterprise or PBX system. This could be a call from the PSTN or from
a SIP trunk. For this case, urn:alert:tone:external should be
used.</t>
</section>
<section title="internal">
<t>This tone is used to indicate that the caller is internal to the
enterprise or PBX system. The call could have been originated from
another user on this PBX or on another PBX within the enterprise.
For this case, the urn:alert:tone:internal should be used.</t>
</section>
</section>
<section title="Service Tones">
<t>These tones are used to indicate specific PBX and telephony
services. </t>
<section title="call-waiting">
<t>The call waiting Service <xref target="TS24.615"></xref> permits
a callee to be notified of an incoming call whilst the media
resources are not available for the incoming call and the callee is
engaged in an active or held call. Subsequently, the callee can
either accept, reject, or ignore the incoming call. There is an
interest on the caller side to be informed about the call waiting
situation on the callee side. Having this information the caller can
decide whether to continue waiting for callee to pickup or better to
call some time later when it is estimated that the callee could have
finished the ongoing conversation. To provide this information, the
callee's UAS or proxy aware of the call waiting condition can add
the call-waiting indication URN to the Alert-Info header. As
call-waiting information may be subject to the callee's privacy
concerns, the exposure of this information SHALL be done only if
explicitly required by the user. The urn:alert:service:call-waiting
should be used for this case.</t>
</section>
<section title="forward">
<t>This feature is used in a 180 response when a call forwarding feature has been initiated on an INVITE. Many PBX system implement a forwarding "beep" followed by normal ringing to indicate this. The urn:alert:service:forward should be used for this case. Note that a 181 response can be used in place of this URN.</t>
</section>
<section title="transfer-recall">
<t>This feature is used when a blind transfer <xref target="RFC5589"/> has been
performed by a server on behalf of the transferor and fails. Instead
of failing the call, the server calls back the transferor, giving
them another chance to transfer or otherwise deal with the call.
This service tone is used to distinguish this INVITE from any other
normal incoming call. The urn:alert:service:transfer-recall should
be used for this case.</t>
</section>
<section title="auto-callback">
<t>This feature is used when a user has utilized a server to
implement an automatic callback service. When the user is available,
the server calls back the user and utilizes this service tone to
distinguish this from any other normal incoming call. The
urn:alert:service:auto-callback should be used for this case.</t>
</section>
<section title="hold-recall">
<t>This feature is used when a server implements a call hold timer on
behalf of an endpoint. After a certain period of time of being on
hold, the user who placed the call on hold is alerted to either
retrieve the call or otherwise dispose of the call. This service
tone is used to distinguish this case from any other normal incoming
call. The urn:alert:service:hold-recall should be used for this
case.</t>
</section>
<section title="crisis">
<t>This feature is used for emergency announcements sent over PBX
systems such as building evacuations, alarms, etc. This service tone
is used to distinguish this case from any other normal incoming
call. The urn:alert:service:crisis should be used for this case.</t>
</section>
</section>
</section>
<section title="Alert Level URN Sub-Indications Definitions">
<t>These sub-indications can be applied to any of the Top Level Alert
Indications defined in the previous sections.</t>
<section title="priority">
<t>This sub-level is used to indicate that a priority level alert
should be applied for the type of alerting specified. For example,
urn:alert:tone:internal.priority would be used to generate alerting
for a priority internal PBX call.</t>
</section>
<section title="short">
<t>This sub-level is used to indicate that the alert type specified
should be rendered shorter than normal. In contact centers, this is
sometimes referred to as "abbreviated ringing" or a "zip tone". For
example, urn:alert:tone:normal.short would generate a shorter than
normal ring-tone.</t>
</section>
<section title="delayed">
<t>This sub-level is used to indicate that the alerting type specified
show be rendered after a short delay. In some bridged line/shared line
appearance implementations, this is used so that the bridged line does
not ring at exactly the same time as the main line, but is delayed a
few seconds. For example, urn:alert:tone:external.delayed would
generate an external ring-tone, delayed by a few seconds.</t>
</section>
</section>
<section title="User Agent Behavior">
<t>Upon receiving a SIP request or a SIP 180 Ringing response with an
Alert-Info header that contains a single or multiple 'alert' URNs, the
User Agent (UA) attempts to match the received URNs with the known
indications. If no match is found, the User Agent (UA) ignores the
received 'alert' URNs and proceeds with the normal operation. If the one
or multiple URNs matches a known indication, the User Agent (UA) renders
the indication(s) to the user according to the tone or
service identifier in the received alert URN. The User Agent (UA) is
responsible for the non disturbing rendering if multiple indications and
network resources are to be rendered simultaneously.</t>
</section>
<section title="Proxy Behavior">
<t></t>
<t>A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
in a SIP request or a 180 Ringing provisional response when it needs to
provide additional information about the call or about the provided
service. A SIP Proxy SHOULD NOT add a mixture of the 'alert' URNs and
URIs to the Alert-Info header that may cause disturbing rendering
interference at the recepient's User Agent (UA).</t>
<t>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.</t>
<t><figure>
<artwork><![CDATA[ Alert-Info: <http://www.example.com/sound/moo.wav>,
<urn:alert:service:call-waiting>]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This section registers a new URN scheme with the registration
template provided in section Registration Template.</t>
<t>Below, the section 7.1 details how to register new alert-identifiers.
Descriptions of alert-indications for the first two alert-identifiers
described in this document , service and tone, are given in Section 7.2
and Section 7.3, respectively. Finally, Section 7.4 contains the initial
registration table.</t>
<section title="New alert-identifiers">
<t>Alert URNs identifiers and alert-indications are identified by
labels managed by IANA, according to the processes outlined in <xref target="RFC2434"></xref> in a new registry called "Alert URN Labels".
Thus, creating a new alert-identifier requires IANA action. The policy
for adding a new alert-identifier category is 'Standards Action'.
(This document defines the alert-identifier categories 'service' and
'tone'.) The policy for assigning labels to alert-indications may
differ for each alert-identifier category and MUST be defined by the
document describing the coresponding alert-identifier.</t>
<t>Entries in the registration table have the following format:</t>
<t><figure>
<artwork><![CDATA[ Category/Indication Reference Description
--------------------------------------------------------------------
foo RFC XXXX Description of the 'foo' alert-category
bar RFC YYYY Description of the 'bar' alert-indication
of the foo alert-category
bar.moo RFC ZZZZ Description of the 'bar.moo'
alert-indication of the foo alert-category
]]></artwork>
</figure></t>
<t>Each alert-category or alert-indication label MUST NOT exceed 27
characters.</t>
</section>
<section title="Alert-category">
<t>This section defines the alert-identifier registration within the
IANA registry defined in Section 7.1, using the alert-category labels
'service' and 'tone'.</t>
<t>The 'tone' alert-category label provides information about ringing
tones generated by a UAS and rendered to the callee in response to an
INVITE.</t>
<t>The 'service' alert-category label describes tones that should be
generated by the UAC or UAS and rendered to the caller or calee upon
receipt of a 180 response or a request. The normal rendering is audio,
however there can be other renderings applicable if needed by the user
interface specifics.</t>
</section>
<section title="Initial IANA Registration">
<t>The following table contains the initial IANA registration for
"tone" alert-indications.</t>
<t><figure>
<artwork><![CDATA[
Alert-Indication Reference Description
--------------------------------------------------------
normal RFC XXXX Normal ring-tone
normal.priority RFC XXXX Priority normal ring-tone
normal.short RFC XXXX Short normal ring-tone
normal.delayed RFC XXXX Delayed normal ring-tone
internal RFC XXXX Internal PBX caller PBX ring-tone
internal.priority RFC XXXX Priority internal PBX caller PBX ring-tone
internal.short RFC XXXX Short internal PBX caller PBX ring-tone
internal.delayed RFC XXXX Delayed internal PBX caller PBX ring-tone
external RFC XXXX External PBX caller PBX ring-tone
external.priority RFC XXXX Priority external PBX caller PBX ring-tone
external.short RFC XXXX Short external PBX caller PBX ring-tone
external.delayed RFC XXXX Delayed external PBX caller PBX ring-tone
]]></artwork>
</figure></t>
<t>The following table contains the initial IANA registration for
"service" alert-indications.</t>
<t><figure>
<artwork><![CDATA[
Alert-Indication Reference Description
--------------------------------------------------------
call-waiting RFC XXXX Call waiting service indication
forward RFC XXXX Call forwarding service indication
transfer-recall RFC XXXX Transfer Recall service indication
auto-callback RFC XXXX Auto Callback service indication
hold-recall RFC XXXX Hold Recall service indication
crisis RFC XXXX Crisis alerting indication
]]></artwork>
</figure></t>
<t>Editor's Note: RFC XXXX should be replaced with this
specification.</t>
</section>
</section>
<section title="Internationalization Considerations ">
<t>The alert-identifier labels are protocol elements <xref target="RFC3536"></xref> and are not normally seen by users. Thus, the
character set for these elements is restricted, as described in Section
6.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>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.</t>
<t>Provision of the specific indications from callee to caller may raise
privacy issues. Such provision SHALL always be explicitly authorised by
the callee.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The draft is based on the ideas expressed by Paul Kyzivat on the
BLISS WG mailing list.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.1123.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.2141.xml"?>
<?rfc include="reference.RFC.3261.xml"?>
<?rfc include="reference.RFC.3406.xml"?>
<?rfc include="reference.RFC.4234.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-bliss-shared-appearances" ?>
<?rfc include="reference.RFC.5589.xml"?>
<?rfc include="reference.RFC.2434.xml"?>
<?rfc include="reference.RFC.3536.xml"?>
<reference anchor="TS24.615">
<front>
<title>3GPP TS 24.615 Communication Waiting (CW) using IP Multimedia
(IM) Core Network (CN) subsystem</title>
<author>
<organization></organization>
</author>
<date/>
</front>
</reference>
</references>
<section title="An Appendix">
<t></t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:40:16 |