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

Versions: 00 01 02

BLISS                                                      D. Alexeitsev
Internet-Draft                                                  L. Liess
Intended status: Standards Track                               R. Jesske
Expires: January 14, 2010                                  M. Huelsemann
                                                     Deutsche Telekom AG
                                                             A. Johnston
                                                                   Avaya
                                                           July 13, 2009


       Alert-Info URNs for the Session Initiation Protocol (SIP)
               draft-alexeitsev-bliss-alert-info-urns-02

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  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.

   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
   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 January 14, 2010.

Copyright Notice




Alexeitsev, et al.      Expires January 14, 2010                [Page 1]


Internet-Draft               Alert-Info URNs                   July 2009


   Copyright (c) 2009 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 in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

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 tied rendering.  To overcome this limitations and
   support new applications a family of the URNs 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].

























Alexeitsev, et al.      Expires January 14, 2010                [Page 2]


Internet-Draft               Alert-Info URNs                   July 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Registration template  . . . . . . . . . . . . . . . . . . . .  5
   3.  Top Level Alert URN Indication Definitions . . . . . . . . . .  8
     3.1.  PBX Tones  . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.1.  normal . . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.2.  external . . . . . . . . . . . . . . . . . . . . . . .  8
       3.1.3.  internal . . . . . . . . . . . . . . . . . . . . . . .  8
     3.2.  Service Tones  . . . . . . . . . . . . . . . . . . . . . .  8
       3.2.1.  call-waiting . . . . . . . . . . . . . . . . . . . . .  9
       3.2.2.  forward  . . . . . . . . . . . . . . . . . . . . . . .  9
       3.2.3.  transfer-recall  . . . . . . . . . . . . . . . . . . .  9
       3.2.4.  auto-callback  . . . . . . . . . . . . . . . . . . . .  9
       3.2.5.  hold-recall  . . . . . . . . . . . . . . . . . . . . .  9
       3.2.6.  crisis . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.  Alert Level URN Sub-Indications Definitions  . . . . . . . . . 10
     4.1.  priority . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.2.  short  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  delayed  . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5.  User Agent Behavior  . . . . . . . . . . . . . . . . . . . . . 10
   6.  Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
     7.1.  New alert-identifiers  . . . . . . . . . . . . . . . . . . 11
     7.2.  Alert-category . . . . . . . . . . . . . . . . . . . . . . 12
     7.3.  Initial IANA Registration  . . . . . . . . . . . . . . . . 12
   8.  Internationalization Considerations  . . . . . . . . . . . . . 13
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     11.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  An Appendix . . . . . . . . . . . . . . . . . . . . . 15
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

















Alexeitsev, et al.      Expires January 14, 2010                [Page 3]


Internet-Draft               Alert-Info URNs                   July 2009


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.
   Current solution is sufficient for human users that share the same
   understanding of the tones.  However 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.  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 and support new applications 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.

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

   o  Names for common ring-tones generated by PBX phone 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 services such as call waiting or automatic callback, not
      tied to any particular rendering.

   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.




Alexeitsev, et al.      Expires January 14, 2010                [Page 4]


Internet-Draft               Alert-Info URNs                   July 2009


   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.

   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.


