We have answering machine detection (AMD_APP) running and on our dialer roughly 1 out of every 200 or so calls gets stuck on the AMD almost indefinitely and eventually return HANGUP after the sip trunk provider has an RTP timeout, our internal timeout does nothing here on triggering the hangup.
I set under sip settings RTP Timeout and RTP HOLD TImeout to 60 seconds.
We originate from a local context to a pjsip and everything works fine 99% of the time, but every so often it looks like the channel gets hung up on somewhere yet the dialplan still runs until it gets to the AMD command, then stays there until the trunk provider terminates.
Anything I can do to ensure if there are not two valid answered legs of the call and it gets to the AMD command that it terminates immidiately? I do not even know if that is the issue, all I can see is that the call stays open the whole time with our trunk provider and eventuals times out for an rtp timeout from their end not ours?
Any ideas what can be going on here? We are using an EC2 aws instance for our pbx, but like i said 99%+ of our calls go out no issue, it’s just very random. I verified our firewall ports were allowing ports 10000-20000 udp on both the local box and the aws firewall…
Any workarounds or something to try?
After Greeting Silence
Total Analysis Time
Minimum Word Length
Maximum Word Length
Between Words Silence
Maximum Number Of Words
This is the only output from log
– Channel PJSIP/voxtelesysshortpjsip-00000b20 left ‘simple_bridge’ basic-bridge <9a48bc49-0628-4550-9763-7e238df60997>
– Channel Local/[email protected];2 left ‘simple_bridge’ basic-bridge <9a48bc49-0628-4550-9763-7e238df60997>
== Spawn extension (outbound-dialer-custom, s, 5) exited non-zero on ‘Local/[email protected];2’
– AMD: Channel [Local/[email protected];1]. HANGUP