[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 draft-ietf-salud-alert-info-urns

DISPATCH                                                   D. Alexeitsev
Internet-Draft                                                  L. Liess
Intended status: Standards Track                               R. Jesske
Expires: August 30, 2010                             Deutsche Telekom AG
                                                             A. Johnston
                                                             A. Siddiqui
                                                                   Avaya
                                                       February 26, 2010


       Alert-Info URNs for the Session Initiation Protocol (SIP)
                draft-liess-dispatch-alert-info-urns-01

Abstract

   The Session Initiation Protocol (SIP) supports the capability to
   provide a reference to the alternative ringback tone (RBT) for
   caller, or ring tone (RT) for callee using the Alert-Info header.
   However, the reference addresses only the network resources with
   specific rendering properties.  There is currently no support for
   predefined standard identifiers for ringback tones or semantic
   indications without being tied to a particular rendering.  To
   overcome this limitation and support new applications, a new family
   of URNs for use in SIP Alert-Info header fields is defined in this
   specification.

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].

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at



Alexeitsev, et al.       Expires August 30, 2010                [Page 1]

Internet-Draft               Alert-Info URNs               February 2010


   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 30, 2010.

Copyright Notice

   Copyright (c) 2010 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 BSD License.






























Alexeitsev, et al.       Expires August 30, 2010                [Page 2]

Internet-Draft               Alert-Info URNs               February 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Registration template  . . . . . . . . . . . . . . . . . . . .  7
   4.  Top Level Alert URN Indication Definitions . . . . . . . . . . 10
     4.1.  PBX Tones  . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.1.1.  normal . . . . . . . . . . . . . . . . . . . . . . . . 10
       4.1.2.  external . . . . . . . . . . . . . . . . . . . . . . . 11
       4.1.3.  internal . . . . . . . . . . . . . . . . . . . . . . . 11
     4.2.  Service Tones  . . . . . . . . . . . . . . . . . . . . . . 11
       4.2.1.  call-waiting . . . . . . . . . . . . . . . . . . . . . 11
       4.2.2.  forward  . . . . . . . . . . . . . . . . . . . . . . . 11
       4.2.3.  transfer-recall  . . . . . . . . . . . . . . . . . . . 11
       4.2.4.  auto-callback  . . . . . . . . . . . . . . . . . . . . 12
       4.2.5.  hold-recall  . . . . . . . . . . . . . . . . . . . . . 12
       4.2.6.  priority . . . . . . . . . . . . . . . . . . . . . . . 12
       4.2.7.  zip  . . . . . . . . . . . . . . . . . . . . . . . . . 12
       4.2.8.  delayed  . . . . . . . . . . . . . . . . . . . . . . . 12
     4.3.  Country-specific ringback tone indications for the
           public telephone network . . . . . . . . . . . . . . . . . 13
     4.4.  Combinations of URNs . . . . . . . . . . . . . . . . . . . 13
   5.  User Agent Behavior  . . . . . . . . . . . . . . . . . . . . . 13
   6.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  New alert-identifiers  . . . . . . . . . . . . . . . . . . 14
     7.2.  Alert-category . . . . . . . . . . . . . . . . . . . . . . 15
     7.3.  Initial IANA Registration  . . . . . . . . . . . . . . . . 15
       7.3.1.  Indications for PBX-tones  . . . . . . . . . . . . . . 15
       7.3.2.  Additional Indications for PBX-tones . . . . . . . . . 15
       7.3.3.  Indications for Country-specific Ringback tones in
               the public telephone network . . . . . . . . . . . . . 16
       7.3.4.  Indications for Services . . . . . . . . . . . . . . . 16
       7.3.5.  Combination Rules for Alert URN Indications  . . . . . 16
   8.  Internationalization Considerations  . . . . . . . . . . . . . 17
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     11.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19










Alexeitsev, et al.       Expires August 30, 2010                [Page 3]

Internet-Draft               Alert-Info URNs               February 2010


