W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2001

[www-voice] Re: new working draft for requirements for call control

From: Garland Sharratt <gsharratt@convedia.com>
Date: Tue, 31 Jul 2001 20:47:43 -0700
Message-ID: <3B677BDF.2DA537C4@convedia.com>
To: www-voice@w3.org
CC: Dave Raggett <dsr@w3.org>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:54 GMT