Re: CCXML: insufficient VoiceXML integration details? - ISSUE-753

Chris:

Based on a working group review of these comments we would like to defer this to the next version of CCXML as the scope of these changes would be pretty wide. Is this resolution acceptable to you? If so we we reassign this issue to the next spec version. 

Best regards,

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800 
skype:zscgeek 



On Dec 7, 2010, at 5:37 AM, Baggia Paolo wrote:

> 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 Thursday, 13 January 2011 14:37:20 UTC