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 16:43:36 UTC