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 Monday, 8 April 2002 17:15:10 UTC