- From: Baggia Paolo <paolo.baggia@loquendo.com>
- Date: Tue, 7 Dec 2010 11:37:22 +0100
- To: Chris Davis <davisc@iivip.com>
- CC: Baggia Paolo <paolo.baggia@loquendo.com>, www-voice <www-voice@w3.org>, "w3c-voice-wg@w3.org" <w3c-voice-wg@w3.org>
Chris:
Good catch. I tracked it as ISSUE-753. We will discuss it in a short, but
being a late stage for the spec, it might be deferred to a future version
of CCXML.
Regards,
Paolo
-------------------------------------------------------------
From: Chris Davis <davisc@iivip.com>
Date: Thu, 02 Dec 2010 08:04:47 -0600
Message-ID: <4CF7A77F.6000603@iivip.com>
To: www-voice@w3.org
Hello www-voice,
Section D.9 of the CCXML
spec(http://www.w3.org/TR/2010/CR-ccxml-20100401/#VoiceXMLIntegration)
attempts to describe how to integrate support for VoiceXML's<transfer>
within CCXML.
It appears incomplete in the following regards:
1) no clear way for VoiceXML to compute the "duration" shadow variable
of the <transfer> tag. Only CCXML knows how long the far side was
connected.
2) no way for VoiceXML to indicate whether caller should <join> to the
callee
to hear call progress tones before the call is answered. If there is no
transferaudio attribute of the <transfer> tag, there is no harm in an
early
<join>. However, if transferaudio exists and that <join> occurs the caller
will never hear it.
3) no way for VoiceXML to abort playback of any transferaudio once the
callee
answers. A case can be made that because CCXML controls the switching the
connections can be made such that the output of the playback doesn't
go anywhere
but this is inefficient.
4) no way for VoiceXML to indicate to CCXML that transferaudio playback
has completed.
Such notification would allow CCXML to then <join> caller and callee
to allow
caller to hear call progress (please wait while we connect your
call....ring ring ).
I propose a new event - dialog.transfer.connected - to inform VoiceXML
the far side has answered. This will solve #3 above and allow VoiceXML
to start
its own timer for duration also solving #1 (time difference calculated
when VoiceXML is told
end of transfer).
Finally, a new dialog.transfer.callprogress event would signal CCXML to
peform an
early <join> of caller to callee for call progress before the call is
answered.
VoiceXML could send this right after the dialog.transfer if there is no
transferaudio,
or after transferaudio completes if there is transferaudio. This would
solve #2 and #4 above.
Regards,
Chris
--
Chris Davis
Interact Incorporated R&D
512-354-8202
Received on Tuesday, 7 December 2010 10:37:55 UTC