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

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

DISPATCH                                                   L. Liess, Ed.
Internet-Draft                                             D. Alexeitsev
Intended status: Standards Track                               R. Jesske
Expires: April 22, 2011                              Deutsche Telekom AG
                                                             A. Johnston
                                                             A. Siddiqui
                                                                   Avaya
                                                        October 19, 2010


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

Abstract

   The Session Initiation Protocol (SIP) supports the capability to
   provide a reference to a specific rendering to be used by the UA when
   the user is alerted.  This is done using the Alert-Info header.
   However, the reference addresses only network resources with specific
   rendering properties.  There is currently no support for predefined
   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 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 in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on April 22, 2011.



Liess, et al.            Expires April 22, 2011                 [Page 1]


Internet-Draft               Alert-Info URNs                October 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 Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Alert-Info Header Usage Change . . . . . . . . . . . . . .  5
     1.3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  6
   2.  Requirements . . . . . . . . . . . . . . . . . . . . . . . . .  6
   3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1.  PBX Ring Tones . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  normal . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.2.  external . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.3.  internal . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.4.  priority . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.5.  short  . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.1.6.  delayed  . . . . . . . . . . . . . . . . . . . . . . .  9
     3.2.  Service Tones  . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.1.  call-waiting . . . . . . . . . . . . . . . . . . . . .  9
       3.2.2.  forward  . . . . . . . . . . . . . . . . . . . . . . . 10
       3.2.3.  transfer-recall  . . . . . . . . . . . . . . . . . . . 10
       3.2.4.  auto-callback  . . . . . . . . . . . . . . . . . . . . 10
       3.2.5.  hold-recall  . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Country-specific ringback tone indications for the
           public telephone network . . . . . . . . . . . . . . . . . 10
   4.  Namespace Registration Template  . . . . . . . . . . . . . . . 10
   5.  Alert-Info URN Values Definitions  . . . . . . . . . . . . . . 13
     5.1.  Alert-category Values Definitions  . . . . . . . . . . . . 13
     5.2.  Alert-indication Values Definitions  . . . . . . . . . . . 13
       5.2.1.  Alert-Info URN Indication Values for the
               alert-category 'service' . . . . . . . . . . . . . . . 14
       5.2.2.  Alert-Info URN Indication Values for the
               alert-category 'source'  . . . . . . . . . . . . . . . 14
       5.2.3.  Alert-Info URN Indication Values for the



Liess, et al.            Expires April 22, 2011                 [Page 2]


Internet-Draft               Alert-Info URNs                October 2010


               alert-category 'priority'  . . . . . . . . . . . . . . 14
       5.2.4.  Alert-Info URN Indication  Values for the
               alert-category 'duration'  . . . . . . . . . . . . . . 15
       5.2.5.  Alert-Info URN Indication Values for the
               alert-category 'delay' . . . . . . . . . . . . . . . . 15
       5.2.6.  Alert-Info URN Indication Values for the
               alert-category 'locale'  . . . . . . . . . . . . . . . 15
   6.  Extensibility Rules  . . . . . . . . . . . . . . . . . . . . . 16
     6.1.  General Extensibility Rules  . . . . . . . . . . . . . . . 16
     6.2.  Extensions Rules for Independent Organizations . . . . . . 16
   7.  Combinations of URNs . . . . . . . . . . . . . . . . . . . . . 16
   8.  Priority Rules within Combinations of URNs . . . . . . . . . . 17
   9.  User Agent Behaviour . . . . . . . . . . . . . . . . . . . . . 17
   10. Proxy Behaviour  . . . . . . . . . . . . . . . . . . . . . . . 17
   11. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
     11.1. New alert identifiers  . . . . . . . . . . . . . . . . . . 18
     11.2. Initial IANA Registration  . . . . . . . . . . . . . . . . 18
       11.2.1. The "service" alert-category and alert-identifiers . . 18
       11.2.2. The "source" alert-category and alert-identifiers  . . 19
       11.2.3. The "priority" alert-category and alert-identifiers  . 20
       11.2.4. The "duration" alert-category and alert-identifiers  . 20
       11.2.5. The "delay"  alert-category and alert-identifiers  . . 20
       11.2.6. The "locale"  alert-category and alert-identifiers . . 21
   12. Internationalization Considerations  . . . . . . . . . . . . . 21
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     15.1. Normative References . . . . . . . . . . . . . . . . . . . 22
     15.2. Informative References . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23





