2.  Registration template

   Below is the registration template for the 'alert' URN scheme
   according to the RFC 3406 [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:

      Namespace Specific String (NSS) in the 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, two categories of alert-
      identifiers are described: the "tone" alert-identifiers and the
      "service" alert-identifiers.

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






Alexeitsev, et al.      Expires January 14, 2010                [Page 5]


Internet-Draft               Alert-Info URNs                   July 2009


         urn:alert:tone:{tone-indication}

      where the tone-indication identifies the semantic of a tone.



      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.

      The tone-indication and 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 or service-
      indication.  In other words, if a tone 'x.y.z' exists, the tone
      'x' and 'x.y' are also valid tone.  Each alert indication
      identifier SHALL explicitly define it's validity respective the
      sub-indications.



      The ABNF [RFC4234] 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"/"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





Alexeitsev, et al.      Expires January 14, 2010                [Page 6]


Internet-Draft               Alert-Info URNs                   July 2009


   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 the IANA Considerations (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 IANA Considerations (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).

   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 the IANA Considerations (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.







Alexeitsev, et al.      Expires January 14, 2010                [Page 7]


Internet-Draft               Alert-Info URNs                   July 2009


   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.


3.  Top Level Alert URN Indication Definitions

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

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

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

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

3.2.  Service Tones

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







Alexeitsev, et al.      Expires January 14, 2010                [Page 8]


Internet-Draft               Alert-Info URNs                   July 2009


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

3.2.2.  forward

   This feature is used in a 180 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.

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.  The urn:alert:service:transfer-recall should
   be used for this case.

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.  The
   urn:alert:service:auto-callback should be used for this case.

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



Alexeitsev, et al.      Expires January 14, 2010                [Page 9]


Internet-Draft               Alert-Info URNs                   July 2009


   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.

3.2.6.  crisis

   This feature is used for emergency announcements sent over PBX
   systems such as building evacuations, alarms, etc.  This service tone
   is used to distinguish this case from any other normal incoming call.
   The urn:alert:service:crisis should be used for this case.


4.  Alert Level URN Sub-Indications Definitions

   These sub-indications can be applied to any of the Top Level Alert
   Indications defined in the previous sections.

4.1.  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:internal.priority would be used to generate alerting
   for a priority internal PBX call.

4.2.  short

   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:normal.short would generate a shorter than
   normal ring-tone.

4.3.  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:external.delayed
   would generate an external ring-tone, delayed by a few seconds.


5.  User Agent Behavior

   Upon receiving a SIP request or a SIP 180 Ringing response with an
   Alert-Info header that contains a single or multiple 'alert' URNs,



Alexeitsev, et al.      Expires January 14, 2010               [Page 10]


Internet-Draft               Alert-Info URNs                   July 2009


   the User Agent (UA) attempts to match the received URNs with the
   known indications.  If no match is found, the User Agent (UA) ignores
   the received 'alert' URNs and proceeds with the normal operation.  If
   the one or multiple URNs matches a known indication, the User Agent
   (UA) renders the indication(s) to the user according to the tone or
   service identifier in the received alert URN.  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 the
   'alert' URNs and URIs to the Alert-Info header that may cause
   disturbing rendering interference at the recepient'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>


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 two alert-identifiers
   described in this document , service and tone, 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 identifiers and alert-indications are identified by labels
   managed by IANA, according to the processes outlined in [RFC2434] 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' and 'tone'.)  The
   policy for assigning labels to alert-indications may differ for each



Alexeitsev, et al.      Expires January 14, 2010               [Page 11]


Internet-Draft               Alert-Info URNs                   July 2009


   alert-identifier category and MUST be defined by the document
   describing the coresponding alert-identifier.

   Entries in the registration table have the following format:

   Category/Indication  Reference  Description
   --------------------------------------------------------------------
   foo                  RFC XXXX     Description of the 'foo' alert-category
   bar                  RFC YYYY     Description of the 'bar' alert-indication
                                     of the foo alert-category
   bar.moo              RFC ZZZZ     Description of the 'bar.moo'
                                     alert-indication of the foo alert-category

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

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' and 'tone'.

   The 'tone' alert-category label provides information about ringing
   tones generated by a UAS and rendered to the callee in response to an
   INVITE.

   The 'service' alert-category label describes tones that should be
   generated by the UAC or UAS and rendered to the caller or calee upon
   receipt of a 180 response or a request.  The normal rendering is
   audio, however there can be other renderings applicable if needed by
   the user interface specifics.

7.3.  Initial IANA Registration

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















Alexeitsev, et al.      Expires January 14, 2010               [Page 12]


Internet-Draft               Alert-Info URNs                   July 2009


Alert-Indication       Reference  Description
--------------------------------------------------------
normal                 RFC XXXX    Normal ring-tone
normal.priority        RFC XXXX    Priority normal ring-tone
normal.short           RFC XXXX    Short normal ring-tone
normal.delayed         RFC XXXX    Delayed normal ring-tone
internal               RFC XXXX    Internal PBX caller PBX ring-tone
internal.priority      RFC XXXX    Priority internal PBX caller PBX ring-tone
internal.short         RFC XXXX    Short internal PBX caller PBX ring-tone
internal.delayed       RFC XXXX    Delayed internal PBX caller PBX ring-tone
external               RFC XXXX    External PBX caller PBX ring-tone
external.priority      RFC XXXX    Priority external PBX caller PBX ring-tone
external.short         RFC XXXX    Short external PBX caller PBX ring-tone
external.delayed       RFC XXXX    Delayed external PBX caller PBX ring-tone

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


   Alert-Indication             Reference  Description
   --------------------------------------------------------
   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.


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.



Alexeitsev, et al.      Expires January 14, 2010               [Page 13]


Internet-Draft               Alert-Info URNs                   July 2009


10.  Acknowledgements

   The draft is based on the ideas expressed by Paul Kyzivat on the
   BLISS WG mailing list.


11.  References

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.

   [RFC4234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

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-02 (work in progress),
              March 2009.

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
              October 1998.

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

   [RFC5589]  Sparks, R., Johnston, A., and D. Petrie, "Session
              Initiation Protocol (SIP) Call Control - Transfer",



Alexeitsev, et al.      Expires January 14, 2010               [Page 14]


Internet-Draft               Alert-Info URNs                   July 2009


              BCP 149, RFC 5589, June 2009.

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


Appendix A.  An Appendix


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: l.liess@telekom.de


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

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











Alexeitsev, et al.      Expires January 14, 2010               [Page 15]


Internet-Draft               Alert-Info URNs                   July 2009


   Martin Huelsemann
   Deutsche Telekom AG
   Heinrich-Hertz Str 3-7
   Darmstadt, Hessen  64295
   Germany

   Phone: +49-6151-6282765
   Email: martin.huelsemann@telekom.de


   Alan Johnston
   Avaya
   St. Louis, MO  63124
   United States

   Phone:
   Email: alan@sipstation.com


































Alexeitsev, et al.      Expires January 14, 2010               [Page 16]


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