Using Asterisk 18.2.1
Using the default configuration to receive DTMF events as RTP out-of-band:
[transport-udp] type=transport protocol=udp bind=0.0.0.0 external_signaling_address = x.x.x.x external_media_address = x.x.x.x [Phoneout] type = endpoint transport=transport-udp allow= !all,ulaw,alaw aors = AbcOutbound direct_media=no context=voice-otp from_domain= x.x.x.x send_rpid=yes rtp_symmetric=yes force_rport=yes timers=no outbound_auth = AbcDigestHeader
The problem: Our ARI application places calls to several different countries around the world. In some countries (UK, Germany) more than others we see that around 5% of the time users press the keypads to generate tones, our Asterisk server gets the RTP stream with those events, but our application does not receive a ChannelDtmfReceived event.
In a regular flow of execution we see the RTP events reaching the Asterisk server and the ChannelDtmfReceived event being sent to the app; In this case a DTMF 8 event was received.
We can see the associated events in the Asterisk log:
On other cases we see the DTMF RTP events coming in to the Asterisk servers but no ARI event being generated; In this case we would expect an event for DTMF digit 1:
Why does this happen? In the Asterisk logs we can see the duration of the DTMF received is between 60 and 300ms. When the duration is short usually there’s an “emulation” warning on the log, but the ARI events are generated. I do not see a pattern that would show when an ARI event is not generated…
Can it be that DTMF RTP events arrive out of order (udp) and this messes up the logic to generate the ARI event?
How can we improve the flow so Asterisk generates the ARI events more reliably?
Thanks for any suggestions