Liess, et al.            Expires April 22, 2011                 [Page 3]


Internet-Draft               Alert-Info URNs                October 2010


1.  Introduction

1.1.  Motivation

   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 [RFC3261] 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
   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 ring tone 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 semantic indications or names for rendering characteristics
   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 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-Info URN will increase SIP interoperability for this header
   field by replacing proprietary conventions used today.

   Using the 'alert' namespace provides syntax for several different
   application spaces, e. g.:




Liess, et al.            Expires April 22, 2011                 [Page 4]


Internet-Draft               Alert-Info URNs                October 2010


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

1.2.  Alert-Info Header Usage Change

   This specification changes the usage of the SIP Alert-Info header
   defined in the [RFC3261].  The Alert-Info header can be used in
   INVITE requests and in provisional 1xx responses excepting the 100
   response.  Backward compatibility issues are not expected, devices
   that do not understand an Alert-Info URN ignore it.






Liess, et al.            Expires April 22, 2011                 [Page 5]


Internet-Draft               Alert-Info URNs                October 2010


1.3.  Terminology

   This specification uses a number of terms to refer to the roles
   played by participants in, and objects of, the SIP Alerting for User
   Devices.  A "specifier" sends an "indication" or "identifier" (a URN
   in an Alert-Info header) 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 [ITU-T E.182])
   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 [ITU-T E.182]) is a signal advising the caller
   that a connection has been made and that a ring tone is being
   rendered to the callee.


2.  Requirements

   This section discusses the requirements for an identifier to
   transport the semantics of the signaling situation or the
   characteristics of the rendering.

   REQ-1: The mechanism will allow user agents (UAs) and proxies to
   provide in the Alert-Info SIP-header an indication which 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 identifier to be specified "by
   name" rather than "by value", to enable local policy decisions
   whether to use it or not.

   REQ-3: Indications must be able to represent a wide variety of
   signals, which have many largely-orthogonal characteristics.

   REQ-4: Indications include subsets which have distinctly different
   semantics, that is, they form disjoint "value spaces".  For example,
   some indications should describe the semantics of the signaling
   situation whereas others should describe the audio characteristics of
   the signal.  This implies that there is no single set of categories
   that can be used as independent coordinates of the value-space of
   indications.

   REQ-5: The set of indications must be able to support extensibility
   by a wide variety of organizations that are not coordinated with each



Liess, et al.            Expires April 22, 2011                 [Page 6]


Internet-Draft               Alert-Info URNs                October 2010


   other.  Extensions must 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

   - add further value spaces of indications whose semantics are not
   related to existing indications, and thus, whose categories differ
   from and do not interact with existing categories.

   REQ-6: 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.

   REQ-7: An indication is transmitted from a specifier to a renderer,
   which must base its rendering decision only on the indication.  In
   particular, there is no multi-message negotiation process or carrying
   of context from one indication to the next.

   REQ-8: The mechanism will allow transmission in the Alert-Info header
   of SIP INVITE requests and provisional 1xx responses excepting the
   100 responses.

   REQ-9: The renderer may be customized in ways that limit the set of
   signals that it can render, or it may be provided with a set of
   signals that have uncommon semantics.  (The canonical example is a UA
   for the hearing-impaired.)  (By REQ-7, the renderer has no way of
   transmitting this fact to the specifier.)

   REQ-10: If the specifier and the renderer have designs that are
   properly coordinated, the indications must be able to reliably carry
   all extensions that are supported in the coordinated designs.  In any
   other situation, it is not required from the renderer to perform the
   best possible rendering.

   REQ-11: In any situation, the renderer must be able to perform close
   to the best possible rendering that it could do even the specifier
   had specific knowledge of the renderer's capabilities.

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

   REQ-13: The mechanism will allow rendering common PBX ring tone



Liess, et al.            Expires April 22, 2011                 [Page 7]


Internet-Draft               Alert-Info URNs                October 2010


   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 values definition are not subject of this
   specification.)

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

   REQ-17: The mechanism will allow TDM 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 are not subject of this
   specification.)

   REQ-18: 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-19: The mechanism will allow storage of the actual encoding
   locally rather than fetching it.


3.  Use Cases

   This section describes some use cases for which the Alert-Info URN
   mechanism is needed today.

3.1.  PBX Ring Tones

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

3.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 ring tone needs to be specified.






Liess, et al.            Expires April 22, 2011                 [Page 8]


Internet-Draft               Alert-Info URNs                October 2010


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

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

3.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).

3.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".

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

3.2.  Service Tones

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

3.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, the callee's UAS ( or
   proxy) aware of the call waiting condition can add the call-waiting



Liess, et al.            Expires April 22, 2011                 [Page 9]


Internet-Draft               Alert-Info URNs                October 2010


   indication to the Alert-Info header in the 180 Ringing response.  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.

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

3.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 any other
   normal incoming call.

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

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

3.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 and
   would like to have this feature for SIP.


4.  Namespace Registration Template

   This section describes the registration template for the 'alert' URN



Liess, et al.            Expires April 22, 2011                [Page 10]


Internet-Draft               Alert-Info URNs                October 2010


   namespace identifier (NID) 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 the right-
      side of the alert-identifier, the alert-indication, by a colon.
      The general form is urn:alert:{alert-category}:{alert-indication}.

      In this specification, following alert-categories identifiers are
      described: "service" , "priority" , "source" , "duration", "delay"
      and "locale".  The alert-category set can be extended in the
      future.

      The categories are orthogonal.  Any Alert-Info URN defined in this
      specification is syntactically valid for ring and ringback tones
      and can be used in INVITE requests or in provisional 1xx responses
      excepting the 100 response.

      The alert-indications are hierarchical identifiers, consisting of
      one label or a sequence of labels separated by periods.  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.










Liess, et al.            Expires April 22, 2011                [Page 11]


Internet-Draft               Alert-Info URNs                October 2010


      The ABNF [RFC5234] for the Alert -Info URNs is shown below:



        alert-URN       = "URN:alert:" alert-identifier
        alert-identifier= alert-category ":" alert-indication
        alert-category  = name
        alert-indication= name *("." name)
        name = 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-Info URN.  The assignment
      of identifiers is described in Section 11.  The Alert-Info 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-Info URN identifies a
      logical service or tone, specified in the alert-indication
      registration (see Section 11).  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 11.

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





Liess, et al.            Expires April 22, 2011                [Page 12]


Internet-Draft               Alert-Info URNs                October 2010


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

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

   Rules for lexical equivalence:  Alert-Info 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-Info URNs at
      IANA.

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


5.  Alert-Info URN Values Definitions

5.1.  Alert-category Values Definitions

   Following alert-category values are defined in this document:

   - service

   - source

   - priority

   - duration

   - delay

   - locale

5.2.  Alert-indication Values Definitions

   This section describes the Alert-Info URN indication values for the
   alert-categories defined in this document.

   For each alert-category, a default indication is defined, which is
   essentially a no-operation Alert-Info URN and should be treated by
   the UA as if no Alert-Info URN for the respective category is
   present.  Alert-Info URN default indications are most useful when



Liess, et al.            Expires April 22, 2011                [Page 13]


Internet-Draft               Alert-Info URNs                October 2010


   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.

5.2.1.  Alert-Info URN Indication Values for the alert-category
        'service'

   - normal (default)

   - call-waiting

   - forward

   - recall.callback

   - recall.hold

   - recall.transfer

   - private.<private-name>

   Examples: urn:alert:service:call-waiting or
   urn:alert:service:recall.transfer.

5.2.2.  Alert-Info URN Indication Values for the alert-category 'source'

   - unclassified (default)

   - internal

   - external

   - friend

   - family

   - private.<private-name>

   Examples: urn:alert:source:external.

5.2.3.  Alert-Info URN Indication Values for the alert-category
        'priority'








Liess, et al.            Expires April 22, 2011                [Page 14]


Internet-Draft               Alert-Info URNs                October 2010


   - normal (default)

   - low

   - high

   - private.<private-name>

   Examples: urn:alert:priority:high.

5.2.4.  Alert-Info URN Indication  Values for the alert-category
        'duration'

   - normal (default)

   - short

   - long

   - private.<private-name>

   Examples: urn:alert:duration:short.

5.2.5.  Alert-Info URN Indication Values for the alert-category 'delay'

   - none (default)

   - yes

   - private.<private-name>

   Examples: urn:alert:delay:yes .

5.2.6.  Alert-Info URN Indication Values for the alert-category 'locale'

   - default (default)

   - country.<ISO 3166-1 country code>

   - private.<private-name>

   The ISO 3166-1 country code [ISO 3166-1] is used to inform the UA 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>.






Liess, et al.            Expires April 22, 2011                [Page 15]


Internet-Draft               Alert-Info URNs                October 2010


