- From: Garland Sharratt <gsharratt@convedia.com>
- Date: Tue, 31 Jul 2001 20:47:43 -0700
- To: www-voice@w3.org
- CC: Dave Raggett <dsr@w3.org>
- Message-ID: <3B677BDF.2DA537C4@convedia.com>
I have a couple of comments on the "Call Control Requirements in a Voice Browser Framework" document, April 13, 2001 draft: 1. A missing requirement (in my view) is that the new call control system should support the decomposition of media processing from application logic, call control, and signaling: o The softswitch architecture clearly separates the call control layer layer (e.g., application server function) from the media layer (media server function). This decomposition is well accepted and is reflected in actual network equipment. o VoiceXML today mixes call control and media by putting DISCONNECT and TRANSFER in with pure media processing (e.g., IVR) operations. (DISCONNECT is actually ok for a media server.) o Pure media servers (available on the market today) are not able to execute call control operations (expect for DISCONNECT). Consequently, the VoiceXML script that is passed to a media server by an application server (or softswitch) must not contain any TRANSFER operations. (The application server controlling the media server must execute TRANSFER.) o If the new call control system is mixed into VoiceXML, the media server safe subset of VoiceXML will need to exclude all these new call control operations. (Again, the application server would have to execute the call control commands.) o It would therefore be better to clearly separate the media processing language (VoiceXML minus TRANSFER) from the call control language (CCXML). o To be very clear, CCXML would set up and manipulate call legs (RTP connections) while VoiceXML would operate only within those already set up RTP connections (e.g., IVR, recording/playback, ASR/TTS). 2. "4. Inter-Session Communication Requirements -- 5. standard inter-session communication protocol -- This requirement addresses the expectation that communication will need to occur between disparate systems, thus requiring a standardized inter-session communication protocol. HTTP to dialog servers is one possible mechanism." o SIP INFO and SIP NOTIFY are two other possible mechanisms. o (Note: VoiceXML allows HTTP GET or POST for method in <submit>. Perhaps it should allow SIP INFO and SIP NOTIFY based methods too.) Garland -- > Date: Wed, 18 Apr 2001 14:09:27 +0100 (GMT Daylight Time) > From: Dave Raggett <dsr@w3.org> > To: www-voice@w3.org > Message-ID: <Pine.WNT.4.10.10104181404480.-45163885-100000@hazel> > Subject: new working draft for requirements for call control > > Your comments are welcomed on a newly published working draft > for requirements for call control in a voice browser framework. > The new working draft can be found at: > > http://www.w3.org/TR/call-control-reqs > > Abstract > > This document describes requirements for mechanisms that enable > fine-grained control of speech (signal processing) resources and > telephony resources in a VoiceXML telephony platform. The scope of > these language features is for controlling resources in a platform > on the network edge, not for building network-based call processing > applications in a telephone switching system, or for controlling an > entire telecom network. > > A solution to these requirements is under development by the Voice > Browser working group, and will make it very much easier to develop > a wide range of new communication services. > > Regards, > > -- Dave Raggett <dsr@w3.org> or <dave.raggett@openwave.com> > W3C Visiting Fellow, see http://www.w3.org/People/Raggett > tel/fax: +44 122 578 3011 (or 2521) +44 771 213 7629 (mobile)
Received on Tuesday, 31 July 2001 23:47:58 UTC