Subject: [Sipping] Comments on 'draft-rosenberg-sip-vxml-00.doc'

From: Garland Sharratt <[email-masked]>
Date: Mon, 24 Sep 2001 15:51:01 -0700

Good document.

The concept of "VoiceXML Dialog Servers" should, I think, be applicable
to both Service Nodes (app server + media server) and Media Servers.
Media Servers, unlike Service Nodes, don't do call control, so can't
handle the <transfer> function.

To make the document more "media server friendly", I would like to
propose the following change:

     In Section 5.3, "Transfer", add a note stating that support
     for the <transfer> tag is not expected or appropriate for
     media servers.

An additional comment on Section 4, "Audio Input and Output":

     The document suggests that the dialog server do DTMF detection
     simultaneously on both the audio and telephone events (RFC
     2833) stream, in case the originator missed detecting a
     digit.  But how would the dialog sever know whether a digit in
     the audio stream and a digit in the 2833 stream were in fact
     the same key press?  I think there would be a strong danger of
     double detection.

Garland

---

From: Steve Gardell <[email-masked]>
Date: Thu, 27 Sep 2001 08:12:14 -0400

> -----Original Message-----
> From: Garland Sharratt [mailto:[email-masked]]
> Sent: Tuesday, September 25, 2001 12:30 PM
> To: SIPPING IETF Mailing List
> Subject: Re: [Sipping] Comments on 'draft-rosenberg-sip-vxml-00.doc'
> 
> 
> 1. Given the plans (as I understand them) to remove call 
> control from VoiceXML
> and to create a separate language for call control, it might 
> be appropriate to
> separately consider and discuss handling for both sides (call 
> control vs. IVR,
> voice IVR, recording) in the draft, as I suggest below.
> 

Are we talking about new call control facilites being 
integrated in an orthogonal fashion (e.g. the Universal
Voice Browser Framework W3C submission) or truly removing 
the limited call control that exists today in VXML?
Any references to these plans would be helpful. 

> 2. Even within the same RTP stream, there will be differences 
> in timing due to
> detection delay at the gateway (let's say).  The dialog 
> server will have its
> own, different detection delay.  How can it be sure when it 
> detects an audio
> tone at time X and sees an incoming telephone event at time X 
> +/- Y (its
> detection could be faster or slower than the gateway's) that 
> the two are the
> same digit?
> 
> Yes, it will work if everything is perfect, i.e., both the 
> sender and receives
> compute an accurate digit press event start time for the 
> timestamp and the
> timestamp values match exactly at the receiver.  However, the 
> receiver,
> realistically, will need a setting for how many milliseconds 
> difference it will
> allow and still declare the events to be the same digit.  
> This is not elegant or
> robust.
> 
> Since the main use of RFC 2833 is for compressed codecs 
> (where audio detection
> does not work) anyway, it might be better for the dialog 
> server to get its
> digits from audio detection or RFC 2833 but not both.
> 

Almost certainly.

> Garland
> --
> 
> Jonathan Rosenberg wrote:
> 
> >
> > -----Original Message-----
> > From: Garland Sharratt [mailto:[email-masked]]
> > Sent: Monday, September 24, 2001 6:51 PM
> > To: SIPPING IETF Mailing List
> > Subject: [Sipping] Comments on 'draft-rosenberg-sip-vxml-00.doc'
> >
> > >Good document.
> >
> > Thanks.
> >
> > >The concept of "VoiceXML Dialog Servers" should, I think, 
> be applicable to
> > both Service
> > >Nodes (app server + media server) and Media Servers.  
> Media Servers, unlike
> > Service Nodes,
> > >don't do call control, so can't handle the <transfer> function.
> > >
> > >To make the document more "media server friendly", I would 
> like to propose
> > the following
> > >change:
> > >
> > >In Section 5.3, "Transfer", add a note stating that support for the
> > <transfer> tag is not
> > >expected or appropriate for media servers.
> >
> > While I agree with the extraction of call control and 
> non-usage of the
> > transfer tag, thats not really within the scope of the 
> draft. Its merely
> > stating a mapping of VoiceXML tags to SIP capabilities. Its 
> not stating
> > implementation requirements on VOiceXML tags within media 
> servers. Thats
> > something for the ISC to do ;)
> >
> > >
> > simultaneously on both the
> > >audio and telephone events (RFC 2833) stream, in case the 
> originator missed
> > detecting a
> > >digit.  But how would the dialog sever know whether a 
> digit in the audio
> > stream and a digit
> > >in the 2833 stream were in fact the same key press?  I 
> think there would be
> > a strong danger
> > >of double detection.
> >
> > I think you have in mind the case where the audio and dtmf 
> streams are
> > separate streams. That is not what this is talking about. 
> There is a single
> > audio stream, which is running either rfc2833 encoding or g.711 (or
> > whatever) within the same timestamp space. Thus, I don't 
> think there can be
> > any danger of double detection.
> >
> > -Jonathan R.
> > ---
> > Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
> > Chief Scientist                             First Floor
> > dynamicsoft                                 East Hanover, NJ 07936
> > [email-masked]                     FAX:   (973) 952-5050
> > http://www.jdrosen.net                      PHONE: (973) 952-5000
> > http://www.dynamicsoft.com
> >
> > _______________________________________________
> > Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> > This list is for NEW development of the application of SIP
> > Use [email-masked] for questions on current sip
> > Use [email-masked] for new developments of core SIP
> 
> --
> _____________________________________________________________________
>   Garland Sharratt                     Convedia Corporation
>   VP, Business Development             4190 Still Creek Drive
>     & Chief Architect                  Suite 300
>   [email-masked]               Vancouver, BC, Canada  V5C 6C6
>   Tel: 604.918.6393                    Fax: 604.918.6400
>   Mob: 604.657.1880                    Web: www.convedia.com
> 
> 
> 
> _______________________________________________
> Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [email-masked] for questions on current sip
> Use [email-masked] for new developments of core SIP
> 

_______________________________________________
Sipping mailing list  http://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP