The following grammar URLs show up in the TAR portal for call ID 07f706626c5599beea25c5382827c435@141.31.8.62:
http://141.31.8.128:8080/7711/-/resources/Hello_Voice/Default/delivery.gram
http://141.31.8.128:8080/7711/-/resources/Hello_Voice/Default/name.gram
http://141.31.8.128:8080/7711/-/resources/Hello_Voice/Default/address.gram
http://141.31.8.128:8080/7711/-/resources/Hello_Voice/Default/phone.gram
However, this is a call to extension 1111, i.e., the Peanuts item, and these resources are asociated with the Pizza item. So, they shouldn't show up as events for this call.
David please check whether this is a problem with overlapping calls in the database.
There is another call, fa145564b1cd1b62477b83bace9a36e6@141.31.8.62, which is showing issues, too. There are two recordings listed right after each other: The Cairo log read
955055 2015-08-24 22:26:01,680 DEBUG ~.~.~.~.~.~.SpeechDataMonitor [Thread-739]: v2 *** SpeechEndSignal encountered!
955056 2015-08-24 22:26:01,693 DEBUG ~.~.~.MrcpRequestProcessorImpl [Thread-183]: MrcpRequestProcessorImpl.processRequest()...
955057 wavNameeee1 : c:/temp/201508242226110695.wav
and shortly after:
955107 2015-08-24 22:26:01,884 DEBUG ~.~.~.MrcpRequestProcessorImpl [Thread-184]: MrcpRequestProcessorImpl got response from request handler.
955108 wavNameeee1 : c:/temp/201508242226110885.wav
These are two recordings a mere 200ms apart from each other! @Patrick, why is this happening?
I have seen this latter issue a number of times now. It seems to be the VAD which starts recognition to later figure out it was only noise and start another recognition including the actual speech. This behavior can even be called a feature and should not be causing actual trouble.
This is related to case
https://sourceforge.net/p/halef/tickets/58/
Fixed by fixing case https://sourceforge.net/p/halef/tickets/58/
There are again instances of calls with wrong events listed. For example:
7792f6f2aa58e7cc2c7d7b6afe4da297@141.31.8.62