1.  Introduction

   The Session Initiation Protocol (SIP) [RFC3261] allows for user agent
   servers (UAS) and proxies to provide the specific ringback or ring
   tone to the user agent (UA).  In RFC 3261 this is done by including a
   URI reference in the Alert-Info header field, that points to the
   tone.  The URI reference is most commonly the HTTP URI to the audio
   file.  On the receipt of the Alert-Info header the user agent may
   fetch the referenced ringback or ring tone and play it to the user.

   This mechanism does not ensure interoperability when there is no
   common understanding of the referenced content (different countries
   or vendors, hearing impaired) or when the user wants his own tones
   configured in the end device.  If caller and callee are from the
   different countries, the understanding of the tones may vary
   significantly.  Hearing impaired users may not sense the specific
   tone if it is provided as an audio file.  The tone per se is also not
   useful for automata.

   There are currently interoperability issues around the use of the
   Alert-Info header field when not using an external ring file.  For
   example, consider the PBX special ringtone for an external (to the
   PBX) caller.  Different vendors use different approaches such as:
   Alert-Info: <file://ring.pcm>;alert=normal where ring.pcm is a dummy
   file or: Alert-Info: <file://normal.ring.pcm> or: Alert-Info:
   <sip:normal-ringtone@example.com> As a result, Alert-Info currently
   only works when the same vendor provides proxy and UA, as only then
   is the same "fake" proprietary URI convention used.

   Another limitation of the current solution is that the referenced
   tones are tied to particular rendering.  It is not possible to
   provide a semantic indication that signals the intent and allows the
   recipient to decide how to render the received information in an
   appropriate way.

   To solve the described issues, this specification defines the new URN
   namespace 'alert' for the Alert-Info header that can be understood by
   an automaton, would allow for programmatic handling including user
   interface adaptation, or conversion to equivalent protocol parameters
   in the Public Switched Telephone Network (PSTN) when the client is a
   gateway.  The work to standardize an Alert-Info URN will increase SIP
   interoperability for this header field by replacing proprietary
   conventions.

   Using 'alert' namespace provides syntax for several different
   application spaces:





Alexeitsev, et al.       Expires August 30, 2010                [Page 4]

Internet-Draft               Alert-Info URNs               February 2010


   o  Names for services 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 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 URI reference to a
   downloadable resource:

   o  Do not need to download it or deal with security issues associated
      with dereferencing.

   o  No formatting or compatibility issues.

   o  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 to use it or
      not.

   o  It facilitates translation for the hearing impaired.

   The downside is that if the recipient does not understand the URN
   then it will only be able to render a default ringback or ring-tone.
   To provide the general awareness about the Alert-Info URNs this
   document provides IANA template for registering the URNs and defines
   several typical identifiers.

   This specification does not change the usage of the SIP Alert-Info-
   header defined in the RFC3261.  The Alert-Info-header can be used in
   INVITE requests and 180 Ringing responses.


2.  Requirements

   This section discusses the requirements for an identifier to
   transport the semantic of a specific ring or ringback tone.




Alexeitsev, et al.       Expires August 30, 2010                [Page 5]

Internet-Draft               Alert-Info URNs               February 2010


   REQ-1: The mechanism will allow user agents (UAs) and proxies to
   provide a semantic indication in the Alert-Info SIP-header that
   signals the intent of the rendering and allows the recipient to
   decide how to render the received information.

   REQ-2: The mechanism will allow interoperability for services as call
   waiting, forward, call forwarding, transfer-recall, auto-callback,
   hold-recall, crisis.

   REQ-3: The mechanism will allow rendering common PBX ring tone types.

   REQ-4: The mechanism will allow rendering specific country ringback
   tones.

   REQ-5: The mechanism will allow rendering tones for emergency alerts.

   REQ-6: The mechanism will allow rendering using other means than
   tones, e.g. text or images.

   REQ-7: The mechanism will allow rendering to be semantic, not biased
   towards a particular representation which might not be suitable for
   all devices or users.  The Alert-Info URN must be semantic whenever
   the semantic is known to the sender.

   REQ-8: The mechanism will allow non-semantic, rendering-oriented
   Alert-Info URNs when the semantic of the rendering is not known by
   the sender and the sender can assume that there is a good chance that
   for the receiver to know how to render the non-semantic URN.  This is
   the case, e.g. for:

   - ringing tones used in closed in enterprise networks

   - ringing tones used in some countries

   - when TDM gateways must map ring-/ringback-tones from legacy
   protocols to SIP at the edge of a network .

   REQ-9: The mechanism must ensure that an UA receiving Alert-Info URNs
   or portions of an Alert-Info URN it does not understand, it can
   ignore them.

   REQ-10: The mechanism will allow storage of the actual encoding
   locally rather than fetching it.

   REQ-11: The mechanism will allow the identifier to be specified "by
   name" rather than "by value", to enable local policy decisions
   whether to use it or not.




