W3C home > Mailing lists > Public > www-voice@w3.org > April to June 2010

Re: April CCXML 7_3: required property reason in dialog.terminatetransfer

From: Chris Davis <davisc@iivip.com>
Date: Fri, 28 May 2010 09:11:14 -0500
Message-ID: <4BFFCF02.5010504@iivip.com>
To: www-voice@w3.org
In my mind, the "reason" property of the dialog.terminatetransfer maps 
to the "Reason" column in VoiceXML's
description of the <transfer> tag:
http://www.w3.org/TR/voicexml21/#sec-transfer

The irony here is that if CCXML is actually performing the call control 
for the VoiceXML, CCXML will have
to inform VoiceXML of things like "the caller hung up", "the callee was 
busy" etc. and then they would be
echoed back to CCXML on the dialog.terminatetransfer.

To me the deeper issue is that VoiceXML has no business doing call 
control and switching when combined w/CCXML.
However, VoiceXML came first and <transfer> is grandfathered in; and of 
course not all VoiceXML platforms
have a CCXML front door. Our VoiceXML developer at the end of the hall 
often reminds me who was first...

Regards,
Chris


Petr Kuba wrote:
> Chris,
>
> wouldn't values be more appropriate in your case rather that reason? 
> By the way, values property is missing in this event.
>
> Petr
>
>
> On 28.5.2010 15:41, Chris Davis wrote:
>> I concur that it can be made optional. We use it for call detail 
>> records.
>>
>> Petr Kuba wrote:
>>> Hello www-voice,
>>>
>>> In 7_3.txml, assetion 430 tests presence of the reason property in
>>> dialog.terminatetransfer.
>>>
>>> May I ask why this property is required according to the
>>> Specification? VoiceXML specification doesn't provide any reason for
>>> the terminate transfer request and therefore only some general
>>> description can be used in this case. It is obviously not very useful.
>>> I believe the same problem can appear for other dialog systems besides
>>> VoiceXML.
>>>
>>> We would recommend to make the reason property optional.
>>>
>>> Thanks,
>>> Petr
>>>
>>
>>
>
>


-- 
Chris Davis
Interact Incorporated R&D
512-502-9969x117
Received on Friday, 28 May 2010 14:11:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 May 2010 14:11:57 GMT