view Side-By-Side changes
Network Working Group W. O'Connor Internet Draft E. Burger Document:draft-burger-sipping-netann-00.txtdraft-burger-sipping-netann-01.txt J. Van Dyke Category: Standards Track SnowShore Networks, Inc.Expires JanuaryExpires: May 2002July 12,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. Expires1/12/20025/21/2002 1 Network Announcements with SIPJulyNovember 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 thenetwork plays the prompt before or afterannouncement server answersupervision.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 a486 BUSY HERE487 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 aplay="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. Expires1/12/025/21/02 2 Network Announcements with SIPJulyNovember 2001 4.SimpleAnnouncement 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. Thetwoservice has several associated URI parameters"play="that control the content and"early=" specifydelivery of the announcement. These parameters are described below: "play=" specifies the audio resource or announcement sequence toplay andbe 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 forsimpleannouncements 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;play="http://audio.carrier.net/allcircuitsbusy.g711"; \ early=yes sip:annc@ms2.carrier.net; \play=file://fileserver.carrier.net/geminii/yourHoroscope.wavplay="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, theearly="early=" parameter determines whether the media server plays the prompt after call setup or as early media. The default value for theearly="early=" parameter MUST BE"no"."yes". That is, the default action is for the media server to play the promptafterbefore 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 containeitherthe parameter "early=no"or leave out the early= parameterto invoke the Established Call Prompting service. The media server responds with 200 OK. The proxy sends a 200 OK to theO'Connor, et. al. Expires 1/12/02 3 Network Announcements with SIP July 2001caller. 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 |<-----------------------| |<-----------------------|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" 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[5][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 HEREtoas theProxy.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. Expires1/12/02 45/21/02 5 Network Announcements with SIPJulyNovember 2001Note: 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 be486,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) | |<================================================| | |486 BUSY HERE487 REQUEST TERMINATED | |486 BUSY HERE487 REQUEST TERMINATED |<-----------------------| |<-----------------------| | | ACK | ACK | |----------------------->|----------------------->| | | | 6. Formal Syntax The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234[6].[8]. ANNC-URL = "sip:" annc-ind "@" hostport annc-parameters annc-ind = "annc"[ ":" password ]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 hostportand password areis as specified by [2]. The syntax of prompt-urlisconsists of a URL scheme as specified by[7].[9] or a special token indicating a provisioned announcement sequence. 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 2001o http o ftp o fileo(referencing a local or nfs (RFC 2224)o IMAP (RFC 2192, only Section 7, "Specific messagelocation) 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 ormessage part")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-00.txt, Julydraft-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-03.txt, Maydraft-ietf-sip-rfc2543bis-05.txt, October 2001, work in progress.68 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.79 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 2001Changes 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.comJ.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. Expires1/12/02 75/21/02 9 Network Announcements with SIPJulyNovember 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. Expires1/12/02 85/21/02 10 ----