Alexeitsev, et al.       Expires August 30, 2010                [Page 6]

Internet-Draft               Alert-Info URNs               February 2010


   REQ-12: The mechanism will allow transmission in the Alert-Info
   header of SIP INVITE requests and 180 Ringing responses.

   REQ-13: The mechanism will be flexible, so new identifiers can be
   defined in the future, when SIP-applications evolve.  E.g.  Alert-
   Info 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.


3.  Registration template

   Below is the registration template for the 'alert' URN scheme
   according to the [RFC2141] and [RFC3406]

   Namespace ID:  alert

   Registration Information:

      Registration version:  1

      Registration date:  TBD

   Declared registrant of the namespace:

      Registering organization:  IETF

      Designated contact:  Laura Liess

      Designated contact email:  l.liess@telekom.de

   Declaration of syntactic structure:

      The Namespace Specific String (NSS) for the "alert" URNs is called
      alert-identifier and has a hierarchical structure.  The left-most
      label is called "alert-category" and is separated from right-side
      of the alert-identifier, the alert-indication, by a semicolon.  In
      this specification, three categories of alert-identifiers are
      described: the "tone" alert-identifiers, the "ringback" alert-
      identifiers and the "service" alert-identifiers.

      The "tone" alert-identifier has the general form:

         urn:alert:tone:{tone-indication}







Alexeitsev, et al.       Expires August 30, 2010                [Page 7]

Internet-Draft               Alert-Info URNs               February 2010


      where the tone-indication identifies the semantic or rendering
      characteristics of a ring tone.  Alert-Info URNs containing the
      "tone" alert-identifier can be used in INVITE requests, but not in
      180 Ringing responses.



      The "ringback" alert-identifier has the general form:

         urn:alert:ringback:{ringback-indication}

      where the ringback-indication is a unique identifier for a
      country-specific ringback tone.  Alert-Info URNs containing the
      "ringback" alert-identifier can be used in 180 Ringing responses,
      but not in INVITE requests.



      The "service" alert-identifier has the general form:

         urn:alert:service:{service-indication}

      where the service-indication is a unique identifier for a service
      as call-waiting or transfer-recall.  Alert-Info URNs containing
      the "service" alert-identifier can be used in both INVITE requests
      and 180 Ringing responses.

      The tone-indication, the ringback-indication and the service-
      indication are hierarchical identifiers, consisting of one label
      or a sequence of labels separated by periods.  The left-most label
      is the most significant one and is called 'top-level indication' ,
      while names to the right are called 'sub-indication'.  The set of
      allowable characters is the same as that for domain names
      [RFC1123].  Labels are case-insensitive, but MUST be specified in
      all lower-case.

      Labels can be removed right-to-left excepting the left-most label;
      the resulting tone-indication or service-indication is still
      valid, referring to a more generic tone-indication, ringback-
      indication or service-indication.  In other words, if a tone
      'x.y.z' exists, the tones 'x' and 'x.y' are also valid tones.
      Each alert indication identifier SHALL explicitly define it's
      validity respective the sub-indications.








Alexeitsev, et al.       Expires August 30, 2010                [Page 8]

