W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2002

RE: Correct interpretation of bridged <transfer> specification

From: Scott McGlashan <scott.mcglashan@pipebeach.com>
Date: Wed, 17 Apr 2002 21:44:26 +0200
Message-ID: <2764A29BE430E64A92EB56561587D2E7107CB1@se01ms02.i.pipebeach.com>
To: "Sharma, Ranjan (Ranjan)" <ranjansharma@lucent.com>, "Kenneth Rehor" <ken@nuance.com>, <www-voice@w3.org>

if you haven't got satisfactory responses to your questions, you can
submit them as change requests for the next draft. Specific alternative
wording proposals are required to get the requests acted upon. 



-----Original Message-----
From: Sharma, Ranjan (Ranjan) [mailto:ranjansharma@lucent.com]
Sent: Monday, April 08, 2002 23:15
To: Kenneth Rehor; www-voice@w3.org
Subject: RE: Correct interpretation of bridged <transfer> specification 

I am not sure if I am missing something here, but the <transfer> element
required (and is not optional) to be supported on the implementation
platform, per VoiceXML 2.0 specification, section 1.2.5.

Next, while I see that speech recognition itself is optional during
<transfer>, DTMF recognition is not, from section 2.3.7 of 1.0 / 2.0
specifications. (Interestingly, the 2.0 specifications add the line
transfer is terminated by DTMF or speech, a near_end_disconnect value is
returned" to the 1.0 specifications).

A few related observations:

- Bridge <transfer> will tie up resources on the implementation platform
we need to monitor DTMF (and optional ASR) during the conversation. This
could very quickly deplete available platform resources.

- A supervised bridge <transfer> with ASR turned on presents another
challenge - how does it recognize "End session", for instance, uttered
in a
conversation as distinct from "End session" that terminates the

- "Help" or other higher level grammars which are outside the scope of
grammar would not be active 

- A "near_end_disconnect" event in this case is explained as "call
and was terminated by the caller". However, the call may be terminated
the ringing phase itself (without completion) by pressing the right


-----Original Message-----
From: Kenneth Rehor [mailto:ken@nuance.com]
Sent: Monday, April 08, 2002 4:43 PM
To: www-voice@w3.org
Subject: RE: Correct interpretation of bridged <transfer> specification 

Listening for user input occurs during the transfer attempt (e.g before
far-end connect), and during the length of the transferred call.  See
10 with the example.

Note that supporting DTMF and/or ASR during a transfer is optional (and
<transfer> itself is optional).  I suppose it might be useful to include
DTMF in the example for clarity.


-----Original Message-----
From: Sharma, Ranjan (Ranjan) [mailto:ranjansharma@lucent.com]
Sent: Monday, April 08, 2002 12:58 PM
To: www-voice@w3.org
Subject: Correct interpretation of bridged <transfer> specification 


The description under <transfer> says:

"During a bridge transfer, the platform can listen for DTMF input from
caller. In particular, if a DTMF grammar appears inside the <transfer>
element, DTMF input matching that grammar will terminate the transfer
return control to the interpreter. A bridge transfer may be terminated
recognition of an utterance matching an enclosed<grammar> element;
of this feature is not required. The <transfer> element is modal in that
grammar defined outside its scope is active."

My question is the scope of the DTMF grammar for terminating the bridged
transfer, please note the phrases "During a bridge transfer" and "A
transfer may be terminated .." first. 

Now, to the question. Is the DTMF grammar operative:
(a) Before a two party stable connection is established (that is, during
ringing of the other number to which the call is transferring)  _OR _
(b) Even afterwards (that is when the two parties are in a conversation)

I tend to think it is (a), since 
(i) the actual VoiceXML session is "parked" on the execution platform
a bridged transfer and
(ii) enforcing a "remote party hang-up" under (b) may not be feasible.


Received on Wednesday, 17 April 2002 15:42:19 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:07:35 UTC