Menu with interruptible recorded voice prompts blocks control flow when prompt is interrupted by user interaction #29
Labels
Comments
ranlauf
changed the title
|
Could you please provide trace level logs of this happening, as well as confirm the versions of Adhearsion, adhearsion-asr, Punchblock and Asterisk that you are using? Additionally, any further simplification of the example that you can do would be appreciated, such as simple repetition of |
|
Hello Ben, thank you for your quick answer. Here is a stripped down, but working, example controller which demonstrates the issue. If you press "1" during the first menu, you will hear the vm-pls-try-again, but not the second menu. This happens on a system with Adhearsion can either run on the CentOS 7 machine or remotely on a Unbuntu 12.0.4. It happens in both environments. class TestController < Adhearsion::CallController
def run
answer
menu %w(file://vm-press file://vm-first file://vm-for file://vm-password), :limit => 1 do
match [1, 2, 3] do |dial|
logger.info "Caller pressed #{dial}"
end
end
interruptible_play 'file://vm-pls-try-again'
#####################################
# this menu is never audible
#####################################
menu %w(file://vm-press file://vm-first file://vm-for file://vm-password), :limit => 1 do
match [1, 2, 3] do |dial|
logger.info "Caller pressed #{dial}"
end
end
hangup
end
endFinally, here is the trace log of adhearsion which records one pass of the above controller. I waited some time in the end when the second menu would not play, and finally hung up the calling phone. Greetings, Rüdiger =========================== TRACE LOG ======================== |
|
It looks like Asterisk is clearing your call as soon as the |
|
Here is the Asterisk Log over the duration of the call. Hoping it sheds some light on the issue. |
|
This really looks like an Asterisk bug. I would follow up with the Asterisk community about it. You may be able to sidestep the issue implementing the |
|
Well, thanks for your help so far. So what exactly is the problem? Is it this: What i believe to see here is that Asterisk thinks the playback failed because it was interrupted. Is that the issue? |
|
No, really everything from here onwards: It is Asterisk terminating the call because of some failure which I don't fully understand right now. That is why I say the Asterisk community will be able to help better pinpoint the issue. I do now notice that you are using IAX, though, and wonder why, and if that might have anything to do with it. A trace of IAX traffic might shed some more light on the situation. |
|
After addressing the issue on the Asterisk JIRA (https://issues.asterisk.org/jira/browse/ASTERISK-25563) i have been told that Asterisk is behaving as it should. Seemingly, Adhearsion redirects the call into the adhearsion-redirect context after the DTMF signal, which initiates the hangup on the old channel. (Please ignore the SIP BYE issue mentioned on the Asterisk JIRA, it is a phantom problem.) Is there something we can do to validate this assumption? For example, where to put the breakpoint to debug the issue in the IDE? To further simplify things, we also reproduced the scenario with a SIP phone instead of a IAX2 call. ASTERISK LOG OF A WORKING CALL:ASTERISK LOG OF A BROKEN CALL |
If you have an alternative log which demonstrates the issue but does not feature a BYE from the phone, you should supply that on JIRA. It looks like the last log you pasted is a candidate.
This appears to be correct.
That is correct behaviour.
I'd suggest attempting to reproduce this with Adhearsion 3.0.0.beta1. On the basis of that result, we can appropriately evaluate what course of action to take. |
|
Adhearsion 3.0.0.beta1 does not start on my machine with MRI Ruby 2.2.1 My celluloid gems are: celluloid (0.17.2) |
|
Urgh, Celluloid went and made more large breaking changes in yet another point release. The class was not typoed here, but has changed in Celluloid. Contributions to make us compatible with their latest revision appreciated. Otherwise, try pinning to a version that we pin Adhearsion to: https://github.com/adhearsion/adhearsion/blob/develop/adhearsion.gemspec#L28 |
|
Ok, I used celluloid 0.16.0 now, and a first quick test shows the same result as before, meaning that i do not hear the second menu. |
|
Please provide new logs. Note that a link to a gist is preferred over inlining logs, since this issue now scrolls to the sun and back. |
|
Please find a corresponding Asterisk log here: ranlauf/2170e68cece999b037a0 |
|
Your Adhearsion log here is at DEBUG level. I really need TRACE. |
|
So attempting to reproduce, it seems you can't have been using Adhearsion 3.0.0.beta1, because it does not have |
|
Turns out that if we use Is this something you feel like contributing support for, @ranlauf? We'd very much appreciate assistance to get Adhearsion 3 out the door. |
|
Closing this in favour of adhearsion/adhearsion#593. Discussion of the fix should continue there. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
There seems to be a problem when using interruptible recorded voice prompts. When the caller makes a choice before all the files are played, this blocks subsequent calls of menu or ask.
You will see the following example code fail, when the caller makes their choice before all the prompts are spoken, if they pick the valid options "1" or "2" as a dtmf signal.
What happens, is that on the second pass, adhearsion does not play any file, but seems to wait for input, yet does not accept any. So it feels like a deadlock, the code hangs.
Example code:
The text was updated successfully, but these errors were encountered: