Internet Engineering Task Force SIP WG
Internet Draft Rosenberg,Mataga,Ladd
draft-rosenberg-sip-vxml-00.txt dynamicsoft
July 13, 2001
Expires: February 2001
A SIP Interface to VoiceXML Dialog Servers
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Abstract
VoiceXML is an XML based scripting language for describing voice
dialogs. VoiceXML interpreters run within an interpreter context
that, among other tasks, provides a call control interface for
accessing the interpreter. It is very natural to provide a VoIP-based
interpreter context that uses SIP and RTP to communicate with the
outside world. In this document, we provide detailed specifications
for a SIP/RTP based interpreter context.
1 Introduction
VoiceXML [1] is an XML based scripting language for describing voice
dialogs. It supports user input through speech recognition and DTMF,
and can communicate with the user through text-to-speech or recorded
files. VoiceXML scripts are interpreted by a VoiceXML interpreter.
Rosenberg,Mataga,Ladd [Page 1]
Internet Draft sip-vxml July 13, 2001
This interpreter, in turn, runs within an interpreter context. The
interpreter context is the interface between the outside world and
the interpreter. It typically handles the mechanisms by which the
script execution begins, and by which it is fed media to drive it. It
also provides the means for fetching documents from some form of
document server.
It is very natural to provide a VoiceXML interpeter context based
purely on IP. Specifically, based on VoIP using SIP [2] and RTP [3],
along with HTTP for document access. An incoming VoIP call triggers
the execution of the script, fetched from a server using HTTP. The
incoming RTP stream for the call is passed to the interpeter for
processing, and speech generated by the interpreter is sent over RTP
to the called party. We call a pure IP-based VoiceXML system an "IP
dialog server", or just "dialog server".
Dialog servers are a key part of the application story for SIP-based
networks, as described in the SIP application component architecture
[4]. That document describes SIP-based dialog servers, and provides a
high level overview of how the SIP interface works. This document
provides a stand-alone, self-contained, more thorough description of
a SIP-based VoIP VoiceXML interpreter context.
2 Script Initiation
The script execution begins when a session is established using an
INVITE request.
2.1 Script Naming
In SIP, the request-URI identifies the user or service that the call
is destined for. In the case of a dialog server, the dialog itself is
the target for the call. As such, the request URI should contain the
identifier for this dialog. This is consistent with the Request-URI
service invocation model of RFC 3087 [5]. This URL can be in one of
two formats. In the first, the VoiceXML script is identified directly
by an HTTP URL. In the second, the script is not specified. Rather,
the dialog server uses its configuration to map the incoming request
to a specific script. The format for the Request-URI in either case
is:
Request-URI = "sip:" service-ID "." dialog-type ["." dialog-specific]
"@" hostport url-parameters [headers]
service-ID = "dialog" | extension-token
dialog-type = "vxml" | service-token
dialog-specific = vxml-specific | service-token
Rosenberg,Mataga,Ladd [Page 2]
Internet Draft sip-vxml July 13, 2001
service-token = 1*(alphanum | "-" | "!" | "%" | "*"
| "_" | "+" | "`" | "'" | "~{}" )
vxml-specific = user-unreserved | unreserved | escaped
Since the request URI can indicate a request for a variety of
different services, of which a dialog server is only one type, the
request URI first begins with a service identifier, that indicates
the basic service required. This document specifies that dialog
servers are addressed by having the first part of the username in the
request-URI contain the service identifier "dialog" to indicate that
a dialog service is requested. This is followed by a period, and
after that, an identifier that indicates the means by which the
dialog is specified. Currently, one mechanism is defined - a VoiceXML
script. Other tokens can be used to indicate different mechanisms
(note that service-token is identical to the BNF for token from RFC
2543, except that the "." character is disallowed). After that comes
an optional period followed by dialog-mechanism specific
identification. For VoiceXML scripts, when present, this
identification information is always a URL-encoded version of the URL
which references the script to execute. When not present, the dialog
server uses server-specific configuration to determine which script
to execute.
Examples of URLs that invoke VoiceXML dialogs are:
sip:dialog.vxml.http%3a//dialogs.server.com/script32.vxml@vxmlservers.com
sip:dialog.vxml@vxmlservers.com
The first of these indicates that the dialog server (located at
vxmlservers.com) should invoke a VoiceXML script fetched from
http://dialogs.server.com/script32.vxml. Since the user part of the
SIP URL cannot contain the : character, this must be escaped to %3a.
2.2 Responding to the INVITE
If the server receiving the INVITE doesn't support the specifics of
the service request (for example, the requested VoiceXML version is
not supported), the server SHOULD generate a 501 response. It MAY
include a Warning header providing details on why the request could
not be serviced.
The server SHOULD authenticate the caller and verify that they are
authorized to access the requested service. It is anticipated that
Rosenberg,Mataga,Ladd [Page 3]
Internet Draft sip-vxml July 13, 2001
dialog servers will generally be used in conjunction with an
application server which makes the actual authorization decision
about whether the call is to be processed. As a result, the dialog
server's authorization decision is simple - if it came from an
authorized upstream server, the request is allowed. It is RECOMMENDED
that a persistent TLS connection between the application server and
the dialog server be used to provide the authentication credentials
for this kind of scenario.
The server then validates that the SDP in the INVITE, if present, is
acceptable. It does so based on the procedures of Section 2.3.
If it has gotten this far, the server SHOULD fetch the script
identified by the request-URI before generating a final response to
the request. If the script cannot be fetched, or is invalid, the
server generates a 502 Bad Gateway response, since effectively the
server is a gateway to HTTP. It MAY include a Warning header
providing details on the reason for failure.
Once the script has been fetched, and is valid, and the offered SDP
is deemed acceptable, the server SHOULD generate a 200 OK response.
The generation of the response, and ACK processing, are based on
standard SIP semantics.
2.3 SDP Processing
If the INVITE contains SDP with an offer, the dialog server will
generate an answer as per SIP-bis [6]. The offer is deemed
unacceptable if it contains no media lines of type audio, or if the
dialog server supports none of the codecs listed for the audio
streams. Otherwise, it is deemed acceptable.
The answer generated by the dialog server SHOULD refuse all media
streams excepting the first offered audio stream. Choice of codecs
used by the dialog server is at the discretion of the implementor.
However, it is STRONGLY RECOMMENDED that all dialog servers support
G.711 and RFC 2833. If an offered media stream does not indicate
support for RFC 2833 tones, the dialog server SHOULD add that codec
to the answer. As described in RFC2543-bis, this allows the dialog
server to inform the caller that it can receive rfc2833 media, even
if the caller cannot receive it.
The server SHOULD allow sendonly, recvonly, and sendrecv media
streams, as well as streams on hold. The meaning of these for script
interpretation is discussed in Section 4.
If the INVITE from the caller did not contain an SDP, the dialog
server SHOULD generate an offer in the 2xx with a single audio media
Rosenberg,Mataga,Ladd [Page 4]
Internet Draft sip-vxml July 13, 2001
line, listing all codecs supported by the dialog server.
2.4 Script Variables
In VoiceXML 1.0, the interpreter context provides the script with
several variables that provide information on the call control
interfaces. These variables are set in the following fashion:
session.telephone.ani: This variable is the value of the URL in
the From field of the INVITE that triggered the script.
session.telephone.dnis: This variable is the value of the URL in
the To field of the INVITE that triggered the script.
session.telephone.iidigits: If the Contact header in the INVITE
request uses the SIP caller preferences contact parameters
[7] to provide additional information on the initiating
device, the interpreter context SHOULD map these parameters
to closest II digit if possible.
session.telephone.uui: This variable is set only if the INVITE
request contained an embedded ISUP IAM request [8]. In that
case, the user-to-user information elements from that IAM
are extracted, and mapped to this variable. Support for
this is optional, but RECOMMENDED.
3 Document Acquisition
The interpreter context fetches the script using normal HTTP GET and
POST requests [9]. It MUST follow the caching behaviors specified in
VoiceXML 1.0. It MAY support other document acquisition protocols,
such as FTP.
4 Audio Input and Output
Audio input and output are provided through RTP. The implementation
platform SHOULD provide DTMF recognition on the incoming media
stream, indpendent of its codec type. This is greatly facilitated
through RFC 2833, which pushes the DTMF detection operation to the
originator. The implementation platform SHOULD provide speech
recognition on the incoming media stream as well.
To be very explicit, this means that the dialog server SHOULD support
recognition of DTMF and speech by processing a single incoming media
stream. Furthermore, this stream can be sent by the caller using one
of at least two codecs - G.711 and RFC 2833, and that the sender of
the media can switch codecs on the fly when it detects DTMF. This
means that RTP packets 1, 2 and 3 might be G.711, followed by RTP
Rosenberg,Mataga,Ladd [Page 5]
Internet Draft sip-vxml July 13, 2001
packet 4 which is RFC 2833. Furthermore, despite the fact that the
sender can send RFC2833, the dialog server SHOULD still perform DTMF
detection on the media stream, in case the sender does not support
RFC 2833, or does support it, but misses a digit.
OPEN ISSUE: This is a strong statement; if the probability
of missed DTMF is small, the dialog server shouldn't have
to do detection if it knows the caller has done it.
Problem, though: since SDP has no way to indicate code-
specific directionalities in a sendrecv stream, a UA that
can only send RFC 2833 doesn't say anything about it in the
SDP in the INVITE. As a result, there is no way to know for
sure that the sender can do it until the first RFC 2833
packet shows up. The SDP FID [10] specification resolves
this. Should we make support for the FID spec mandatory for
dialog servers?
Some implementations we are aware of use a separate stream for the
DTMF and for the speech. This approach is NOT RECOMMENDED, since it
makes synchronization of the speech and DTMF difficult.
SDP allows media streams to be unidirectional. If a stream is one-way
from the caller to the dialog server, this means that script
processing SHOULD proceed normally, except that any audio which would
normally be output by the implementation platform is discarded.
Furthermore, if a stream is one-way from the dialog server to the
caller, script processing SHOULD proceed normally, except that the
implementation platform never delivers characters (i.e., DTMF digits)
or utterances to the interpreter. In other words, behavior is
identical to the case where the caller is simply not talking.
Unidirectional streams are very useful for applications which require
a "listener" on an existing media stream to look for a particular
utterance and DTMF digit, and deliver that to an application server
for event processing. Therefore, it is RECOMMENDED that they be
supported in dialog servers as described above.
SIP allows media streams to be placed on hold. This will happen when
the interpreter context receives a re-INVITE with an SDP with a
0.0.0.0 connection line. This is handled identically to the case of a
media stream which is unidirectional from the dialog server to the
caller, meaning that it's "just" disconnected, not an interpreter-
freeze.
SIP allows media streams to be disabled by setting the port to zero.
This has very specific meaning in the case of a dialog server. It has
the effect of requesting a freeze of the interpreter state. When the
Rosenberg,Mataga,Ladd [Page 6]
Internet Draft sip-vxml July 13, 2001
interpreter context returns a 200 OK as a response, it indicates that
the interpreter has been frozen. The interpreter is truly frozen; the
behavior should be as if time were literally suspended as far as the
interpreter is concerned. To unfreeze the interpreter state, a re-
INVITE is needed to establish a new audio media stream. This will
cause processing of the script to continue at exactly the same place
it left off, using the media input and output from the new media
stream to drive the interpreter. It is critical that, as far as the
script is concerned, the freeze never even took place.
This capability is essential for supporting feature composition of
voice-based applications. Consider application A, which allows the
user to hear an announcement when a friend comes online. If the user
says yes, a call is placed to that friend. Another application, B,
allows the user to hear stock quotes. We'd like to compose these so
that both can happen simultaneously. For that to happen in a
reasonable fashion, one of these applications has the "focus",
meaning that it is the one processing the input and output from the
user. Consider the case where the stock quote application has the
focus. An the stock quote application runs on dialog server X, and
the presence application on dialog server Y. Application server Z is
the central point for all system events related to all applications.
The flow to consider is show in Figure 1. At the beginning of the
flow, the caller has a call leg to the AS, the the AS has used third
party call control [11] to connect the caller to dialog server X.
This means there is an RTP connection between the caller and this
dialog server, as shown.
An external event (such as a friend coming online), will cause an
application server to decide that the other voice application needs
to receive the focus. However, we don't want to terminate the stock
quote application; we merely wish to suspend it so that the user can
resume it after hearing that the friend came online. So, the
application server sends a re-INVITE (1) to the dialog server running
the stock quote application, and requests it to be frozen. When the
interpreter comples the current prompt block, the context freezes the
interpreter and returns a 200 OK. The AS then connects the user to
the dialog server running the presence application (4-9). Dialog
server Y will fetch the VoiceXML script from the AS (since the AS
knows the identity of the buddy that came online, it needs to be the
one that generates the VoiceXML script), but this is not shown. This
dialog runs, and assuming the user doesn't call the friend, the
script terminates, causing server Y to send a BYE (10). The AS
decides to resume the stock quote application. So, using 3pcc, it
reconnects the caller with server X (12-17). The re-INVITE to server
X (14) has the effect of unfreezing the context, so processing
continues where the call left off.
Rosenberg,Mataga,Ladd [Page 7]
Internet Draft sip-vxml July 13, 2001
The result of this is that the user's experience is the following:
network: Please enter the stock to check.
user: Lucent
network: Lucent technologies is at six dollars.
network: Friend alert: Bob is online. Would you like to call him?
user: no
network: Please enter the name of the stock to check.
Note that The issue of when the interpreter can be suspended is being
worked in the W3C.
The key idea with this mechanism is that in NO CASE should the
VoiceXML script for the stock quote application need to know that
this external event (the buddy coming online) has occurred, so that
it can play the buddy announcement. Doing so is counter to the entire
concept of feature interaction; it is an intractable problem if every
application and feature needs to know about each other. In the
approach proposed here, each voice application remains independent.
The application server plays the role of composing them by activating
and deactivating the contexts as needed. This still requires the AS
to know the set of applications that are running, but in this case,
it doesn't need to know anything except the relative precedences of
the various applications and the events which trigger them. Logic for
that can, in principle, be constructed in a generic way, independent
of the specific applications.
This approach isn't perfect for all cases, but its simple enough to
get things started.
4.1 Processing Further SIP Messages
The interpreter context processes subsequent SIP messages in the
following fashion.
If a BYE request is received from the caller, this terminates the
call. The interpreter context SHOULD throw the telephone.disconnect
event to the interpreter.
4.3 re-INVITE
If a re-INVITE is received, it has the effect of changing some aspect
of the media input and output. Codec changes, port changes, and IP
Rosenberg,Mataga,Ladd [Page 8]
Internet Draft sip-vxml July 13, 2001
Caller AS (Z) DS (X) DS (Y)
|RTP | | |
|...................................| |
| |friend online | |
| |<-------- | |
| |(1) INV disable | |
| |---------------->|request freeze |
| |(2) 200 OK | |
| |<----------------|frozen |
| |(3) ACK | |
| |---------------->| |
| |(4) INV no SDP | |
| |---------------------------------->|
| |(5) 200 SDP 1 | |
|(6) INV SDP 1 |<----------------------------------|
|<----------------| | |
|(7) 200 SDP 2 | | |
|---------------->|(8) ACK SDP 2 | |
|(9) ACK |---------------------------------->|
|<----------------| | |
| | | |
| RTP | | |
|.....................................................|
| | | |
| |(10) BYE | |
| |<----------------------------------|
| |(11) 200 OK | |
| |---------------------------------->|
|(12) INV no SDP | | |
|<----------------| | |
|(13) 200 SDP 3 | | |
|---------------->|(14) INV SDP 3 | |
| |---------------->|unfreeze |
| |(15) 200 SDP 4 | |
|(16) ACK SDP 4 |<----------------| |
|<----------------|(17) ACK | |
| |---------------->| |
|RTP | | |
|.................|.................| |
| | | |
| | | |
Figure 1: Voice Application Composition
Rosenberg,Mataga,Ladd [Page 9]
Internet Draft sip-vxml July 13, 2001
address changes are handled normally as per bis [6]. Specific
processing is required for changes in stream direction, placing the
call on hold, disabling a media stream, and adding a new audio stream
after a previous re-INVITE disabled it. See Section 4.
4.4 INFO, MESSAGE
These messages are ignored by the interpreter context.
5 Tag Processing
Certain tags within the VoiceXML script have call control
implications. The following subsections describe how the interpreter
context handles them.
VoiceXML 1.0 says that the processing of the exit tag is entirely
context specific.
For SIP, the interpreter context SHOULD send a BYE to terminate the
call.
Ideally, the VoiceXML <exit> element would also post the given
namelist to a URI specified in the original call setup. For example,
the URI of an HTTP servlet running directly in the AS or in an
associated web application server would be an appropriate choice.
This would allow voice interactions to be completely independent of
the calling context, and therefore be re-usable across providers and
applications. The VoiceXML specification is silent on exactly what
should happen with the <exit> namelist. For this reason, we do not
specify specific processing at this time.
OPEN ISSUE: Should we specify something? We could provide
an additional URL at script initiation which is used to
post the namelist upon exit.
5.2 Disconnect
The interpreter context SHOULD send a BYE to terminate the call. As
per the VoiceXML specification, a telephone.disconnected.hangup event
is also thrown.
5.3 Transfer
VoiceXML 1.0 supports two styles of transfer, bridged and blind.
Rosenberg,Mataga,Ladd [Page 10]
Internet Draft sip-vxml July 13, 2001
When the interpreter context needs to perform a blind transfer, it
SHOULD generate a REFER [12] request. The REFER request is sent to
the caller. It contains a Refer-To header which contains the target
URL specified in the URI in the value of the "dest" attribute of the
transfer tag. If the transfer tag contains a connecttimeout
attribute, the URI in the Refer-To has an Expires header parameter
appended to it, containing the duration from the attribute.
For example, if the following transfer tag was encountered:
<transfer name="mycall" dest="sip:support@foo.com" bridge="false"
connecttimeout="10s">
The REFER would look like:
REFER sip:caller@pc13.company.com
Via: SIP/2.0/UDP server3.vxmlservers.com
From: sip:dialog.vxml20@vxmlservers.com;tag=8aa6s
CSeq: 3487 REFER
Call-ID: 9a8s9809s@102.3.4.4
To: sip:caller@company.com;tag=99as7
Refer-To: sip:support@foo.com?Expires=10
Referred-By: sip:dialog.vxml20@vxmlservers.com
If the REFER is rejected, the interpreter context outputs a
network_busy as the outcome of the transfer attempt. Otherwise, the
interpreter context remains suspended until a NOTIFY is received.
At some point before the expiration, the interpreter context will
receive a NOTIFY request containing the final response received for
the triggered INVITE. If this response is a 2xx, the interpreter
context throws a telephone.disconnect.transfer, and sends a BYE
request to terminate the call.
If the final response was a non-2xx response, the transfer attempt
failed. If the final response was a 486, the outcome of the transfer
attempt is set to busy, and form processing continues. If the final
response was a 408, the outcome of the transfer attempt is set to
noanswer, and form processing continues. For any other response, the
outcome of the transfer attempt is set to network_busy, and form
Rosenberg,Mataga,Ladd [Page 11]
Internet Draft sip-vxml July 13, 2001
processing continues.
In a bridged transfer, the interpreter context resumes after the
transfer call completes. VoiceXML 1.0 also allows the script to
specify a grammar within the transfer tag, allowing it to listen in
for DTMF that meets that grammar. When a match is found, the transfer
is terminated and control returns to the interpreter.
This function requires that the dialog server act as a UAC, and make
the outbound call to the transferred party. The flow is shown in
Figure 2. The caller connects to the dialog server with messages 1-3.
RTP flows between the caller and the dialog server. When the transfer
tag is encountered, the dialog server sends an outbound INVITE (4)
The outbound INVITE contains the same SDP, SDP 1, offered by the
caller. If the final response (5) is a 200 OK, this contains SDP3.
The dialog server continues to receive media from the caller. This is
passed on to the transfer target, using SDP3. However, media from the
transfer target to the caller goes direct, bypassing the dialog
server.
If the final response to the INVITE was a non-2xx response, the
transfer attempt failed. If the final response was a 486, the outcome
of the transfer attempt is set to busy, and form processing
continues. If the final response was a 408, the outcome of the
transfer attempt is set to noanswer, and form processing continues.
For any other response, the outcome of the transfer attempt is set to
network_busy, and form processing continues.
The INVITE should not be left pending for more than the amount of
time in the connecttimeout parameter, if specified. After that amount
of time has passed, the INVITE request is cancelled, and form
processing continues. The outcome of the transfer is set to noanswer.
If the final response to the INVITE was a 2xx response, the transfer
attempt succeeded. In addition to passing on the media to the
transfer target, the interpreter passes the media received from the
caller through the grammar present within the transfer tag, if
present. If the grammar is matched, the interpreter context sends a
BYE to the transfer target. Processing continues within the
interpreter.
If the transfer target sends a BYE, a 200 OK is returned. The outcome
of the script is set to far_end_disconnect. Form interpretation
continues. If the caller sends a BYE, a 200 OK is returned. The
dialog server sends a BYE to the transfer target. A
Rosenberg,Mataga,Ladd [Page 12]
Internet Draft sip-vxml July 13, 2001
|(1) INVITE SDP1 | |
|-------------------->| |
|(2) 200 SDP2 | |
|<--------------------| |
|(3) ACK | |
|-------------------->| |
|RTP | |
|<...................>| |
| |(4) INVITE SDP1 |
| |------------------->|
| |(5) 200 SDP3 |
| |<-------------------|
| |(6) ACK |
| |------------------->|
| RTP from caller | |
|....................>| RTP from caller |
| |...................>|
| RTP to caller |
|<.........................................|
| | |
| | |
Caller DS Transfer
target
Figure 2: Bridged Transfer flow
telephone.disconnect.hangup event is thrown, and form processing
continues to allow cleanup.
OPEN ISSUE: When would it even be possible for the transfer
Rosenberg,Mataga,Ladd [Page 13]
Internet Draft sip-vxml July 13, 2001
outcome to be near_end_disconnect? Wouldn't this terminate
the script, so that there is no transfer outcome?
If the transfer target sends a REFER (ie., the caller is to be
transferred elsewhere), the interpreter context responds with a 200
OK. It creates a new REFER with the same Refer-To header (but its own
value for Referred-By), and sends it to the caller. Upon receiving a
200 OK to the REFER, the dialog server sends a NOTIFY to the transfer
target, informing it of a successful REFER completion to the new
target. If a BYE is received from the transfer target, the
interpreter sends a BYE to the caller as well, and throws a
telephone.disconnect.transfer event.
6 Additional Requirements
In addition to the above behaviors, we also recommend that several
optional SIP capabilities be implemented by dialog servers. This is
to support their intended use cases as components in the application
server component architecture [4]. The following list of requirements
includes these recommended features, in addition to summarizing the
ones scattered above:
1. The dialog server SHOULD support SIP over persistent TCP
and TLS connections, and SHOULD support a configurable
authorization listing of allowed Distinguished Names which
can connect. This is useful when authorization decisions
are outsourced to an application server, as described
above.
2. The dialog server SHOULD fully support RFC 1889 and RFC
1890. Of particular importance is RTCP.
3. The dialog server SHOULD support G.711 and RFC 2833.
4. The dialog server SHOULD support the UA requirements
outlined in the third party call control specification
[11]. This is important for building more complex
applications, a common usage for dialog servers.
5. The dialog server SHOULD support the SDP FID attribute
[10], and SHOULD use it to allow processing to occur over a
collection of alternate streams with the same FID group.
6. The dialog server SHOULD support the REFER method [12],
needed for the blind transfer tag. It SHOULD also allow
itself to be referrred as a normal UAS.
7. The dialog server SHOULD allow any HTTP URL to be placed in
Rosenberg,Mataga,Ladd [Page 14]
Internet Draft sip-vxml July 13, 2001
the request-URI for specifying the script to execute.
7 Authors Addresses
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: jdrosen@dynamicsoft.com
Peter Mataga
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: pmataga@dynamicsoft.com
David Ladd
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
email: dladd@dynamicsoft.com
8 Bibliography
[1] VoiceXML Forum, "Voice extensible markup language (VoiceXML)
version 1.00," VoiceXML forum specification, VoiceXML Forum, Mar.
2000.
[2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments 2543, Internet
Engineering Task Force, Mar. 1999.
[3] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a
transport protocol for real-time applications," Request for Comments
1889, Internet Engineering Task Force, Jan. 1996.
[4] J. Rosenberg, P. Mataga, and H. Schulzrinne, "An application
server component architecture for SIP," Internet Draft, Internet
Engineering Task Force, Mar. 2001. Work in progress.
[5] B. Campbell and R. Sparks, "Control of service context using SIP
Rosenberg,Mataga,Ladd [Page 15]
Internet Draft sip-vxml July 13, 2001
Request-URI," Request for Comments 3087, Internet Engineering Task
Force, Apr. 2001.
[6] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
Session initiation protocol," Internet Draft, Internet Engineering
Task Force, Nov. 2000. Work in progress.
[7] H. Schulzrinne and J. Rosenberg, "SIP caller preferences and
callee capabilities," Internet Draft, Internet Engineering Task
Force, Nov. 2000. Work in progress.
[8] E. Zimmerer, J. Peterson, A. Vemuri, L. Ong, F. Audet, M. Watson,
and M.Zonoun, "MIME media types for ISUP and QSIG objects," Internet
Draft, Internet Engineering Task Force, Mar. 2001. Work in progress.
[9] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P.
Leach, and T. Berners-Lee, "Hypertext transfer protocol -- HTTP/1.1,"
Request for Comments 2616, Internet Engineering Task Force, June
1999.
[10] G. Camarillo, J. Holler, and G. Eriksson, "The SDP fid
attribute," Internet Draft, Internet Engineering Task Force, Apr.
2001. Work in progress.
[11] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo,
"Third party call control in SIP," Internet Draft, Internet
Engineering Task Force, Mar. 2001. Work in progress.
[12] R. Sparks, "SIP call control," Internet Draft, Internet
Engineering Task Force, Feb. 2001. Work in progress.
Rosenberg,Mataga,Ladd [Page 16]