Internet-Draft               Alert-Info URNs               February 2010


      The ABNF [RFC5234] for the "tone" and "service" alert URNs is
      shown below:



        alert-URN       = "URN:alert:" alert-identifier
        alert-identifier= alert-category ":" alert-indication
        alert-category  = "tone"/  "ringback"/  "service"
        alert-indication= top-level *("." sub-indication)
        top-level       = let-dig [ *25let-dig-hyp let-dig ]
        sub-indication  = let-dig [ *let-dig-hyp let-dig ]
        let-dig-hyp     = let-dig / "-"
        let-dig         = ALPHA / DIGIT
        ALPHA           = %x41-5A / %x61-7A   ; A-Z / a-z
        DIGIT           = %x30-39 ; 0-9


   Relevant ancillary documentation:  None

   Community considerations:  The alert URN is believed to be relevant
      to a large cross-section of Internet users, including both
      technical and non-technical users, on a variety of devices and
      with a variety of perception capabilities.  The 'alert' URN will
      allow Internet users to receive more information and enable them
      to better make decisions about accepting an offered call, or get
      better feedback on the progress of a call they have made.  User
      interfaces for the perception impaired users can better render the
      ringback indication based on the 'alert' URN.  The assignment of
      identifiers is described in Section 7.  The 'alert' URN does not
      prescribe a particular resolution mechanism, but it is assumed
      that a number of different entities could operate and offer such
      mechanisms.

   Namespace considerations:  There do not appear to be other URN
      namespaces that serve the same need of uniquely identifying
      'alert' communication and information services.

   Identifier uniqueness considerations:  An 'alert' URN identifies a
      logical service or tone, specified in the 'alert' indication
      registration (see Section 7).  Resolution of the registered URN
      will return a particular instance of the alert identifier.  Alert
      identifier URNs MUST be unique for each unique indication; this is
      guaranteed through the registration of each alert indication
      within this namespace, described in Section 7.







Alexeitsev, et al.       Expires August 30, 2010                [Page 9]

Internet-Draft               Alert-Info URNs               February 2010


   Identifier persistence considerations:  The 'alert' URN for the same
      indication is expected to be persistent, as long as it is
      registered with IANA.

   Process of identifier assignment:  The process of identifier
      assignment is described in Section 7.

   Process for identifier resolution:  'alert' URNs are statically
      resolved according to the IANA registry.

   Rules for lexical equivalence:  'alert' URNs are compared according
      to case-insensitive string equality.

   Conformance with URN syntax:  The BNF in the 'Declaration of
      syntactic structure' above constrains the syntax for this URN
      scheme.

   Validation mechanism:  Validation determines whether a given string
      is currently a validly-assigned URN [RFC3406].  Static validation
      is performed based on the currently registered 'alert' URNs at
      IANA.

   Scope:  The scope for this URN is public and global.


4.  Top Level Alert URN Indication Definitions

   This section describes the use cases that are supported by the
   'alert' URNs.

4.1.  PBX Tones

   This section defines some commonly encountered ring-tones on PBX or
   business phones.  They are as follows:

4.1.1.  normal

   This tone indicates that the default or normal ring-tone should be
   rendered.  This is essentially a no-operation Alert-Info URN and
   should be treated by the UA as if no Alert-Info URN is present.  This
   is most useful when Alert-Info header field parameters are being
   used.  For example, in [I-D.ietf-bliss-shared-appearances], an Alert-
   Info header field needs to be present containing the "appearance"
   parameter, but no special ringtone need be specified.  If no special
   alerting is to be used, urn:alert:tone:normal should be used.






Alexeitsev, et al.       Expires August 30, 2010               [Page 10]

Internet-Draft               Alert-Info URNs               February 2010


4.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.  For this case, urn:alert:tone:external should be used.

4.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.
   For this case, the urn:alert:tone:internal should be used.

4.2.  Service Tones

   These tones are used to indicate specific PBX and telephony services.

4.2.1.  call-waiting

   The call waiting Service [TS24.615] permits a callee to be notified
   of an incoming call whilst the media resources are not available for
   the incoming call and the callee is engaged in an active or held
   call.  Subsequently, the callee can either accept, reject, or ignore
   the incoming call.  There is an interest on the caller side to be
   informed about the call waiting situation on the callee side.  Having
   this information the caller can decide whether to continue waiting
   for callee to pickup or better to call some time later when it is
   estimated that the callee could have finished the ongoing
   conversation.  To provide this information, the callee's UAS or proxy
   aware of the call waiting condition can add the call-waiting
   indication URN to the Alert-Info header.  As call-waiting information
   may be subject to the callee's privacy concerns, the exposure of this
   information SHALL be done only if explicitly required by the user.
   The urn:alert:service:call-waiting should be used for this case.

4.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.  The
   urn:alert:service:forward should be used for this case.  Note that a
   181 response can be used in place of this URN.

4.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



Alexeitsev, et al.       Expires August 30, 2010               [Page 11]

Internet-Draft               Alert-Info URNs               February 2010


   them another chance to transfer or otherwise deal with the call.
   This service tone is used to distinguish this INVITE from any other
   normal incoming call.  The urn:alert:service:transfer-recall should
   be used for this case.