6.  Extensibility Rules

6.1.  General Extensibility Rules

   TBD

6.2.  Extensions Rules for Independent Organizations

   The "private.<private-name>" syntax is for extensions specific to
   independent organizations.  The "<private-name>" is used in the form
   of a "reverse FQDN" such as is used for Java package names.  This
   gives a way of assigning unique names without the need for a new
   registry.  The namespace for each alert category is independent.
   Those assigning new names must ensure they are in a position to
   assign names uniquely for the FQDN they choose.  For example, a
   private company might want to define:
   urn:alert:source:private.com.example.customer

   Adding new categories and adding alert-indication values other than
   via the "private" mechanism is standards action.


7.  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
   separated by a comma.  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 categories are orthogonal.  Any Alert-Info URN defined in this
   specification is syntactically valid for ring and for ringback and
   can be used in an INVITE or in provisional 1xx responses excepting
   the 100 response.  There can be at most one instance of each alert-
   category in an Alert-Info header.  In principle any combination of
   Alert-Info URNs with different "alert-category" is valid and can be
   used for either ring or ringback, though some combinations may not
   make sense.  The receiving UA should make the decision about what to
   render to the user and what device it is rendered on depending on the
   value of the Alert-Info URN and the kind of the received message
   (INVITE or provisional response).  Typically, the same UA will do the
   rendering of a particular Alert-Info URN received in an INVITE
   differently from the rendering of the same Alert-Info URN received in
   a provisional response.  The exact way in which the various
   categories are combined for rendering is left as an implementation
   issue.  The implementation is free to ignore any or all received



Liess, et al.            Expires April 22, 2011                [Page 16]


Internet-Draft               Alert-Info URNs                October 2010


   Alert-Info URNs.


8.  Priority Rules within Combinations of URNs

   TBD


9.  User Agent Behaviour

   Upon receiving a SIP INVITE request or a SIP provisional response
   with an Alert-Info header that contains a single or multiple Alert-
   Info 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.


10.  Proxy Behaviour

   A SIP proxy MAY add a URN or multiple URNs to the Alert-Info header
   in a SIP request or a provisional 1xx response excepting 100 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-Info 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
   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>


11.  IANA Considerations

   This section registers a new URN namespace identifier (NID) in
   accordance with RFC 3406 with the registration template provided in
   Section 4 .





Liess, et al.            Expires April 22, 2011                [Page 17]


Internet-Draft               Alert-Info URNs                October 2010


11.1.  New alert identifiers

   Alert URN identifiers 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-Info URN
   identifier requires IANA action.  The policy for adding a new alert
   category is 'Standards Action'.  (This document defines the alert
   categories 'service', 'source', 'priority', 'duration', 'delay' and
   'locale'. ) The policy for assigning labels to alert-indications and
   the rules to combine them may differ for each alert-category and MUST
   be defined by the document describing the corresponding alert
   category.  The entries in the registration table have the following
   format:


      alert-category/      Reference    Description
      alert-identifier
      ---------------------------------------------------------------
      foo                  RFCxyz       Description of the 'foo'
                                        alert-category
      foo:bar              RFCabc       Description of the 'foo:bar'
                                        alert-identifier


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

11.2.  Initial IANA Registration

11.2.1.   The "service" alert-category and alert-identifiers

   The following table contains the initial IANA registration for the
   "service" alert-category and alert-identifiers.  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 which has been
   initiated.















Liess, et al.            Expires April 22, 2011                [Page 18]


Internet-Draft               Alert-Info URNs                October 2010


   alert-category/                Reference  Description
   alert-identifier
   -----------------------------------------------------------
   service                        RFC XXXX  Alert-category for "service"
                                            alert-identifiers.
   service:normal                 RFC XXXX  Normal ring /rinback
                                            rendering (default value).
   service:call-waiting           RFC XXXX  Call waiting was
                                            initiated at the other side
                                            of the call.
   service:forward                RFC XXXX  Call has been forwarded.
   service:recall.calback         RFC XXXX  Recall due to callback.
   service:recall.hold            RFC XXXX  Recall due to call hold.
   service:recall.transfer        RFC XXXX  Recall due to callback.
   service:private.<private-name> RFC XXXX  Reserved for private
                                            extensions.

