Internet DRAFT - draft-darshan-bau
draft-darshan-bau
draft-darshan-bau December 2005
SIPPING Working Group
Internet Draft Darshan Bildikar
Document: draft-darshan-bau-00.txt Huawei Technologies
India Pvt Ltd.
Bangalore
India
Expires: July 2006 January 2006
SIP Interface for Media Servers with BAU
draft-darshan-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 - June 2006 [Page 1]
draft-darshan-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 - June 2006 [Page 2]
draft-darshan-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 - June 2006 [Page 3]
draft-darshan-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 - June 2006 [Page 4]
draft-darshan-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 - June 2006 [Page 5]
draft-darshan-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 - June 2006 [Page 6]
draft-darshan-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 - June 2006 [Page 7]
draft-darshan-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: <sip:user@client.huawei.com>;tag=8000
To: <sip:dialog@mrs.huawei.com;annc.BAU.pa;an=welcome.wav;it=3;iv=4>
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 - June 2006 [Page 8]
draft-darshan-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: <sip:user@client.huawei.com>;tag=8000
To: <sip:dialog@mrs.huawei.com;annc.BAU.pa;an=welcome.wav;it=3;iv=4>;tag=1a1e0a19
CSeq: 1 INVITE
Call-ID: 12345678@client.huawei.com
Via: SIP/2.0/UDP client.huawei.com
Contact:<sip:dialog@mrs.huawei.com;transport=udp>
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: <sip:user@client.huawei.com>;tag=8000
To: <sip:dialog@mrs.huawei.com;annc.BAU.pa;an=welcome.wav;it=3;iv=4>;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 - June 2006 [Page 9]
draft-darshan-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: <sip:user@client.huawei.com>;tag=8001
To: <sip:dialog@mrs.huawei.com;annc.BAU.pa;an=welcome.wav;it=3;iv=4>
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 - June 2006 [Page 10]
draft-darshan-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: <sip:user@client.huawei.com>;tag=8001
To: <sip:dialog@mrs.huawei.com;annc.BAU.pa;an=welcome.wav;it=3;iv=4>
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 - June 2006 [Page 11]
draft-darshan-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 - June 2006 [Page 12]
draft-darshan-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 - June 2006 [Page 13]
draft-darshan-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 - June 2006 [Page 14]
