GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7462

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:
  1. service
  2. source
  3. priority
  4. duration
  5. delay
  6. 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"

  1. normal (default)
  2. call-waiting
  3. forward
  4. recall:callback
  5. recall:hold
  6. recall:transfer
  7. <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"

  1. unclassified (default)
  2. internal
  3. external
  4. friend
  5. family
  6. <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"

  1. normal (default)
  2. low
  3. high
  4. <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"

  1. normal (default)
  2. short
  3. long
  4. <private-name>
 Examples: <urn:alert:duration:short>.

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

  1. none (default)
  2. yes
  3. <private-name>
 Examples: <urn:alert:delay:yes>.

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

  1. default (default)
  2. country:<ISO 3166-1 country code>
  3. <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)
  1. Signal 3: internal
  2. Signal 8: internal high
 Signals at source: (tied for second place)
  1. Signal 4: low
  2. Signal 5: high
  3. Signal 1: default
 Signals excluded from the set:
  1. Signal 2: external
  2. Signal 7: external low
  3. Signal 6: external high
 Two signals are tied for the first place, but the final sort orders
 them:
  1. Signal 3: internal
  2. 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:
  1. Signal 2: external
  2. Signal 7: external low
  3. Signal 6: external high
 Signals at source:
  1. Signal 4: low
  2. Signal 5: high
  3. Signal 1: default

Liess, et al. Standards Track [Page 37] RFC 7462 Alert URNs March 2015

 Signals excluded:
  1. Signal 3: internal
  2. 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:
  1. Signal 7: external low
  2. Signal 2: external
  3. Signal 4: low
  4. Signal 1: default
 Excluded:
  1. Signal 6: external high
  2. Signal 5: high
  3. Signal 3: internal
  4. 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:
  1. Signal 3: internal
  2. Signal 8: internal high
  3. Signal 4: low
  4. Signal 5: high
  5. Signal 1: default
 Excluded:
  1. Signal 2: external
  2. Signal 7: external low
  3. 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:
  1. Signal 3: internal
  2. Signal 4: low
  3. Signal 1: default
 Excluded:
  1. Signal 8: internal high
  2. Signal 5: high
  3. Signal 7: external low
  4. Signal 2: external
  5. 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:
  1. Signal 2: low
  2. Signal 1: default
 Excluded:
  1. 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:
  1. Signal 1 :default
 Excluded:
  1. Signal 2: low
  2. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7462.txt · Last modified: 2015/03/25 15:51 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki