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

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 RFC 4240

Network Working Group                                        W. O'Connor
Internet Draft                                                 E. Burger
Document: draft-burger-sipping-netann-01.txt                 J. Van Dyke
Category: Standards Track                       SnowShore Networks, Inc.
Expires: May 2002                                      November 21, 2001


                     Network Announcements with SIP


Status of this Memo
   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   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 document is the result of a chartered SIPPING work group item.


1. Abstract

   In SIP-based networks [2], there is a need to provide announcements.
   In some situations, one must play the announcement without providing
   an answer indication.  In others, one must play the announcement
   after completing call setup.  This document describes how to provide
   such announcements in a SIP-based network.  The method described
   here is a media server service instance.  The document [3] describes
   generic URI's for media server service instances.

2. Conventions used in this document

   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 RFC-2119 [4].


O'Connor, et. Al.         Expires 5/21/2002                         1 
                    Network Announcements with SIP       November 2001


3. Overview

   A network announcement is the delivery of an audio resource, such as
   a prompt file, to a terminal device.

   There are two types of network announcements.  The differentiating
   characteristic between the two types is whether the network fully
   sets up the call before playing the announcement.  The analog in the
   PSTN is whether answer supervision is supplied; i.e. does the
   announcement server answer the call prior to delivering the
   announcement.

   Playing an announcement after call setup is straightforward.  First,
   the requesting device issues an INVITE to the media server
   requesting the announcement service.  The media server negotiates
   the SDP and responds with a 200 OK.  After receiving the ACK from
   the requesting device, the media server plays the requested prompt
   and issues a BYE to the requesting device.

   In replicating and expanding on the existing telephone network,
   there is a need to play announcements during call setup.  That is,
   the network delivers media to the caller before the setup completes.
   Network operators need this capability to provide informational
   network announcements, such as "The person you are trying to reach
   is unavailable.  Good Bye." or "We are sorry, but all circuits are
   busy.  Please try your call again later.  Good Bye."

   Note that simply redirecting the caller to a media server, with the
   media server issuing a 200 OK response, is not appropriate.  The
   call has not completed successfully.  To support the appropriate
   paradigm, the media server issues a 100 TRYING response, followed
   immediately by a 183 SESSION PROGRESS response with SDP.  This
   enables the media server to send early media to the caller.  The
   media server sends the requested audio.  After playing the audio,
   the media server issues a 487 REQUEST TERMINATED response code to
   the requesting device.

   If the media server does not support announcements, it MUST respond
   with the 488 NOT ACCEPTABLE HERE response code, as specified by [3].
   If the media server supports announcements, but it cannot find the
   referenced URI, it MUST respond with the 404 NOT FOUND response
   code, as specified by [3].

   If the media server receives an INVITE for the announcement service
   without a "play=" parameter, it MUST respond with the 404 NOT FOUND
   response code, as there is no default value for the announcement
   service.

   If there is an error retrieving the announcement, the media server
   MUST respond with an appropriate 4xx error code reflecting the
   error.


O'Connor, et. al.          Expires 5/21/02                          2 
                    Network Announcements with SIP       November 2001


4. Announcement Service

   The Request URI fully describes the announcement service through the
   use of the user part of the address and additional URI parameters,
   as described in [3].  The user portion of the address, "annc",
   specifies the announcement service on the media server.  The service
   has several associated URI parameters that control the content and
   delivery of the announcement.  These parameters are described below:

   "play=" specifies the audio resource or announcement sequence to be
   played.

   "early=" Specifies whether early media treatment is desired.

   "repeat=" Specifies how many times the media server should repeat
   the announcement or sequence named by the "play=" parameter.

   "delay=" Specifies a delay interval between announcement
   repetitions.  The delay is measured in milliseconds.

   "duration=" Specifies the maximum duration of the announcement.  The
   media server will discontinue the announcement and end the call if
   the maximum duration has been reached.  The duration is measured in
   milliseconds.

   "locale=" Specifies the language and country variant of the
   announcement sequence named in the "play=" parameter.  The language
   is defined as a two letter code per ISO 639 [5].  The country
   variant is also defined as a two letter code per ISO 3166 [6].
   These elements are concatenated with a single underbar (%x5F)
   character.

   "param[n]=" Provides a mechanism for passing values that are to be
   substituted into an announcement sequence.  Up to 9 parameters
   ("param1=" through "param9=") may be specified.

   The "play=" parameter is mandatory and MUST be present.  All other
   parameters are OPTIONAL.

   NOTE: Some encodings are not self-describing.  Should we specify
   something like content-type?  Alternatively, how about a "media="
   parameter?

   The form of the SIP Request URI for announcements is as follows.
   Note that the backslash, CRLF, and spacing before the "play=" is for
   readability purposes only.

        sip:annc@ms2.carrier.net; \
          play="http://audio.carrier.net/allcircuitsbusy.g711"; \
            early=yes
        sip:annc@ms2.carrier.net; \

   play="file://fileserver.carrier.net/geminii/yourHoroscope.wav"

O'Connor, et. al.          Expires 5/21/02                          3 
                    Network Announcements with SIP       November 2001



5. Operation

   The scenarios below assume there is a SIP Proxy, application server,
   or SoftSwitch between the caller and the media server.  However, the
   announcement service works as described below even if the caller
   invokes the service directly.  We chose to discuss the proxy case,
   as it will be the most common case.

   As described above, the "early=" parameter determines whether the
   media server plays the prompt after call setup or as early media.
   The default value for the "early=" parameter MUST BE "yes".  That
   is, the default action is for the media server to play the prompt
   before establishing the call.  We envision that that this service
   will be most commonly used for network announcements which require
   early media, hence that is the default behavior.

5.1. Established Call Prompting

5.1.1. Description

   The caller issues an INVITE to the serving SIP Proxy.  The SIP Proxy
   determines what audio prompt to play to the caller.  The proxy
   responds to the caller with 100 TRYING.

   The proxy issues an INVITE to the media server, requesting the
   appropriate prompt to play coded in the play= parameter.  The INVITE
   MUST contain the parameter "early=no" to invoke the Established Call
   Prompting service.  The media server responds with 200 OK.  The
   proxy sends a 200 OK to the caller.  The caller then issues an ACK.
   The proxy then issues an ACK to the media server.

   With the call setup, the media server plays the requested prompt.
   When the media server completes the play of the prompt, it issues a
   BYE to the proxy.  The proxy then issues a BYE to the caller.

O'Connor, et. al.          Expires 5/21/02                          4 
                    Network Announcements with SIP       November 2001


5.1.2. Protocol Diagram

   Caller                   Proxy                 Media Server
     |   INVITE               |                        |
     |----------------------->|   INVITE               |
     |   100 TRYING           |----------------------->|
     |<-----------------------|   200 OK               |
     |   200 OK               |<-----------------------|
     |<-----------------------|                        |
     |   ACK                  |                        |
     |----------------------->|   ACK                  |
     |                        |----------------------->|
     |                        |                        |
     |              Play Announcement (RTP)            |
     |<================================================|
     |                        |                        |
     |                        |   BYE                  |
     |   BYE                  |<-----------------------|
     |<-----------------------|                        |
     |   200 OK               |    200 OK              |
     |----------------------->|----------------------->|
     |                        |                        |


5.2. Early Media Prompting

5.2.1. Description

   The caller issues an INVITE to the serving SIP Proxy.  Normally, the
   SIP Proxy would complete the call to the requested destination.
   However, if the destination is not available, the proxy will request
   a media server to play an audio prompt to the caller.  The proxy
   responds with a 100 TRYING.

   The proxy issues an INVITE to the media server, requesting the
   appropriate prompt to play.  The INVITE MUST contain the parameter
   "early=yes" or omit the "early=" parameter to invoke the Early Media
   Prompting service.  The media server responds with 100 TRYING
   followed by 183 SESSION PROGRESS.  At that point, the media server
   sends the announcement to the caller.  The document [7] describes
   the 183 SESSION PROGRESS result code.

   After the media server completes the streaming of the prompt, it
   MUST send a 487 REQUEST TERMINATED to the Proxy.

   Note: When the early media service is used the requester is
   implicitly asking the media server to cancel the transaction as soon
   as the announcement is played.  Since 487 is associated with an
   explicit CANCEL request it seems appropriate for this use as well.
   The 00 version specified 486 BUSY HERE as the appropriate response
   in this scenario.  However, 486 might could potentially be mis-
   interpreted as a true busy by the requester so its use has been
   deprecated.

O'Connor, et. al.          Expires 5/21/02                          5 
                    Network Announcements with SIP       November 2001



   The proxy sends the appropriate error response to the caller.  That
   could be 487 or any other appropriate code reflective of the failure
   situation.

5.2.2. Protocol Diagram

   Caller                   Proxy                 Media Server
     |   INVITE               |                        |
     |----------------------->|   INVITE               |
     |   100 TRYING           |----------------------->|
     |<-----------------------|   100 TRYING           |
     |                        |<-----------------------|
     |                        |   183 SESSION PROGRESS |
     |   183 SESSION PROGRESS |<-----------------------|
     |<-----------------------|                        |
     |                        |                        |
     |              Play Announcement (RTP)            |
     |<================================================|
     |                        | 487 REQUEST TERMINATED |
     | 487 REQUEST TERMINATED |<-----------------------|
     |<-----------------------|                        |
     |   ACK                  |    ACK                 |
     |----------------------->|----------------------->|
     |                        |                        |


6. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [8].
   ANNC-URL        = "sip:" annc-ind "@" hostport
                       annc-parameters

   annc-ind        = "annc"

   annc-parameters = ";" play-param [ ";" early-param ]
        [ ";" delay-param] [ ";" duration-param ] [ ";" repeat-param ]
        [ ";" locale-param ] [ ";" variable-params ]

   play-param      = "play=" prompt-url

   early-param     = "early=" ( "yes" | "no" )

   delay-param     = "delay=" delay-value

   delay-value     = 1*DIGIT

   duration-param  = "duration=" duration-value

   duration-value  = 1*DIGIT

   repeat-param    = "repeat=" repeat-value

O'Connor, et. al.          Expires 5/21/02                          6 
                    Network Announcements with SIP       November 2001



   repeat-value    = 1*DIGIT

   locale-param    = "locale=" locale-value

   locale-value    = 2ALPHA %x5F 2ALPHA

   variable-params = param-name "=" variable-value

   param-name      = "param" DIGIT ; e.g "param1"

   variable-value  = 1*(ALPHA | DIGIT)

   The locale-value consists of a 2 letter language code as specified
   in ISO 639 [5]and a 2 letter country code specified in ISO 3166 [6]
   separated by a single underbar (%x5Fh) character.

   The definition of hostport is as specified by [2].

   The syntax of prompt-url consists of a URL scheme as specified by
   [9] or a special token indicating a provisioned announcement
   sequence.  We expect the URL to be one of the following schemes.
     o http
     o ftp
     o file (referencing a local or nfs (RFC 2224) location)

   If a provisioned announcement sequence is to be played the value of
   prompt-url will have the following form:
   prompt-url      = "/provisioned/" announcement-id

   announcement-id = 1*(ALPHA | DIGIT)

   This document is strictly focused on the SIP interface for the
   announcement service and as such does not detail how announcement
   sequences are provisoned or defined.

7. Security Considerations

   Untrusted network elements could use the protocol described here for
   providing information services.  Many extant billing arrangements
   are for completed calls.  Successful call completion occurs with a
   2xx result code.

8. References


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2  Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP:
      Session Initiation Protocol", RFC 2543, March 1999.



O'Connor, et. al.          Expires 5/21/02                          7 
                    Network Announcements with SIP       November 2001



   3  Van Dyke, J. and Burger, E., "SIP URI Conventions for Media
      Servers", draft-ietf-sipping-msuri-01.txt, November 2001, work in
      progress.

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

   5  ISO 639, "Codes for the representation of names of languages",
      1998.

   6  ISO 3166, "Codes for the representation of names of countries and
      their subdivisions", 1997.

   7  Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP:
      Session Initiation Protocol", draft-ietf-sip-rfc2543bis-05.txt,
      October 2001, work in progress.

   8  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, November 1997.

   9  Berners-Lee, T., Fielding, R., and Masinter, L., "Uniform
      Resource Identifiers (URI): Generic Syntax", RFC 2396, August
      1988.


9. Changes Made in Version 01
     o Added duration, repeat, delay, locale and variable parameters.
     o Added the ability to reference a provisioned announcement.
     o Made early media treatment the default behavior for the
        service.
     o 487 REQUEST TERMINATED replaces 486 BUSY HERE as the media
        serverËs final response when early media treatment is desired.


10. Acknowledgments
   We would like to thank Kevin Summers and Ravindra Kabre of Sonus
   Networks for their constructive comments.


11. Author's Addresses

   Walter O'Connor
   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA

   Phone: 978/367-8411
   Email: woconnor@snowshore.com


   Eric Burger

O'Connor, et. al.          Expires 5/21/02                          8 
                    Network Announcements with SIP       November 2001


   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA

   Phone: 978/367-8403
   Email: eburger@snowshore.com


   Jeff Van Dyke
   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA

   Phone: +1 978/367-8405
   Email: jvandyke@snowshore.com



O'Connor, et. al.          Expires 5/21/02                          9 
                    Network Announcements with SIP       November 2001



Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.  This
   document and the information contained herein is provided on an "AS
   IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
   FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT
   LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL
   NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY
   OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   The Internet Society currently provides funding for the RFC Editor
   function.


O'Connor, et. al.          Expires 5/21/02                         10


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