RE: Correct interpretation of bridged <transfer> specification

Ranjan,

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. 

thanks

Scott

-----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
is
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
bridged
<transfer>, DTMF recognition is not, from section 2.3.7 of 1.0 / 2.0
specifications. (Interestingly, the 2.0 specifications add the line
"When
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
if
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
transfer?

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

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

Thanks!
Ranjan




-----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
figure
10 with the example.

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

Ken

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


Hi,

The description under <transfer> says:

"During a bridge transfer, the platform can listen for DTMF input from
the
caller. In particular, if a DTMF grammar appears inside the <transfer>
element, DTMF input matching that grammar will terminate the transfer
and
return control to the interpreter. A bridge transfer may be terminated
by
recognition of an utterance matching an enclosed<grammar> element;
support
of this feature is not required. The <transfer> element is modal in that
no
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
bridge
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
during
a bridged transfer and
(ii) enforcing a "remote party hang-up" under (b) may not be feasible.

Thanks,
Ranjan



.

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