4.2.4.  auto-callback

   This feature is used when a user has utilized a server to implement
   an automatic callback service.  When the user is available, the
   server calls back the user and utilizes this service tone to
   distinguish this from any other normal incoming call.  The
   urn:alert:service:auto-callback should be used for this case.

4.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 any other normal incoming
   call.  The urn:alert:service:hold-recall should be used for this
   case.

4.2.6.  priority

   This sub-level is used to indicate that a priority level alert should
   be applied for the type of alerting specified.  For example,
   urn:alert:tone:priority would be used to generate priority alerting.

4.2.7.  zip

   This sub-level is used to indicate that the alert type specified
   should be rendered shorter than normal.  In contact centers, this is
   sometimes referred to as "abbreviated ringing" or a "zip tone".  For
   example, urn:alert:tone:zip would generate a shorter than normal
   ring-tone.

4.2.8.  delayed

   This sub-level is used to indicate that the alerting type specified
   show be rendered after a short delay.  In some bridged line/shared
   line appearance implementations, this is used so that the bridged
   line does not ring at exactly the same time as the main line, but is
   delayed a few seconds.  For example, urn:alert:tone:delayed would
   generate a normal ring-tone, delayed by a few seconds.






Alexeitsev, et al.       Expires August 30, 2010               [Page 12]

Internet-Draft               Alert-Info URNs               February 2010


4.3.  Country-specific ringback tone indications for the public
      telephone network

   In the PSTN, different tones are used in different countries.  End
   users are accustomed to hear the callee's country ringback tone.

   The ISO 3166-1 country code [ISO 3166-1] is used as a top-level
   indication to infor the UAC about the country-specific tone which
   should be rendered to the caller.  For example, to indicate ringback
   tones from South Africa, the following URN would be used:
   <urn:alert:ringback:za>.

4.4.  Combinations of URNs

   In some cases, more than one URN will need to be specified to fully
   define a particular tone.  This is done by including multiple URNs.
   For example, an internal, priority call could be indicated by Alert-
   Info: <urn:alert:tone:internal>, <urn:alert:tone:priority>.  A
   priority call waiting tone could be indicated by Alert-Info:
   <urn:alert:service:call-waiting>, <urn:alert:tone:priority>.


5.  User Agent Behavior

   Upon receiving a SIP INVITE request or a SIP 180-Ringing response
   with an Alert-Info header that contains a single or multiple 'alert'
   URNs, the User Agent (UA) attempts to match the received Alert-Info
   URNs with the known indications or indication combinations.  The User
   Agent (UA) ignores the Alert-Info URNs for which no match is found
   and proceeds with the normal operation.  If one or multiple URNs
   match(es) a known indication or a known indication combination, the
   User Agent (UA) renders the indication or the indication combination
   to the user accordingly.  The User Agent (UA) is responsible for the
   non disturbing rendering if multiple indications and network
   resources are to be rendered simultaneously.


6.  Proxy Behavior

   A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
   in a SIP request or a 180 Ringing provisional response when it needs
   to provide additional information about the call or about the
   provided service.  A SIP Proxy SHOULD NOT add a mixture of 'alert'
   URNs and URIs to the Alert-Info header that may cause disturbing
   rendering interference at the recipient's User Agent (UA).

   Following example shows both the network audio resource referenced by
   the HTTP URI and the URN indication for the call-waiting service



Alexeitsev, et al.       Expires August 30, 2010               [Page 13]

Internet-Draft               Alert-Info URNs               February 2010


   transported by the Alert-Info header in a 180 Ringing provisional
   response.

      Alert-Info: <http://www.example.com/sound/moo.wav>,
       <urn:alert:service:call-waiting>


7.  IANA Considerations

   This section registers a new URN scheme with the registration
   template provided in section Registration Template.

   Below, the section 7.1 details how to register new alert-identifiers.
   Descriptions of alert-indications for the first three alert-
   identifiers described in this document , 'service', 'tone' and
   'ringback', are given in Section 7.2 and Section 7.3, respectively.
   Finally, Section 7.4 contains the initial registration table.

7.1.  New alert-identifiers

   Alert URNs are identified by labels managed by IANA, according to the
   processes outlined in [RFC5226] in a new registry called "Alert URN
   Labels".  Thus, creating a new alert-identifier requires IANA action.
   The policy for adding a new alert-identifier category is 'Standards
   Action'.  (This document defines the alert-identifier categories
   'service' , 'tone' and 'ringback'.)  The policy for assigning labels
   to alert top-level indications or sub-indications and the rules to
   combine top-level indications and sub-indications may differ for each
   alert-identifier category and MUST be defined by the document
   describing the corresponding alert indications.  The entries in the
   registration table have the following format:

      Category/           Reference    Description
      Top-Indication/
      Sub-Indication
      ------------------------------------------------------------
      foo                 RFC XXXX     Description of the 'foo'
                                       alert-category
      bar                 RFC YYYY     Description of the 'bar'
                                       alert-indication of the foo
                                       alert-category

   Each alert-category or alert-indication label MUST NOT exceed 27
   characters.







Alexeitsev, et al.       Expires August 30, 2010               [Page 14]

Internet-Draft               Alert-Info URNs               February 2010


7.2.  Alert-category

   This section defines the alert-identifier registration within the
   IANA registry defined in Section 7.1, using the alert-category labels
   'service', 'tone' and 'ringback'.

   The 'tone' alert-category label provides information about ringing
   tones rendered by a UAS to the callee.  The 'tone' alert-category
   label may be generated by a UAC or a proxy and transmitted in a
   INVITE request to the UAS.

   The 'ringback' alert-category label provides information about
   ringback tone rendered by a UAC to the caller.  The 'ringback' alert-
   category label may be generated by a UAS or a proxy and transmitted
   in a 180 Ringing response.

   The 'service' alert-category label describes special tones rendered
   by a UAC or the UAS to the caller or the callee.  The 'service'
   alert-category label may be generated by a UAC, a UAS or a proxy and
   transmitted in a INVITE request or a 180 Ringing response.

   The normal rendering is audio, however there can be other renderings
   applicable if needed by the user interface specifics.

7.3.  Initial IANA Registration

7.3.1.  Indications for PBX-tones

   The following table contains the initial IANA registration for "tone"
   top-level alert URN indications for PBX-tones.


       Top-level     Reference   Description
       Indication
       -----------------------------------------------------------
       normal         RFC XXXX    Normal ring-tone
       internal       RFC XXXX    Internal PBX caller PBX ring-tone
       external       RFC XXXX    External PBX caller PBX ring-tone

7.3.2.  Additional Indications for PBX-tones

   The following table contains the initial IANA registration for "tone"
   top-level alert URN indications for PBX-tones.








Alexeitsev, et al.       Expires August 30, 2010               [Page 15]

Internet-Draft               Alert-Info URNs               February 2010


       Top-level    Reference   Description
       Indication
       ------------------------------------------------
       priority     RFC XXXX    Priority ring-tone
       zip          RFC XXXX    zip ring-tone
       delayed      RFC XXXX    Delayed ring-tone

7.3.3.  Indications for Country-specific Ringback tones in the public
        telephone network

   For the alert-category "ringback", the alert-indication contains the
   ISO 3166-1 country code [ISO 3166-1].  For example, to indicate the
   Romanian ringback tone, the country-code "ro" is used and the Alert-
   Info URN will be <urn:alert:ringback:ro>.

7.3.4.  Indications for Services

   The following table contains the initial IANA registration for
   "service" alert-indications.


           Top-level           Reference   Description
           Indication
           --------------------------------------------------------
           call-waiting     RFC XXXX    Call waiting service indication
           forward          RFC XXXX    Call forwarding service
                                        indication
           transfer-recall  RFC XXXX    Transfer Recall service
                                        indication
           auto-callback    RFC XXXX    Auto Callback service indication
           hold-recall      RFC XXXX    Hold Recall service indication
           crisis           RFC XXXX    Crisis alerting indication

   Editor's Note: RFC XXXX should be replaced with this specification.

