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

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 25 Sep 2001 02:21:52 -0400

-----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 ;)

>
>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.

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

---

From: Garland Sharratt <[email-masked]>
Date: Tue, 25 Sep 2001 09:29:30 -0700

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.

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.

Garland
--

--
_____________________________________________________________________
  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

---

From: "Don Stanwyck" <[email-masked]>
Date: Tue, 25 Sep 2001 12:57:23 -0600

> any danger of double detection.

There is a significant danger that the media server will detect digits in
the clipped portions of the streams sent by the gateway prior to its own
digit detection.  The gateway forwards RTP packets with the samples embedded
in order not to add additional delay to the cross-gateway path.  Only when
it has determined that the embedded audio is a detectable tone does it cease
forwarding.  The result is the media server, if it is more sensitive to
tones, may detect a tone inband prior to receiving the first RFC2833 encoded
tone-message.

Secondly, as we have pointed out on other lists, the currect reading of
RFC2833 indicates the preferred method is for the gateway to forward both
the audio stream and the audio messages in parallel (this is an error in the
wording, not the intent of the authors).  The result is that some gateways
may, if they take the words literally, send both continuously.

Don Stanwyck

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 26 Sep 2001 00:03:49 +0300

Hello,

> may, if they take the words literally, send both continuously.

Yes. Some gateways actually send both streams in parallel. That is, they
do not mute the audio channel when DTMF tones are detected. Then it is
up to the receiver which stream is rendered to the user.

Some time ago we were trying to figure out which behavior was more
common (mute the voice channel or not), and I believe that it was more
common to send both in parallel.

Best regards,

Gonzalo

-- 
Gonzalo Camarillo                    Phone :   +1 212 939 71 71
Columbia University                  Mobile:  +358 40 702 35 35
472 Computer Science Building        Fax   :  +358  9 299 30 52
1214 Amsterdam Ave., Mail Code 0401  http://www.hut.fi/~gonzalo
New York, NY 10027                   
USA                              [email-masked]

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 26 Sep 2001 00:16:07 +0300

Hello,

> may, if they take the words literally, send both continuously.

I have checked that out and, as a matter of fact, the intent of the
authors of RFC 2833 was that the recommended behavior is to send both
streams in parallel. Which is the error of wording you are talking
about?

Best regards,

Gonzalo

---

From: "Eric Burger" <[email-masked]>
Date: Wed, 26 Sep 2001 07:35:10 -0400

<transfer> is an optional tag.  In the next version of the draft I can see
putting in a sentence on that.

I'm not sure how much we want to get into architectures here.  In the W3C
Voice Browser Work Group there is a document titled the Universal Voice
Browser Framework.  That document describes a reference architecture and
usage scenarios that fully separate application, call control, and user
interface presentation.  It is at the W3C, and not the IETF, as it is purely
an architecture document.

The document is at
<http://lists.w3.org/Archives/Member/w3c-voice-wg/2001Aug/0116.html>.  I
think you need to be a W3C member to access it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Garland Sharratt
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.
[snip]