doc: Add RFC documents

1 files changed, 2579 insertions, 0 deletions

diff --git a/doc/rfc/rfc7462.txt b/doc/rfc/rfc7462.txt
new file mode 100644
index 0000000..deb5be1
--- /dev/null
+++ b/doc/rfc/rfc7462.txt
@@ -0,0 +1,2579 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                    [Page 1]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                    [Page 2]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+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
+
+
+
+
+Liess, et al.                Standards Track                    [Page 3]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+                  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
+
+
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                    [Page 4]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+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.
+
+
+
+Liess, et al.                Standards Track                    [Page 5]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   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.
+
+
+
+
+
+Liess, et al.                Standards Track                    [Page 6]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   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.
+
+
+
+Liess, et al.                Standards Track                    [Page 7]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   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
+
+
+
+Liess, et al.                Standards Track                    [Page 8]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   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.)
+
+
+
+
+Liess, et al.                Standards Track                    [Page 9]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   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.
+
+
+
+Liess, et al.                Standards Track                   [Page 10]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+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.
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 11]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+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
+
+
+
+Liess, et al.                Standards Track                   [Page 12]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   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
+
+
+
+
+Liess, et al.                Standards Track                   [Page 13]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   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.
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 14]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+      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-
+
+
+
+Liess, et al.                Standards Track                   [Page 15]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+      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.
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 16]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+      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.
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 17]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   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
+
+
+
+
+Liess, et al.                Standards Track                   [Page 18]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   [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>.
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 19]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+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>.
+
+9.  IANA Considerations
+
+9.1.  URN Namespace Identifier "alert"
+
+   This section registers a new URN namespace identifier (NID), "alert",
+   in accordance with [RFC3406] with the registration template provided
+   in Section 7.
+
+9.2.  'Alert URN Identifiers' Registry
+
+   Standard "alert" URNs are recorded as <alert-identifier>s in a new
+   registry called "Alert URN Identifiers".  Thus, creating a new
+   standard "alert" URN requires IANA action.  IANA manages the "Alert
+   URN Identifiers" registry under the policy 'Specification Required'
+   [RFC5226] following the guidelines in Section 10.1.
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 20]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   The registry contains entries in the following formats:
+
+      <alert-category>/      Reference    Description
+      <alert-identifier>
+      ---------------------------------------------------------------
+      foo                    [RFCxyz]     Description of the 'foo'
+                                          <alert-category>;
+      foo:bar                [RFCabc]     Description of the 'foo:bar'
+                                          <alert-identifier>
+
+      foo:<range>            [RFCdef]     Description of the
+      'foo:<category>'                    <alert-identifer>s (which will
+                                          reference the <range> value)
+
+   The first value in each row is the value that is registered, which is
+   either: (1) an <alert-category> value, (2) an <alert-identifier>
+   value, composed of an <alert-category> followed by an <alert-
+   indication>, in turn composed of one or more <alert-label>s, or (3) a
+   pattern for <alert-identifier> values (e.g., for the "locale" <alert-
+   category> in Section 9.2.1.6).
+
+   The second value in each row is the reference to the required
+   specification for the value.
+
+   The third value in each row is a short description of the semantics
+   of the value.
+
+   A new URN MUST NOT be registered if it is equal by the comparison
+   rules (that is, case-insensitive string comparison) to an already
+   registered URN.
+
+   <alert-category> and <alert-identifier> values that contain <private-
+   name>s are not managed by IANA.  The process of assigning these
+   values is described in Section 10.2.
+
+9.2.1.  Initial IANA Registration
+
+   This document defines the <alert-category>s 'service', 'source',
+   'priority', 'duration', 'delay' and 'locale'.  The entries to be
+   added to the 'Alert URN Identifiers' registry table for each <alert-
+   category> are given in the respective sections below.
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 21]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+9.2.1.1.  The "service" <alert-category> and <alert-identifier>s
+
+   The following table contains the initial IANA registration for the
+   "service" <alert-category> and <alert-identifier>s.  The value of
+   this indicator is set to a value different from "normal" if the
+   caller or callee is informed that a specific telephony service has
+   been initiated.
+
+   <alert-category>/              Reference  Description
+   <alert-identifier>
+   -----------------------------------------------------------
+   service                        RFC 7462   Specific telephony
+                                             service used in this
+                                             call
+
+   service:normal                 RFC 7462   Normal ring/ringback
+                                             rendering (default value)
+
+   service:call-waiting           RFC 7462   Call waiting was
+                                             initiated at the other side
+                                             of the call
+
+   service:forward                RFC 7462   Call has been forwarded
+
+   service:recall:callback        RFC 7462   Recall due to callback
+
+   service:recall:hold            RFC 7462   Recall due to call hold
+
+   service:recall:transfer        RFC 7462   Recall due to transfer
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 22]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+9.2.1.2.  The "source" <alert-category> and <alert-identifier>s
+
+   The following table contains the initial IANA registration for the
+   "source" <alert-category> and <alert-identifier>.  The value of this
+   indicator provides information about the user at the other side of
+   the call.
+
+   <alert-category>/             Reference  Description
+   <alert-identifier>
+   -----------------------------------------------------------
+   source                        RFC 7462   Classification
+                                            of the other party
+                                            to the call
+
+   source:unclassified           RFC 7462   Unclassified ring/ringback
+                                            rendering (default value)
+
+   source:internal               RFC 7462   User at the other side of
+                                            the call is internal to the
+                                            enterprise or PBX system
+
+   source:external               RFC 7462   User at the other side of
+                                            the call is external to the
+                                            enterprise or PBX system
+
+   source:friend                 RFC 7462   User at the other side of
+                                            the call is a friend
+
+   source:family                 RFC 7462   User at the other side of
+                                            the call is a family member
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 23]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+9.2.1.3.  The "priority" <alert-category> and <alert-identifier>s
+
+   The following table contains the initial IANA registration for the
+   "priority" <alert-category> and <alert-identifier>s.  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 7462   Priority of the
+                                              call
+
+   priority:normal                 RFC 7462   Normal ring/ringback
+                                              rendering (default value)
+
+   priority:low                    RFC 7462   Low priority call
+
+   priority:high                   RFC 7462   High priority call
+
+9.2.1.4.  The "duration" <alert-category> and <alert-identifier>s
+
+   The following table contains the initial IANA registration for the
+   "duration" <alert-category> and <alert-identifier>s.  The value of
+   this indicator provides information about the duration of the
+   alerting signals compared to the default alerting signals.
+
+  <alert-category>/               Reference  Description
+  <alert-identifier>
+  -----------------------------------------------------------
+  duration                        RFC 7462   Duration of alerting signal
+
+  duration:normal                 RFC 7462   Normal ring/ringback
+                                             rendering (default value)
+
+  duration:short                  RFC 7462   Shorter than normal
+
+  duration:long                   RFC 7462   Longer than normal
+
+
+
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 24]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+9.2.1.5.  The "delay" <alert-category> and <alert-identifier>s
+
+   The following table contains the initial IANA registration for the
+   "delay" <alert-category> and <alert-identifier>s.  The value of this
+   indicator provides information about whether the presentation of the
+   alerting signal should be delayed compared to the default
+   presentation process.  For more details see Section 6.1.6.
+
+   <alert-category>/            Reference  Description
+   <alert-identifier>
+   -----------------------------------------------------------
+   delay                        RFC 7462   Delay of rendering
+                                           of alerting signal
+
+   delay:none                   RFC 7462   Immediate alerting
+                                           (default value)
+
+   delay:yes                    RFC 7462   Delayed alerting
+
+
+9.2.1.6.  The "locale" <alert-category> and <alert-identifier>s
+
+   The following table contains the initial IANA registration for the
+   "locale" <alert-category> and <alert-identifier>s.  The value of this
+   indicator provides information about whether the alerting signals
+   characteristic of the specified location should be used.
+
+   <alert-category>/             Reference  Description
+   <alert-identifier>
+   -----------------------------------------------------------
+   locale                        RFC 7462   Location-specific
+                                            alerting signals
+
+   locale:default                RFC 7462   Alerting not location
+                                            specific
+                                            (default value)
+
+   locale:country:<ISO 3166-1 country code>
+                                 RFC 7462   Alerting according to the
+                                            conventions of the specified
+                                            country
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 25]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+9.3.  'Alert URN Providers' Registry
+
+   Values of <provider>, which are used to create <private-name>s, are
+   recorded in a new registry called "Alert URN Providers".  (Private
+   extension "alert" URNs that are defined are not recorded by IANA.)
+   The registry is managed by IANA under the policy 'First Come First
+   Served' [RFC5226].
+
+   The registry contains entries in the following format:
+
+   <provider>             Registrant       Contact URI
+   ---------------------------------------------------------------------
+   example                IETF             rai-ads@ietf.org
+
+   The first value in each row is the <provider> value that is
+   registered.  This value is case-insensitive and MUST comply with the
+   syntax for Non-Reserved LDH labels [RFC5890].
+
+   The second value in each row is the name of the registrant of the
+   value.
+
+   The third value is a contact URI for the registrant.
+
+   The registry initially contains the one entry shown above, which can
+   be used for constructing examples of private extension URNs.
+
+10.  Extension Rules
+
+10.1.  General Extension Rules
+
+   The set of "alert" URNs is extensible.  An extension "at the top
+   level" creates a new <alert-category> (which represents a new
+   alerting characteristic), an extension "at the second level" creates
+   a new <alert-indication> value for an existing <alert-category>, an
+   extension "at the third level" creates a subdivision of an existing
+   <alert-indication> (that has one <alert-ind-part>), etc.  URNs allow
+   (in principle) indefinite subdivision of existing <alert-indication>
+   values, although most of the standard "alert" URNs have only one
+   level of subdivision and a few have two levels of subdivision.
+
+   Extensions, either standard or private, MUST conform to the following
+   principles:
+
+   A new <alert-category> is independent of all previously existing
+   <alert-category>s: For any combination of one <alert-identifier> in
+   the new <alert-category> with any one <alert-identifier> in any of
+   the previously existing <alert-category>s, there are potential calls
+   to which the combination can be meaningfully applied.
+
+
+
+Liess, et al.                Standards Track                   [Page 26]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   A new <alert-identifier> that has more than one <alert-ind-part> is a
+   semantic refinement of a parent <alert-identifier>, the parent being
+   obtained by deleting the final <alert-ind-part>.  The new <alert-
+   identifier> has as parent the most specific previously existing
+   <alert-identifier> whose meaning includes all potential calls to
+   which the new <alert-identifier> could be meaningfully applied.
+
+   A new <alert-identifier> has no semantic overlap with any sibling
+   <alert-identifier> (<alert-identifier>s that differ only in the final
+   <alert-ind-part>).  That is, there could be no call to which both
+   <alert-identifier>s could be meaningfully applied.
+
+   The process for defining new standard "alert" URNs is described in
+   Section 9.2; all such definitions require registering a publicly
+   available specification.  The process for defining new "alert" URNs
+   via the private extension mechanism is described in Section 10.2.
+
+10.2.  Private Extension Rules
+
+   The <private-name> syntax is used to create private extensions,
+   extensions that are not registered with IANA.  The <private-name> has
+   the form of an <alert-label> followed by "@" and then a <provider>
+   that designates the organization defining the extension.  Both
+   <alert-label> and <provider> have the same syntax as an ordinary
+   ASCII DNS label.  A private extension URN is created by using a
+   <private-name> as either an <alert-category> or an <alert-ind-part>.
+
+   If the <private-name> is used as an <alert-category>, the
+   characteristic of the alerting signal that the <alert-category>
+   describes is defined by the organization.  If the <private-name> is
+   used as the first <alert-ind-part>, the organization defines an
+   alternative value for the standardized <alert-category> of the URN.
+   If the <private-name> is used as the second or later <alert-ind-
+   part>, the organization defines the meaning of the URN as a subset of
+   the meaning of the shorter URN resulting when the <private-name> (and
+   any subsequent <alert-ind-part>s) are removed.
+
+   Within a URN, all <alert-label> components that follow a <private-
+   name> but are before any following <private-name>s are additional
+   private extensions whose meaning is defined by the organization
+   defining the nearest preceding <private-name>.
+
+   A URN that contains a private extension can be further subdivided by
+   the private extension of a different organization: the second
+   organization appends an <alert-ind-part> that is a <private-name>
+   containing a the <provider> value for the second organization.
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 27]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   The meaning of a <private-name> or an <alert-label> that is defined
+   privately (because of a preceding <private-name>) is only fixed
+   within the context provided by the sequence of preceding
+   <alert-name>s; these components have no meaning in isolation and
+   there is no necessary relationship between the meaning of textually
+   identical <alert-name>s that are preceded by different sequences of
+   <alert-name>s.
+
+   Creating private extension "alert" URNs is not a Standards Action and
+   they are not registered with IANA.
+
+   The organization defining a private extension is responsible for
+   ensuring persistence of the meaning of the private extension.
+
+   Private extensions MUST conform to the principles of Section 10.1,
+   both in regard to previously existing standard <alert-URN>s and in
+   regard to any previously existing private extensions using the same
+   <provider> value, and any other private extensions that the
+   organization is aware of.  In particular, a private extension MUST
+   NOT duplicate any standard URN or any private extension that the
+   organization is aware of.  (In either of those cases, the
+   organization MUST use the existing URN for its purposes.)
+
+   An organization obtains a <provider> value for constructing <private-
+   name>s by registering the value with IANA as provided in Section 9.3.
+
+10.3.  Examples
+
+10.3.1.  Subsetting an Existing URN
+
+   The organization registering the <provider> "example" can define
+   distinctive versions of <urn:alert:service:call-waiting>:
+
+      urn:alert:service:call-waiting:abc@example
+
+      urn:alert:service:call-waiting:def@example
+
+   It can create a more specialized URN that applies to a subset of the
+   situations to which the first URN above applies:
+
+      urn:alert:service:call-waiting:abc@example:xyz
+
+   Because "xyz" follows "abc@example" (and there is no intervening
+   <private-name>), its meaning is defined by the owner of the
+   <provider> "example".
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 28]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+10.3.2.  A New Value within an <alert-category>
+
+   The organization registering the <provider> "example" can define URNs
+   in the "service" category to express a new service that is not
+   covered by any of the standardized URNs:
+
+      urn:alert:service:ghi@example
+
+   However, before defining such a URN, the organization should verify
+   that the set of calls to which the URN applies is not a subset of the
+   set of calls for some existing URN.  If it is a subset, the extension
+   URN should be a subdivision of the existing URN.
+
+10.3.3.  A New <alert-category>
+
+   The organization registering the <provider> "example" can define an
+   extension <alert-category> named "jkl@example" with two <alert-
+   indication>s "a1" and "a2":
+
+      urn:alert:jkl@example:a1
+
+      urn:alert:jkl@example:a2
+
+10.3.4.  Subsetting a Private Extension URN
+
+   The organization registering the <provider> "foo" wants to define a
+   set of URNs that specify the different ring patterns used by a
+   "distinctive ring" service to alert for incoming calls that are
+   directed to different directory numbers.  These ring patterns are
+   composed of groups of ring sounds that have particular patterns of
+   lengths.
+
+   The company can create a private <alert-category> "distinctive@foo",
+   and within it assign three 'alert' URNs that indicate the three
+   different ring patterns used by the company's service:
+
+      urn:alert:distinctive@foo:long-long
+
+      urn:alert:distinctive@foo:short-long-short
+
+      urn:alert:distinctive@foo:short-short-long
+
+   Later, the company registering the <provider> "bar" wants to define
+   an additional 'alert' URN for the ring pattern "short short", which
+   it uses to support a fourth directory number for a phone instrument.
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 29]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   The company can create a <private-name> to be used with the
+   "distinctive@foo" <alert-category>:
+
+      urn:alert:distinctive@foo:short-short@bar
+
+11.  Combinations of "alert" URNs
+
+11.1.  Priority Rules
+
+   This section describes combination rules for the case when all the
+   Alert-Info header fields only contain "alert" URNs.  Other
+   combinations of URIs in the Alert-Info header fields of the same SIP
+   message are not defined in this specification.
+
+   In many cases, more than one URN will be needed to fully define a
+   particular tone.  This is done by including multiple "alert" URNs, in
+   one or more Alert-Info header fields in a request or a response.  For
+   example, an internal, priority call could be indicated by Alert-Info:
+   <urn:alert:source:internal>, <urn:alert:priority:high>.  A priority
+   call-waiting tone could be indicated by Alert-Info:
+   <urn:alert:service:call-waiting>, <urn:alert:priority:high>.
+
+   The sender of the Alert-Info header field may include an arbitrary
+   list of "alert" URNs, even if they are redundant or contradictory.
+   An earlier URN has priority over any later contradictory URN.  This
+   allows any element to modify a list of URNs to require a feature
+   value (by adding a URN at the beginning of the list) or to suggest a
+   feature value (by adding a URN at the end of the list).
+
+   The receiving UA matches the received "alert" URN combination with
+   the signal(s) it is able to render.
+
+   The implementation is free to ignore an "alert" URN if it does not
+   recognize the URN, or if it is incapable of rendering its effect in
+   the context.  Similarly, it can remove a final series of one or more
+   <alert-ind-part>s of an "alert" URN to create a "more generic" URN
+   that it recognizes and whose meaning it can render in the context.
+
+   The exact way in which a UA renders a received combination of "alert"
+   URNs is left as an implementation issue.  However, the implementation
+   MUST comply to following rules:
+
+   (a)  Each "alert" URN has precedence over all URNs that follow it,
+        and its interpretation is subordinate to all URNs that precede
+        it.
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 30]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   (b)  If the UA cannot implement the effect of a URN (because it does
+        not recognize the URN or the URN's effect is precluded by
+        preceding URNs), the UA repeatedly removes the final <alert-ind-
+        part> of the URN until either:
+
+        (1)  the resulting URN is recognized and can be given effect by
+             some signal (without reducing the degree of expression of
+             any preceding URN), or
+
+        (2)  the resulting URN is reduced to having no <alert-ind-part>
+             in which case, that URN in the series cannot be given
+             effect, and so is ignored.
+
+   (c)  In case that after processing all the received URNs, the UA can
+        generate more than one signal that are equally effective at
+        expressing the URNs (under the preceding rules), one of those
+        signals is selected.  When selecting from the set of equally
+        effective signals, the least specific signal in the set should
+        be chosen: a signal should not be chosen if a less-specific
+        signal is also in the set.  (Specificity is to be judged based
+        on the defined meanings of the signals to the user.)  (For
+        example, if each signal is considered to express certain <alert-
+        indication>s of certain <alert-category>s, one signal is less-
+        specific than a second signal if the first signal's <alert-
+        indication>s are a subset or are prefixes of the second signal's
+        <alert-indication>s.)  However, a more-specific signal may be
+        chosen if the choice is based on information derived from the
+        containing SIP message.  For example, a signal implying
+        <urn:alert:priority:high> may be chosen if the SIP message
+        contains the header field "Priority: urgent".
+
+   In all situations, the set of signals that can be rendered and their
+   significances may change based on user preferences and local policy.
+   In addition, the chosen signal may change based on the status of the
+   UA.  For example, if a call is active on the UA, all audible signals
+   may become unavailable, or audible signals may be available only if
+   <urn:alert:priority:high> is specified.
+
+11.2.  Multi-mode Signals
+
+   There are cases when the device can render two signal modes (e.g.,
+   audio and visual, or video and text) at the same time.
+
+   Formally, the device must be considered to be making its choice from
+   the set of all combined signals that it can render (pairs of one
+   signal from the first mode and one signal from the second mode), and
+   that choice must conform to the above rules.  However, it can be
+   proven that if the device makes its rendering choice for each of the
+
+
+
+Liess, et al.                Standards Track                   [Page 31]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   two modes independently, with each choice separately conforming to
+   the above rules, its combined choice also conforms to the above
+   rules, when it is regarded as a choice from among all possible
+   combinations.
+
+   In such a situation, it may simplify implementation to make each
+   choice separately.  It is an implementation decision whether to chose
+   from among combined signals or to combine choices made from each
+   signal mode.
+
+12.  Non-normative Algorithm for Handling Combinations of URNs
+
+   The following text is a non-normative example of an algorithm for
+   handling combinations of URNs that complies with the rules in
+   Sections 10 and 11.  Thus, it demonstrates that the rules are
+   consistent and implementable.  (Of course, a device may use any other
+   algorithm that complies with Sections 10 and 11.)
+
+12.1.  Algorithm Description
+
+   For each <alert-category> (feature) known by the implementation,
+   there is a "feature tree" of the known <alert-indication>s for that
+   <alert-category>, with the sequence of <alert-ind-part>s in an
+   <alert-indication> specifying the path in the tree from the root to
+   the node representing the <alert-indication>.  For this description,
+   we will name each tree and its root node by the <alert-category>
+   name, and name each non-root node by the <alert-identifier>.  Each
+   URN thus corresponds to one non-root node in one feature tree.  For
+   example, there is a tree named "source", whose root node is also
+   named "source", and which has the children source:internal,
+   source:external, source:friend, and source:family.  The URN
+   <urn:alert:source:external> is placed at the node "source:external"
+   in the "source" tree.  If the implementation understands
+   <urn:alert:source:foo@example>, there is a node source:foo@example
+   that is a child of node "source".  If the implementation understands
+   <urn:alert:source:external:bar@example>, there is a node
+   source:external:bar@example that is a child of node source:external.
+   (Of course, there are an infinite number of potential additional
+   nodes in the tree for private values, but we don't have to represent
+   those nodes explicitly unless the device has a signal representing
+   the private value.)
+
+   We assign similar locations to signals, but each signal has a
+   position in *every* tree, describing the specific combination of
+   meanings that it carries.  If a signal has a simple meaning, such as
+   "external source", its place in the "source" tree is source:external,
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 32]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   showing that it carries the "external source" meaning, but its place
+   in every other feature tree is at the root node, meaning that it has
+   no particular meaning for those features.
+
+   A signal that has a complex meaning may have non-root positions in
+   more than one feature tree.  For example, an "external, high
+   priority" signal would be placed at source:external and priority:high
+   in those trees, but be at the root in all other feature trees.
+
+   In order to assure that the algorithm always selects at least one
+   signal, we require that there is a "default" signal, whose position
+   in every feature tree is at the root.  This default signal will never
+   be excluded from the set of acceptable signals for any set of URNs,
+   but will be the lowest priority signal for any set of URNs.
+
+   The algorithm proceeds by considering each URN in the received Alert-
+   Info header fields from left to right, while revising a set of
+   signals.  The set of signals starts as the entire set of signals
+   available to the device.  Each URN excludes some signals from the
+   set, and "sorts" the signals that remain in the set according to how
+   well they represent the URN.  (The details of these operations are
+   described below.)  The first URN is the "major sort", and has the
+   most influence on the position of a signal in the set.  The second
+   URN is a "minor sort", in that it arranges the orders of the signals
+   that are tied within the first sort, the third URN arranges the
+   orders of the signals that are tied within the first two sorts, etc.
+
+   At the end of the algorithm, a final, "most minor" sort is done,
+   which orders the signals that remain tied under all the sorts driven
+   by the URNs.  This final sort places the least specific signals
+   (within their tied groups) "first".  (If one signal's position in
+   each feature tree is ancestral or the same as a second signal's
+   position in that tree, the first signal is "less specific" than the
+   second signal.  Other cases are left to the implementation to
+   decide.)
+
+   Once all the URNs are processed and the sorting of the signals that
+   have not been excluded is done, the device selects the first signal
+   in the set.
+
+   Here is how a single sort step proceeds, examining a single URN to
+   modify the set of signals (by excluding some signals and further
+   sorting the signals that remain):
+
+   o  The URN specifies a specific node in a specific feature tree.
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 33]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   o  All signals in the set that are, within that feature tree,
+      positioned at the URN's node, or at an ancestor node of the URN's
+      node, are kept.  All other signals are removed from the set
+      (because they have meanings that are incompatible with the URN's
+      meaning).
+
+   o  Each group of signals that are tied under the previous sorts are
+      further sorted into groups based on how much of the URN's meaning
+      they represent: those which are positioned at the node of the URN
+      are tied for first position, those which are positioned at the
+      parent node of the URN are tied for second position, etc., and
+      those which are positioned at the root node of the feature tree
+      are tied for last position.
+
+12.2.  Examples of How the Algorithm Works
+
+   The following examples show how the algorithm described in the
+   previous section works:
+
+12.2.1.  Example 1
+
+   The device has a set of four alerting signals.  We list their primary
+   meanings, and the locations that they are placed in the feature
+   trees:
+
+   Signal 1
+
+      Meaning: external
+      Locations:
+      - source:external
+      - priority (that is, the root node of the priority tree)
+
+   Signal 2
+
+      Meaning: internal
+      Locations:
+      - source:internal
+      - priority
+
+   Signal 3
+
+      Meaning: low
+      Locations:
+      - source
+      - priority:low
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 34]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   Signal 4
+
+      Meaning: high
+      Locations:
+      - source
+      - priority:high
+
+   To which we add:
+
+   Signal 5
+
+      Meaning: default
+      Locations:
+      - source
+      - priority
+
+   If the device receives <urn:alert:source:internal>, then the sort is:
+
+   Signals at source:internal: (this is, first place)
+
+      Signal 2: internal
+
+   Signals at source: (tied for second place)
+
+      Signal 3: low
+      Signal 4: high
+      Signal 5: default
+
+   And these signals are excluded from the set:
+
+      Signal 1: external
+
+   So, in this example, the sorting algorithm properly gives first place
+   to Signal 2 "internal".
+
+12.2.2.  Example 2
+
+   Let us add to the set of signals in Example 1 ones that express
+   combinations like "internal, high priority", but let us specifically
+   exclude the combination "internal, low priority" so as to set up some
+   tricky examples.  This enlarges our set of signals:
+
+   Signal 1
+
+      Meaning: default
+      Locations:
+      - source
+      - priority
+
+
+
+Liess, et al.                Standards Track                   [Page 35]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   Signal 2
+
+      Meaning: external
+      Locations:
+      - source:external
+      - priority
+
+   Signal 3
+
+      Meaning: internal
+      Locations:
+      - source:internal
+      - priority
+
+   Signal 4
+
+      Meaning: low
+      Locations:
+      - source
+      - priority:low
+
+   Signal 5
+
+      Meaning: high
+      Locations:
+      - source
+      - priority:high
+
+   Signal 6
+
+      Meaning: external high
+      Locations:
+      - source:external
+      - priority:high
+
+   Signal 7
+
+      Meaning: external low
+      Locations:
+      - source:external
+      - priority:low
+
+   Signal 8
+
+      Meaning: internal high
+      Locations:
+      - source:internal
+      - priority:high
+
+
+
+Liess, et al.                Standards Track                   [Page 36]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   If the device receives <urn:alert:source:internal>, then the sort is:
+
+   Signals at source:internal: (that is, tied for first place)
+
+      - Signal 3: internal
+      - Signal 8: internal high
+
+   Signals at source: (tied for second place)
+
+      - Signal 4: low
+      - Signal 5: high
+      - Signal 1: default
+
+   Signals excluded from the set:
+
+      - Signal 2: external
+      - Signal 7: external low
+      - Signal 6: external high
+
+   Two signals are tied for the first place, but the final sort orders
+   them:
+
+      - Signal 3: internal
+      - Signal 8: internal high
+
+   because it puts the least-specific signal first.  So, the Signal 3
+   "internal" is chosen.
+
+12.2.3.  Example 3
+
+   The same device receives <urn:alert:source:external>,
+   <urn:alert:priority:low>.  The first sort (due to
+   <urn:alert:source:external>) is:
+
+   Signals at source:external:
+
+      - Signal 2: external
+      - Signal 7: external low
+      - Signal 6: external high
+
+   Signals at source:
+
+      - Signal 4: low
+      - Signal 5: high
+      - Signal 1: default
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 37]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   Signals excluded:
+
+      - Signal 3: internal
+      - Signal 8: internal high
+
+   The second sort (due to <urn:alert:priority:low>) puts signals at
+   priority:low before signals at priority, and excludes signal at
+   priority:high:
+
+      - Signal 7: external low
+      - Signal 2: external
+      - Signal 4: low
+      - Signal 1: default
+
+   Excluded:
+
+      - Signal 6: external high
+      - Signal 5: high
+      - Signal 3: internal
+      - Signal 8: internal high
+
+   So, we choose Signal 7 "external low".
+
+12.2.4.  Example 4
+
+   Suppose the same device receives <urn:alert:source:internal>,
+   <urn:alert:priority:low>.  Note that there is no signal that
+   corresponds to this combination.
+
+   The first sort is based on source:internal, and results in this
+   order:
+
+      - Signal 3: internal
+      - Signal 8: internal high
+      - Signal 4: low
+      - Signal 5: high
+      - Signal 1: default
+
+   Excluded:
+
+      - Signal 2: external
+      - Signal 7: external low
+      - Signal 6: external high
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 38]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   The second sort is based on priority:low, and results in this order:
+
+      - Signal 3: internal
+      - Signal 4: low
+      - Signal 1: default
+
+   Excluded:
+
+      - Signal 8: internal high
+      - Signal 5: high
+      - Signal 7: external low
+      - Signal 2: external
+      - Signal 6: external high
+
+   So, we choose the Signal 3 "internal".
+
+   Note that <urn:alert:priority:low> could not be given effect because
+   it followed <urn:alert:source:internal>.  If the two URNs had
+   appeared in the reverse order, the Signal 2 "external" would have
+   been chosen, because <urn:alert:priority:low> would have been given
+   precedence.
+
+12.2.5.  Example 5
+
+   Let us set up a simple set of signals, with three signals giving
+   priority:
+
+   Signal 1
+
+      Meaning: default
+      Locations:
+      - priority
+
+   Signal 2
+
+      Meaning: low
+      Locations:
+      - priority:low
+
+   Signal 3
+
+      Meaning: high
+      Locations:
+      - priority:high
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 39]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   Notice that we've used the "default" signal to cover "normal
+   priority".  That is so the signal will cover situations where no
+   priority URN is present, as well as the ones with
+   <urn:alert:priority:normal>.  So, we're deliberately failing to
+   distinguish "priority:normal" from the default priority.
+
+   If the device receives <urn:alert:priority:low>, the sort is:
+
+      - Signal 2: low
+      - Signal 1: default
+
+   Excluded:
+
+      - Signal 3: high
+
+   and Signal 2 "low" is chosen.
+
+   Similarly, if the device receives <urn:alert:priority:high>, Signal 3
+   is chosen.
+
+   If the device receives <urn:alert:priority:normal>, the sort is:
+
+      -Signal 1 :default
+
+   Excluded:
+
+      - Signal 2: low
+      - Signal 3: high
+
+   and Signal 1 "default" is chosen.
+
+   If no "priority" URN is received, Signal 1 "default" will be put
+   before Signal 2 "low" and Signal 3 "high" by the final sort, and so
+   it will be chosen.
+
+13.  User Agent Behaviour
+
+   A SIP UA MAY add a URN or multiple URNs to the Alert-Info header
+   field in a SIP request or a provisional 1xx response (excepting a 100
+   response) when it needs to provide additional information about the
+   call or about the provided service.
+
+   Upon receiving a SIP INVITE request or a SIP provisional response
+   with an Alert-Info header field that contains a combination of Alert-
+   Info URNs, the UA attempts to match the received Alert- Info URNs
+   combination with a signal it can render.  The process the UA uses
+   MUST conform to the rules described in Section 11.  (A non-normative
+   algorithm example for the process is described in Section 12.)
+
+
+
+Liess, et al.                Standards Track                   [Page 40]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   The UA must produce a reasonable rendering regardless of the
+   combination of URIs (of any schemes) in the Alert-Info header field:
+   it MUST produce a rendering based on the URIs that it can understand
+   and act on (if any), interpreted as prescribed by local policy, and
+   ignore the other URIs.  In particular, unless the containing message
+   is a request and is immediately rejected, the UA SHOULD provide some
+   alert unless it is instructed not to (for example, by Alert-Info URIs
+   that it understands, the presence of a Replaces or Joins header
+   field, local policy, or direction of the user).
+
+   Subsequent provisional responses, even within the same dialog, may
+   contain different Alert-Info header field values.  The Alert-Info
+   header field values received within different provisional responses
+   are treated independently.  If subsequent provisional responses
+   containing different Alert-Info header field values were received
+   within the same dialog, the UA SHOULD render, at any time, the last
+   received Alert-Info header field value.  The handling of provisional
+   responses containing different Alert-Info header field values that
+   were not received within the same dialog is left as an implementation
+   issue.
+
+14.  Proxy Behaviour
+
+   A SIP proxy MAY add or remove an Alert-Info header field, and MAY add
+   or remove Alert-Info header field values, in a SIP request or a
+   non-100 provisional response when it needs to modify the information
+   about the call or about the provided services.
+
+   There are many reasons a proxy may choose do this, for example, (1)
+   to add indications based on information that the proxy can determine
+   about the call, such as that it is coming from an external source, or
+   that the INVITE contains a "Priority: urgent" header field; (2) to
+   add indication that a particular service is being invoked at this end
+   of the call; (3) to remove undesirable indications, such as possibly
+   deceptive indications from untrusted sources; and (4) to remove
+   indications that contain information that should be suppressed for
+   privacy reasons.
+
+   The following example shows a typical example of a 180 (Ringing)
+   provisional response that has been modified by a proxy.  The response
+   sent by the UAS to the proxy was very similar, but had no Alert-Info
+   header field.  The proxy has added Alert-Info header field values
+   specifying both a network audio resource referenced by the HTTP URI
+   and the URN indication for the call-waiting service.  This allows the
+   UAC to render the network audio resource, to choose a rendering based
+   on the URN, or to perform some combination of these actions.  Due to
+   Section 10, the UAC must produce some reasonable rendering in this
+   situation.
+
+
+
+Liess, et al.                Standards Track                   [Page 41]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   SIP/2.0 180 Ringing
+   Alert-Info: <http://www.example.com/sound/moo.wav>,
+                <urn:alert:service:call-waiting>
+   To: Bob <sip:bob@biloxi.example.com>;tag=a6c85cf
+   From: Alice <sip:alice@atlanta.example.com>;tag=1928301774
+   Call-ID: a84b4c76e66710
+   Contact: <sip:bob@192.0.2.4>
+   CSeq: 314159 INVITE
+   Via: SIP/2.0/UDP server10.biloxi.example.com;
+               branch=z9hG4bK4b43c2ff8.1
+   Content-Length: 0
+
+15.  Internationalization Considerations
+
+   The <alert-identifier> labels are protocol elements [RFC6365] and are
+   not normally seen by users.  Thus, the character set for these
+   elements is restricted, as described in Section 7.
+
+   Allowance has been made for the possibility of internationalizing
+   <alert-identifier>s by allowing them to be A-labels: a processor that
+   does not understand such <alert-identifier>s is required to ignore
+   them as specified in Sections 7 and 11.1.
+
+   The URNs <urn:alert:locale:country:<ISO 3166-1 country code>> select
+   renderings that are conventional in the specified country.
+
+16.  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.
+
+   However, the provision of specific indications may raise privacy
+   issues by revealing information about the source UA, e.g., its
+   nature, its dialog state, or services initiated at its end of the
+   call.  For example, call-waiting (Section 6.2.1) and call-forwarding
+   (Section 6.2.2) services can reveal the dialog state of the UA.  Such
+   a provision SHALL always require authorization on behalf of the user
+   of the source UA (usually through accessing configured policy).
+   Authorization SHALL NOT assume that there is any limitation of the
+   potential recipients of the indications without obtaining specific
+   information about the SIP transaction.
+
+   Based on local policy, a UA MAY choose to ignore undesirable
+   indications (e.g., possibly deceptive indications from untrusted
+   sources), and it MAY choose not to send indications that are
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 42]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   otherwise valid in the context (e.g., for privacy reasons).  A proxy
+   acting on behalf of a UA MAY add or delete indications going to or
+   from the UA for the same reasons.
+
+   Since the alert indications can be sensitive, end-to-end SIP
+   encryption mechanisms using S/MIME MAY be used to protect it.  UAs
+   that implement alert indications SHOULD also implement SIP over TLS
+   [RFC5246] and the sips: scheme [RFC5630].
+
+17.  References
+
+17.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997,
+              <http://www.rfc-editor.org/info/rfc2141>.
+
+   [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, <http://www.rfc-editor.org/info/rfc3261>.
+
+   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
+              "Uniform Resource Names (URN) Namespace Definition
+              Mechanisms", BCP 66, RFC 3406, October 2002,
+              <http://www.rfc-editor.org/info/rfc3406>.
+
+   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
+              May 2008, <http://www.rfc-editor.org/info/rfc5226>.
+
+   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
+              Specifications: ABNF", STD 68, RFC 5234, January 2008,
+              <http://www.rfc-editor.org/info/rfc5234>.
+
+   [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
+              (TLS) Protocol Version 1.2", RFC 5246, August 2008,
+              <http://www.rfc-editor.org/info/rfc5246>.
+
+   [RFC5630]  Audet, F., "The Use of the SIPS URI Scheme in the Session
+              Initiation Protocol (SIP)", RFC 5630, October 2009,
+              <http://www.rfc-editor.org/info/rfc5630>.
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 43]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+17.2.  Informative References
+
+   [E182]     ITU-T, "Application of tones and recorded announcements in
+              telephone services", ITU-T Recommendation E.182, 1998,
+              <http://www.itu.int/rec/T-REC-E.182-199803-I/en>.
+
+   [ISO3166-1]
+              ISO, "English country names and code elements", ISO
+              3166-1, <http://www.iso.org/iso/
+              english_country_names_and_code_elements>.
+
+   [RFC3043]  Mealling, M., "The Network Solutions Personal Internet
+              Name (PIN): A URN Namespace for People and Organizations",
+              RFC 3043, January 2001,
+              <http://www.rfc-editor.org/info/rfc3043>.
+
+   [RFC3044]  Rozenfeld, S., "Using The ISSN (International Serial
+              Standard Number) as URN (Uniform Resource Names) within an
+              ISSN-URN Namespace", RFC 3044, January 2001,
+              <http://www.rfc-editor.org/info/rfc3044>.
+
+   [RFC3120]  Best, K. and N. Walsh, "A URN Namespace for XML.org", RFC
+              3120, June 2001, <http://www.rfc-editor.org/info/rfc3120>.
+
+   [RFC3187]  Hakala, J. and H. Walravens, "Using International Standard
+              Book Numbers as Uniform Resource Names", RFC 3187, October
+              2001, <http://www.rfc-editor.org/info/rfc3187>.
+
+   [RFC3188]  Hakala, J., "Using National Bibliography Numbers as
+              Uniform Resource Names", RFC 3188, October 2001,
+              <http://www.rfc-editor.org/info/rfc3188>.
+
+   [RFC4152]  Tesink, K. and R. Fox, "A Uniform Resource Name (URN)
+              Namespace for the Common Language Equipment Identifier
+              (CLEI) Code", RFC 4152, August 2005,
+              <http://www.rfc-editor.org/info/rfc4152>.
+
+   [RFC4179]  Kang, S., "Using Universal Content Identifier (UCI) as
+              Uniform Resource Names (URN)", RFC 4179, October 2005,
+              <http://www.rfc-editor.org/info/rfc4179>.
+
+   [RFC4195]  Kameyama, W., "A Uniform Resource Name (URN) Namespace for
+              the TV-Anytime Forum", RFC 4195, October 2005,
+              <http://www.rfc-editor.org/info/rfc4195>.
+
+   [RFC4198]  Tessman, D., "A Uniform Resource Name (URN) Namespace for
+              Federated Content", RFC 4198, November 2005,
+              <http://www.rfc-editor.org/info/rfc4198>.
+
+
+
+Liess, et al.                Standards Track                   [Page 44]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+   [RFC5589]  Sparks, R., Johnston, A., and D. Petrie, "Session
+              Initiation Protocol (SIP) Call Control - Transfer", BCP
+              149, RFC 5589, June 2009,
+              <http://www.rfc-editor.org/info/rfc5589>.
+
+   [RFC5890]  Klensin, J., "Internationalized Domain Names for
+              Applications (IDNA): Definitions and Document Framework",
+              RFC 5890, August 2010,
+              <http://www.rfc-editor.org/info/rfc5890>.
+
+   [RFC6365]  Hoffman, P. and J. Klensin, "Terminology Used in
+              Internationalization in the IETF", BCP 166, RFC 6365,
+              September 2011, <http://www.rfc-editor.org/info/rfc6365>.
+
+   [RFC6910]  Worley, D., Huelsemann, M., Jesske, R., and D. Alexeitsev,
+              "Completion of Calls for the Session Initiation Protocol
+              (SIP)", RFC 6910, April 2013,
+              <http://www.rfc-editor.org/info/rfc6910>.
+
+   [RFC7463]  Johnston, A., Ed., Soroushnejad, M., Ed., and V.
+              Venkataramanan, "Shared Appearances of a Session
+              Initiation Protocol (SIP) Address of Record (AOR)", RFC
+              7463, March 2015,
+              <http://www.rfc-editor.org/info/rfc7463>.
+
+   [TS24.615]
+              3GPP, "Communication Waiting (CW) using IP Multimedia (IM)
+              Core Network (CN) subsystem; Protocol Specification", 3GPP
+              TS 24.615, September 2015.
+
+Acknowledgements
+
+   The authors wish to thank Denis Alexeitsev, the editor of the initial
+   version in BLISS, Anwar Siddiqui for his contributions to the
+   document, Christer Holmberg for his careful review of the document,
+   Adam Roach, Dean Willis, Martin Huelsemann, Shida Schubert, John
+   Elwell, and Tom Taylor for their comments and suggestions and Alfred
+   Hoenes for his extensive comments and proposals related to new
+   namespace identifiers for URNs.
+
+
+
+
+
+
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 45]
+
+RFC 7462                       Alert URNs                     March 2015
+
+
+Authors' Addresses
+
+   Laura Liess (editor)
+   Deutsche Telekom AG
+   Heinrich-Hertz Str 3-7
+   Darmstadt, Hessen  64295
+   Germany
+
+   Phone: +49 6151 5812761
+   EMail: laura.liess.dt@gmail.com
+
+
+   Roland  Jesske
+   Deutsche Telekom AG
+   Heinrich-Hertz Str. 3-7
+   Darmstadt, Hessen  64295
+   Germany
+
+   Phone: +49 6151 5812766
+   EMail: r.jesske@telekom.de
+
+
+   Alan Johnston
+   Avaya, Inc.
+   St. Louis, MO
+   United States
+
+   EMail: alan.b.johnston@gmail.com
+
+
+   Dale R. Worley
+   Ariadne Internet Services, Inc.
+   738 Main St.
+   Waltham, MA    02451
+   United States
+
+   Phone: +1 781 647 9199
+   EMail: worley@ariadne.com
+
+
+   Paul Kyzivat
+   Huawei
+   United States
+
+   EMail: pkyzivat@alum.mit.edu
+
+
+
+
+
+
+Liess, et al.                Standards Track                   [Page 46]
+