11.2.2.  The "source" alert-category and alert-identifiers

   The following table contains the initial IANA registration for the
   "source" alert-category and alert-identifiers.  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 XXXX  Alert-category for "source"
                                           alert-identifiers
   source:unclassified           RFC XXXX  Unclassified ring /rinback
                                           rendering (default value)
   source:internal               RFC XXXX  User at the other side of
                                           the call is internal to the
                                           enterprise or PBX system.
   source:external               RFC XXXX  User at the other side of
                                           the call is internal to the
                                           enterprise or PBX system.
   source:friend                 RFC XXXX  User at the other side of
                                           the call is a friend.
   source:family                 RFC XXXX  User at the other side of
                                           the call is a family member.
   source:private.<private-name> RFC XXXX  Reserved for private
                                           extensions.








Liess, et al.            Expires April 22, 2011                [Page 19]


Internet-Draft               Alert-Info URNs                October 2010


11.2.3.   The "priority" alert-category and alert-identifiers

   The following table contains the initial IANA registration for the
   "priority" alert-category and alert-identifiers.  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 XXXX  Alert-category for
                                            "priority" alert-
                                             identifiers.
   priority:normal                 RFC XXXX  Normal ring /rinback
                                             rendering (default value).
   priority:low                    RFC XXXX  Low priority call.
   priority:high                   RFC XXXX  High priority call.
   priority:private.<private-name> RFC XXXX  Reserved for private
                                             extensions.

11.2.4.  The "duration" alert-category and alert-identifiers

   The following table contains the initial IANA registration for the
   "duration" alert-category and alert-identifiers.  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 XXXX  Alert-category for "duration"
                                           alert-identifiers
 duration:normal                 RFC XXXX  Normal ring /rinback
                                           rendering (default value)
 duration:short                  RFC XXXX  Shorter than normal
 duration:long                   RFC XXXX  Longer than normal
 duration:private.<private-name> RFC XXXX  Reserved for private
                                           extensions.

11.2.5.  The "delay"  alert-category and alert-identifiers

   The following table contains the initial IANA registration for the
   "delay" alert-category and alert-identifiers.  The value of this
   indicator provides information about the delay of the alerting
   signals.






Liess, et al.            Expires April 22, 2011                [Page 20]


Internet-Draft               Alert-Info URNs                October 2010


   alert-category/              Reference  Description
   alert-identifier
   -----------------------------------------------------------
   delay                        RFC XXXX  Alert-category for "delay"
                                          alert-identifiers
   delay:none                   RFC XXXX  Immediate alerting
                                          (default value)
   delay:yes                    RFC XXXX  Delayed alerting
   delay:private.<private-name> RFC XXXX  Reserved for private
                                          extensions.

11.2.6.  The "locale"  alert-category and alert-identifiers

   The following table contains the initial IANA registration for the
   "locale" alert-category and alert-identifiers.  The value of this
   indicator provides information about the location of the user at the
   other side of the call.

   alert-category/               Reference  Description
   alert-identifier
   -----------------------------------------------------------
   locale                        RFC XXXX  Alert-category for "locale"
                                           alert-identifiers
   locale:default                RFC XXXX  Alerting not location
                                           specific
                                           (default value)
   locale:country.<ISO 3166-1 country code>
                                 RFC XXXX  Country-specific alerting
   locale:private.<private-name> RFC XXXX  Reserved for private
                                           extensions.


12.  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 11.


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



Liess, et al.            Expires April 22, 2011                [Page 21]


Internet-Draft               Alert-Info URNs                October 2010


   by the callee.


14.  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 and
   Dale Worley for their major contributions to this draft and also Adam
   Roach, Dean Willis, Martin Huelsemann, Shida Schubert, John Elwell
   and Tom Taylor for their comments and suggestions.


15.  References

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

15.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-06 (work in progress),
              July 2010.

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



Liess, et al.            Expires April 22, 2011                [Page 22]


Internet-Draft               Alert-Info URNs                October 2010


              english_country_names_and_code_elements .

   [ITU-T E.182]
              "Application of tones and recorded announcements in
              telephone services".

   [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]
              "3GPP TS 24.615 Communication Waiting (CW) using IP
              Multimedia (IM) Core Network (CN) subsystem".


Authors' Addresses

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

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


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

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









Liess, et al.            Expires April 22, 2011                [Page 23]


Internet-Draft               Alert-Info URNs                October 2010


   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


   Anwar Siddiqui
   Avaya
   Milpitas, CA
   United States

   Phone:
   Email: anwars@avaya.com

























Liess, et al.            Expires April 22, 2011                [Page 24]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/