tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7462

Proposed STD
Pages: 46
Top     in Index     Prev     Next
in Group Index     No Prev: Lowest Number in Group     No Next: Highest Number in Group     Group: SALUD

URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)

Part 1 of 2, p. 1 to 20
None       Next RFC Part

Updates:    3261


Top       ToC       Page 1 
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.

Page 2 
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.

Top       Page 3 
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

Top      ToC       Page 4 
                  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

Top      ToC       Page 5 
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.

Top      ToC       Page 6 
   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.

Top      ToC       Page 7 
   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.

Top      ToC       Page 8 
   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

Top      ToC       Page 9 
   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.)

Top      ToC       Page 10 
   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.

Top      ToC       Page 11 
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.

Top      ToC       Page 12 
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

Top      ToC       Page 13 
   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

Top      ToC       Page 14 
   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.

Top      ToC       Page 15 
      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-

Top      ToC       Page 16 
      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.

Top      ToC       Page 17 
      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.

Top      ToC       Page 18 
   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

Top      ToC       Page 19 
   [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>.

Top      ToC       Page 20 
8.2.4.  <alert-Indication> Values for the <alert-category> "duration"

   - normal (default)
   - short
   - long
   - <private-name>

   Examples: <urn:alert:duration:short>.

8.2.5.  <alert-indication> Values for the <alert-category> "delay"

   - none (default)
   - yes
   - <private-name>

   Examples: <urn:alert:delay:yes>.

8.2.6.  <alert-indication> Values for the <alert-category> "locale"

   - default (default)
   - country:<ISO 3166-1 country code>
   - <private-name>

   The ISO 3166-1 country code [ISO3166-1] is used to inform the
   renderer on the other side of the call that a country-specific
   rendering should be used.  For example, to indicate ringback tones
   from South Africa, the following URN would be used:
   <urn:alert:locale:country:za>.



(page 20 continued on part 2)

Next RFC Part