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. 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 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 1/12/2002 1 Network Announcements with SIP July 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 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 4. 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 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 "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 | |----------------------->|----------------------->| | | | 6. 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") 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. 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. 9. Acknowledgments O'Connor, et. al. Expires 1/12/02 6 Network Announcements with SIP July 2001 10. 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