7.3.5.  Combination Rules for Alert URN Indications

   Senders may insert one or more Alert-Info URNs.  Following rules
   apply:

   - Senders should not insert two different URNs from one of the groups
   described above.

   - Any indication for PBX-tones can be combined with any additional
   indication for PBX-tones.

   - Indications and additional indications for PBX-tones can not be
   combined with indication for country specific ringback (they are sent



Alexeitsev, et al.       Expires August 30, 2010               [Page 16]

Internet-Draft               Alert-Info URNs               February 2010


   in diferent messages).

   -Indications and additional indications for PBX-tones as well as
   indication for country specific ringback can be combind with
   indications for services which can be sent in the same SIP message
   (INVITE or 180 Ringing).

   - For stand-alone additional indication for PBX-tones, the receiver
   should assume the "normal" indication for PBX-tones.

   UAs may have rules how to render specific combinations of Alert-Info
   URNs.  An UA receiving a combination of Alert-Info URN which it does
   not know how to render, it may choose to render a subset of it or to
   ignore the content of the Alert-Info URN Header.


8.  Internationalization Considerations

   The alert-identifier labels are protocol elements [RFC3536] and are
   not normally seen by users.  Thus, the character set for these
   elements is restricted, as described in Section 6.


9.  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, so privacy considerations do not
   apply to the URN.

   Provision of the specific indications from callee to caller may raise
   privacy issues.  Such provision SHALL always be explicitly authorised
   by the callee.


10.  Acknowledgements

   The draft is based on the ideas expressed by Paul Kyzivat on the
   BLISS WG mailing list.  The authors wish to thank Paul Kyzivat, Adam
   Roach, Dean Willis, Martin Huelsemann, Shida Schubert, John Elwell
   and Tom Taylor for their comments and suggestions.


11.  References







Alexeitsev, et al.       Expires August 30, 2010               [Page 17]

Internet-Draft               Alert-Info URNs               February 2010


11.1.  Normative References

   [RFC1123]  Braden, R., "Requirements for Internet Hosts - Application
              and Support", STD 3, RFC 1123, October 1989.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2141]  Moats, R., "URN Syntax", RFC 2141, May 1997.

   [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.

   [RFC3406]  Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
              "Uniform Resource Names (URN) Namespace Definition
              Mechanisms", BCP 66, RFC 3406, October 2002.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

11.2.  Informative References

   [I-D.ietf-bliss-shared-appearances]
              Johnston, A., Soroushnejad, M., and V. Venkataramanan,
              "Shared Appearances of a Session Initiation Protocol (SIP)
              Address of Record (AOR)",
              draft-ietf-bliss-shared-appearances-04 (work in progress),
              October 2009.

   [ISO 3166-1]
              "ISO 3166-1 English country names and code elements", http
              ://www.iso.org/iso/
              english_country_names_and_code_elements .

   [RFC3536]  Hoffman, P., "Terminology Used in Internationalization in
              the IETF", RFC 3536, May 2003.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

   [RFC5589]  Sparks, R., Johnston, A., and D. Petrie, "Session
              Initiation Protocol (SIP) Call Control - Transfer",
              BCP 149, RFC 5589, June 2009.

   [TS24.615]



Alexeitsev, et al.       Expires August 30, 2010               [Page 18]

Internet-Draft               Alert-Info URNs               February 2010


              "3GPP TS 24.615 Communication Waiting (CW) using IP
              Multimedia (IM) Core Network (CN) subsystem".


Authors' Addresses

   Denis Alexeitsev
   Deutsche Telekom AG
   Friedrich-Ebert-Allee
   Bonn  53113
   Germany

   Phone: +49-228-18112010
   Email: d.alexeitsev@telekom.de


   Laura Liess
   Deutsche Telekom AG
   Heinrich-Hertz Str 3-7
   Darmstadt, Hessen  64295
   Germany

   Phone: +49-6151-6282761
   Email: laura.liess.dt@gmail.com


   Roland  Jesske
   Deutsche Telekom AG
   Heinrich-Hertz Str 3-7
   Darmstadt, Hessen  64295
   Germany

   Phone: +49-6151-6282766
   Email: r.jesske@telekom.de


   Alan Johnston
   Avaya
   St. Louis, MO
   United States

   Phone:
   Email: alan.b.johnston@gmail.com








Alexeitsev, et al.       Expires August 30, 2010               [Page 19]

Internet-Draft               Alert-Info URNs               February 2010


   Anwar Siddiqui
   Avaya
   Milpitas, CA
   United States

   Phone:
   Email: anwars@avaya.com












































Alexeitsev, et al.       Expires August 30, 2010               [Page 20]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/