- From: Chris Davis <davisc@iivip.com>
- Date: Fri, 28 May 2010 09:11:14 -0500
- 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 UTC