Network Working Group                                       W. O'Connor
Internet Draft                                                E. Burger
Document: draft-burger-sipping-netann-00.txt                J. Van Dyke
Category: Standards Track                      SnowShore Networks, Inc.
Expires January 2002                                      July 12, 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.



. 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
   media server service instances.


. 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 1/12/2002                         1

                    Network Announcements with SIP           July 2001


. 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 the network plays the prompt before or after answer
   supervision.

   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 486 BUSY HERE 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 1/12/02                          2

                    Network Announcements with SIP           July 2001


. Simple 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 two URI
   parameters "play=" and "early=" specify the audio resource to play
   and whether early media is desired.

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


. 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 "no".  That is,
   the default action is for the media server to play the prompt after
   establishing the call.

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 either the parameter "early=no" or leave out the early=
   parameter to invoke the Established Call Prompting service.  The
   media server responds with 200 OK.  The proxy sends a 200 OK to the


O'Connor, et. al.          Expires 1/12/02                          3

                    Network Announcements with SIP           July 2001


   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.

5.1.2. Protocol Diagram

   Caller                   Proxy                 Media Server
     |   INVITE               |                        |
     |----------------------->|   INVITE               |
     |   100 TRYING           |----------------------->|
     |<-----------------------|   200 OK               |
     |   200 OK               |<-----------------------|
     |<-----------------------|   200 OK               |
     |   ACK                  |                        |
     |----------------------->|   ACK                  |
     |   100 TRYING           |----------------------->|
     |                        |                        |
     |              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" 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 [5] describes the 183 SESSION PROGRESS result
   code.

   After the media server completes the streaming of the prompt, it
   MUST send a 486 BUSY HERE to the Proxy.



O'Connor, et. al.          Expires 1/12/02                          4

                    Network Announcements with SIP           July 2001


   Note: We chose 486 as it indicates that the user is not reachable at
   this address.  However, the situation may or may not be permanent,
   and the prompt may be part of a forking proxy request.

   The proxy sends the appropriate error response to the caller.  That
   could be 486, 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)            |
     |<================================================|
     |                        |    486 BUSY HERE       |
     |   486 BUSY HERE        |<-----------------------|
     |<-----------------------|                        |
     |   ACK                  |    ACK                 |
     |----------------------->|----------------------->|
     |                        |                        |


. Formal Syntax

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in RFC-2234 [6].

   ANNC-URL        = "sip:" annc-ind "@" hostport
                       annc-parameters

   annc-ind        = "annc" [ ":" password ]

   annc-parameters = ";" play-param [ ";" early-param ]

   play-param      = "play=" prompt-url

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


   The definition of hostport and password are as specified by [2].

   The syntax of prompt-url is as specified by [7].  We expect the URL
   to be one of the following schemes.


O'Connor, et. al.          Expires 1/12/02                          5

                    Network Announcements with SIP           July 2001


     o http
     o ftp
     o file
     o nfs (RFC 2224)
     o IMAP (RFC 2192, only Section 7, "Specific message or message
        part")


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


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

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

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

   5  Handley, M., Schulzrinne, H., Schooler, E., Rosenberg, J., "SIP:
      Session Initiation Protocol", draft-ietf-sip-rfc2543bis-03.txt,
      May 2001, work in progress.
   6  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
      Specifications: ABNF", RFC 2234, November 1997.

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




. Acknowledgments








O'Connor, et. al.          Expires 1/12/02                          6

                    Network Announcements with SIP           July 2001


. 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
   SnowShore Networks, Inc.
   285 Billerica Rd.
   Chelmsford, MA  01824-4120
   USA

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


   J. 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 1/12/02                          7

                    Network Announcements with SIP           July 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 1/12/02                          8