draft-darshan-sipping-bau December 2005 SIPPING Working Group Internet Draft Darshan Bildikar Document: draft-darshan-sipping-bau-00.txt Huawei Technologies India Pvt Ltd. Bangalore India Expires: July 2006 January 2006 SIP Interface for Media Servers with BAU draft-darshan-sipping-bau-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 June 30, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document defines a mechanism that helps SIP entities leverage the BAU packet cable specification to support simple IVR applications. It builds upon [1] to add BAU [2] support in addition to the VXML support that is already provided. Darshan Expires - July 2006 [Page 1] draft-darshan-sipping-bau December 2005 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 [i]. Table of Contents 1. Introduction...................................................2 2. Motivation for BAU SIP Interface...............................3 3. Terminology....................................................3 4. BAU Usage......................................................4 4.1 BAU Package Events.........................................4 4.2 BAU Package Variables......................................6 5. Formal Syntax..................................................7 6. SIP BAU Interface..............................................7 6.1 Session Setup..............................................8 6.2 Session Maintenance........................................9 6.3 Session Teardown..........................................11 6.4 Rejection.................................................11 7. Returning DTMF Digits.........................................11 8. IANA Considerations...........................................12 9. Security Considerations.......................................12 10. Author’s Addresses...........................................12 11. References...................................................12 11.1 Normative References.....................................13 11.2 Informative References...................................13 12. Intellectual Property Statement..............................13 13. Disclaimer of Validity.......................................14 14. Copyright Statement..........................................14 15. Acknowledgment...............................................14 1. Introduction The NCS Packet Cable specification [2] BAU or Basic Audio Server, offers standard way of performing typical media server functions like play, record, DTMF detection and reporting. Many commercial media servers already support the BAU package and this document attempts to standardize a SIP interface that utilizes the BAU specification implemented by media servers. The SIP interface described in this document derives from the mechanism defined in [1] and helps SIP servers (like Application servers) to utilize functionality such as audio variables, control of audio interruptibility, digit buffer control, special key sequences and re-prompting during data collection as defined in BAU specifications. Darshan Expires - July 2006 [Page 2] draft-darshan-sipping-bau December 2005 2. Motivation for BAU SIP Interface There is more than one standard method to invoke announcement services on Media servers; a major one being VXML [1]. VXML is designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF input, recording of spoken input, telephony and mixed initiative conversations etc. For applications that wish to use simple play announcement and play and collect operations, VXML could be too "heavy" a solution i.e. in terms of VXML fetch (VXML usually resides on a web server and also could be dynamically generated) and VXML parsing. BAU or Base Audio Server is an event package that is defined for MGCP / Megaco and is described in the Packet Cable Audio Server Specification. Though defined for MGCP it is targeted especially towards Media Servers. It provides the standard IVR operations of Play Announcement, Play Collect and Play Record. MGCP along with SIP is a commonly used media server control protocol. There are over 50 event packages that have been defined by the IETF/ITU for MGCP / Megaco to provide bearer control functionality. All these packages have been defined specifically for MGCP and not Media Servers. BAU, however, is especially relevant to Media Servers. Though defined specifically for MGCP, we feel it is sufficiently generic to extend to SIP. This reason for this extension would be the simplicity of the specification along with the performance gain it provides in that there is no VXML fetch and processing required thus optimizing network and CPU utilization. Note however that SIP-BAU is not intended as a replacement to VXML. It is intended for use in environments where the requirements for user interaction in IVR are relatively simple and straightforward. It is envisioned that Media Servers would provide both VXML and BAU SIP interfaces to Control Agents wishing to initiate bearer and media control. 3. Terminology Application Server: It hosts services It acts as a control agent for the Media Server i.e. it negotiates and sets up SIP sessions between UA’s and the media server. Media Server: A device that provides functions such as play, collect digits and record functions in IP networks. Play and Collect: The mechanism of playing recorded announcements to an end user and gathering user input in the form of dialed DTMF digits. VXML: VoiceXML is a W3C standard designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and DTMF Darshan Expires - July 2006 [Page 3] draft-darshan-sipping-bau December 2005 key input, recording of spoken input, telephony, and mixed initiative conversations. 4. BAU Usage 4.1 BAU Package Events The NCS specification defines certain parameters that can be used with the BAU package. Presented below are some of the parameters along with directions on mandatory parameters that need to be supported in order to achieve inter operability and some that are optional which must be ignored by the media server if not understood. There are three sub packages defined for the BAU package namely pa play announcement), pc (Play Announcement and Collect Digits) and pr (Play and Record). Presented in the table below is a list of all parameters that can be used with any of the above packages. BAU Parameters +--------+------------------------+----+----+----+ | Symbol | Definition | PA | PC | PR | +--------+------------------------+----+----+----+ | an | Announcement | o | f | f | | | | | | | | ap | Append | f | f | o | | | | | | | | cb | Clear Digit Buffer | f | o | o | | | | | | | | dm | Digit Map | f | f | o | | | | | | | | du | Duration | o | f | f | | | | | | | | fdt | First Digit Timer | f | o | f | | | | | | | | ip | Initial Prompt | f | o | o | | | | | | | | idt | Inter Digit Timer | f | f | o | | | | | | | | it | Iterations | o | f | f | | | | | | | | iv | Interval | o | f | f | | | | | | | Darshan Expires - July 2006 [Page 4] draft-darshan-sipping-bau December 2005 | na | Number of Attempts | f | o | o | | | | | | | | ni | Non Interruptible Play | f | o | o | | | | | | | | rid | Recording ID | f | f | m | | | | | | | | rlt | Recording Length | f | f | m | | | | | | | | rsk | Restart Key | f | o | o | | | | | | | | rtk | Return Key | f | o | o | +--------+------------------------+----+----+----+ 'o' - Optional, 'm' - Mandatory, 'f' - Forbidden Note: The parameters mentioned above are an optimal subset of the parameters in the BAU specification i.e. it is a minimal set of parameters that MUST be supported in order to achieve inter operability between different implementations. Other parameters defined in BAU CAN be supported but MUST be ignored by media servers that do not understand them. Announcement: The file name of the announcement to play. The assumption is that the file is loaded in the media server as is generally the case. Therefore this will typically be a local file URL but other URL schemes (for example HTTP) can also be used. Append: If set to true, the audio recording will append to any existing content in the Recording ID. Valid values are "true" or "false. Clear Digit Buffer: If set to true, it clears the digit buffer before playing the announcement. Valid values are "true" or "false. Digit Map: As specified in [4]. Valid digits are 0-9 and '#' and '*'. Duration: The maximum duration of time to play a specified announcement. Takes precedence over iteration and interval (interval specified in units of 100 milliseconds). First Digit Timer: The amount of time allowed for the user to enter the first digit and is specified in 100's of milliseconds. Default is 50 (5 seconds). Initial Prompt: The initial announcement prompting the user to enter DTMF digits or speak. Inter Digit Timer: The amount of time allowed for the user to enter a digit when no alternative within the digit map has been matched. The timer value is specified in 100's of milliseconds and the default value is 50 (5 seconds) Darshan Expires - July 2006 [Page 5] draft-darshan-sipping-bau December 2005 Interval: The interval of silence to be inserted between iterative plays. The interval of silence is specified in 100's of milliseconds and the default value is 10 (1 second). Iterations: The maximum number of times an announcement is to be played. -1 indicates that the announcement is to be repeated forever. The default value is 1. Number of attempts: The number of attempts the user is allowed to make until a valid digit pattern has been entered/ announcement has been recorded. Non Interruptible Play: If set to true, the user needs to hear the complete initial announcement before entering any digits / making a voice recording. Valid values are "true" or "false. Recording ID: It is the URI to be assigned to the physical segment which is to be recorded by the Play Record event. Recording Length: The maximum allowable length of the recording and is specified in 100's of milliseconds. -1 indicates no limit. Restart Key: Defines a digit map that discards all collected input / recording in progress and re-prompt the user with the original prompt. This key is also referred to as the cancel character. Return Key: Defines a digit map that returns the collected digits to the Application Server. This key is also referred to as the terminating character. 4.2 BAU Package Variables Certain variable data can be played with the BAU package like date, time, duration etc. The table below lists variable packages that MUST be supported +--------+--------+-------------------------------------------------+ | Symbol | Sub | Definition | | | Type | | +--------+--------+-------------------------------------------------+ | dat | mdy | Date in month-day-year format | | | | | | dat | dym | Date in day-year-month format | | | | | | dat | ymd | Date in year-month-day format | | | | | | dat | mdy | Date in month-day-year format | Darshan Expires - July 2006 [Page 6] draft-darshan-sipping-bau December 2005 | | | | | dig | - | Generic digits, can be used to announce phone | | | | numbers | | | | | | dur | - | Duration | | | | | | mny | - | Money. Uses ISO 4217 three letter codes | | | | | | tme | t12 | Time. In 12 hour format | | | | | | tme | t24 | Time. In 24 hour format | +--------+--------+-------------------------------------------------+ 5. Formal Syntax In order for the SIP entity to invoke the BAU package in the media server, SIP entity is required to carry following parameters in the SIP headers. The syntax of these parameters uses the augmented Backus-Naur Form (BNF) as described in [3]. DIALOG-URL = sip-ind dialog-ind "@" hostport dialog-parameters sip-ind = "sip:" / "sips:" dialog-ind = "dialog" dialog-parameters = ";" dialog-param [ bau-parameters ] dialog-param = "annc.BAU.pa" / "annc.BAU.pc" / "annc.BAU.pr / annc.cancel" bau-parameters = bau-param [ bau-parameters ] bau-param = ";" bau-keyword "=" bau-value bau-keyword = token bau-value = token 6. SIP BAU Interface A SIP entity can initiate a BAU session by issuing an INVITE or REFER request to the Media Server and can terminate the session with BYE. If the media server needs to return collected DTMF digits, it can do so by sending INFO or any other method as mentioned in section 7. This section provides details on creation, maintenance and teardown of a session with a BAU compliant Media Server. Darshan Expires - July 2006 [Page 7] draft-darshan-sipping-bau December 2005 6.1 Session Setup A SIP entity can initiate a BAU session by issuing an INVITE or REFER request to the Media Server. Typical session setup using the INVITE request is shown below. Sip Entity Media Server | | | INVITE (F1) | |----------------------->| | | | 200 OK (F2) | |<-----------------------| | | | ACK (F3) | |----------------------->| | | |........................| | RTP | |........................| | | | | For PA the INVITE message format would be as shown below. The INVITE indicates that pa package of BAU is to be used. The announcement to be played is welcome.wav (loaded locally in the media server) and the number of iterations is three with an interval of two seconds between each iterations. F1 --> INVITE to Media Server INVITE sip:dialog@mrs.huawei.com;annc.BAU.pa;an=file://welcome.wav;it=3;iv=2 Via: SIP/2.0/UDP client.huawei.com From: ;tag=8000 To: Contact: sip:user@client.huawei.com Call-ID: 12345678@client.huawei.com CSeq: 1 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=user 2890844526 2890844526 IN IP4 client.huawei.com s=Session SDP c=IN IP4 client.huawei.com Darshan Expires - July 2006 [Page 8] draft-darshan-sipping-bau December 2005 t=3034423619 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F2 --> 200 OK from Media Server SIP/2.0 200 OK From: ;tag=8000 To: ;tag=1a1e0a19 CSeq: 1 INVITE Call-ID: 12345678@client.huawei.com Via: SIP/2.0/UDP client.huawei.com Contact: Content-Length: ... Content-Type: application/sdp v=0 o=mrs 2890844527 2890844527 IN IP4 mrs.huawei.com s=Session SDP c=IN IP4 mrs.huawei.com t=3034423619 0 m=audio 3456 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F3 --> ACK to Media Server ACK sip:dialog@mrs.huawei.com;annc.BAU.pa;an=file://welcome.wav;it=3;iv=2 SIP/2.0 From: ;tag=8000 To: ;tag=1a1e0a19 Call-ID: 12345678@client.huawei.com CSeq: 1 ACK Via: SIP/2.0/UDP client.huawei.com Content-Length: 0 6.2 Session Maintenance An IVR session generally involves playing announcements to the user and gathering user input in the form of DTMF digits. Further course of action is determined based on user input. As a result of this is necessary to place multiple Play and Collect requests inside the same dialog. The SIP INFO method [5] MUST be used to issue subsequent PA/PC/PR requests after the initial setup using INVITE or REFER [6]. A SIP entity can initiate an BAU session by issuing an INVITE or REFER request to the Media Server. Typical session setup using the INVITE request is shown below. Darshan Expires - July 2006 [Page 9] draft-darshan-sipping-bau December 2005 Sip Entity Media Server | | | INVITE (F1) | |----------------------->| | | | 200 OK (F2) | |<-----------------------| | | | ACK (F3) | |----------------------->| | | |........................| | RTP | |........................| | | |........................| | Report Digits | |........................| | | |INFO (F4 - next request)| |----------------------->| | | | 200 OK | |<-----------------------| | | | | The message flow indicates two announcements requests being issued to the media server. The first one (INVITE in this case) creates a SIP dialog and the second INFO issues one more request within the dialog created by the INVITE. For the sake of illustration let us assume that both the requests issued are for Play and Collect Operations F1 --> INVITE to Media Server INVITE sip:dialog@mrs.huawei.com;annc.BAU.pc; \ ip=file://selectLanguage.wav;dm=1|2|3;rsk=*;rtk=# Via: SIP/2.0/UDP client.huawei.com From: ;tag=8001 To: Contact: sip:user@client.huawei.com Call-ID: 12345679@client.huawei.com CSeq: 1 INVITE Content-Type: application/sdp Content-Length: ... v=0 o=user 2890844526 2890844526 IN IP4 client.huawei.com Darshan Expires - July 2006 [Page 10] draft-darshan-sipping-bau December 2005 s=Session SDP c=IN IP4 client.huawei.com t=3034423619 0 m=audio 49170 RTP/AVP 0 a=rtpmap:0 PCMU/8000 F4 --> INFO to Media Server INFO sip:dialog@mrs.huawei.com;annc.BAU.pc; \ ip=file://enterCardNumber.wav;dm=0xxxxxxx|7xxxxxxx;rsk=*;rtk=# Via: SIP/2.0/UDP client.huawei.com From: ;tag=8001 To: CSeq: 2 INFO Call-ID: 12345679@client.huawei.com F2 and F3 messages are identical to those shown in section 5.1. 6.3 Session Teardown The dialog can be terminated by either the media server or the requesting SIP entity by issuing a SIP BYE request. It is recommended that it is always the requesting entity that controls the setup and teardown of the dialog 6.4 Rejection As defined in [1] if the announcement to be played is not found then the request is rejected with a 404 NOT FOUND response code. An appropriate reason phrase will accompany this error code. If the media server cannot perform the requested operation then it must respond with a 488 NOT ACCEPTABLE HERE response code. If there is a keyword without a corresponding value or the request URI format is invalid in some way, the request must be rejected with a 400 BAD REQUEST response code. 7. Returning DTMF Digits This document places no restriction on the mechanism adopted to return DTMF digits to the requesting entity. Some methods that can be used to carry DTMF digits are:- Darshan Expires - July 2006 [Page 11] draft-darshan-sipping-bau December 2005 Carrying DTMF in media: This has the disadvantage of not working with compressed media Special Encoding in RTP ([RFC 2833]): Can be sent separate from media but requires a special [RFC 2833] compliant encoder/decoder at each UA. Encode data using INFO method: Sent along call signaling path but still requires the use of an [RFC 2833] encoder/decoder. DTMF data using INFO with digits encoded as text: There are no out of order issues in this case and is recommended that this is the method that CAN be used to carry DTMF digits. It is not yet a standard but we expect some such method to be standardized soon. 8. IANA Considerations This document defines the following parameters Parameter Name Default Values Reference -------------- ----------------- --------- annc.BAU.pa - This document annc.BAU.pc - This document annc.BAU.pr - This document annc.cancel - This document 9. Security Considerations Standard SIP authorization mechanisms can be used by the media server to validate requests by clients. The mechanism defined in this document does not lead to any new security issues that need to be addressed. 10. Author’s Addresses Darshan Bildikar Huawei Technologies India Pvt. Ltd. Level IV, No.23, Leela Galleria, Airport Road, Bangalore - 560 008 Phone: +91-80-4178 1770 Email: darshanb@huawei.com 11. References Darshan Expires - July 2006 [Page 12] draft-darshan-sipping-bau December 2005 11.1 Normative References [1] Burger, Van Dyke, Spitzer "Basic Network Media Services with SIP", RFC 4240, December 2005. [2] Cable Television Labs Inc. "Packet Cable 1.5 Specifications",June 2001. [3] Crocker, Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [4] Andreasen, Foster, "Augmented Media Gateway Control Protocol (MGCP)", RFC 3435, January 2003. 11.2 Informative References [1] Donovan, "Augmented The SIP INFO Method", RFC 2976, October 2000. [2] Sparks, "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003. [3] Rosenberg et al, "The Session Initiation Protocol", RFC 3261, June 2002. [4] Schulzrinne, Petrack "The Session Initiation Protocol", RFC 3261, June 2002. 12. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights Darshan Expires - July 2006 [Page 13] draft-darshan-sipping-bau December 2005 that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 13. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 14. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. 15. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Darshan Expires - July 2006 [Page 14]