Hello,
I’m having a problem that AMI sometimes sends DTMF events and sometimes it does not send. I’m looking at events when I enabled manager set debug on. Sometimes I can see the events but for some of the calls I cannot see any DTMF events. Do you have any idea why is that happening? Do you have any idea how to debug this? I’m using PJSIP. This issue is about DTMF detection.
Thanks
DTMF is not being sent; or
DTMF is not being sent with correct timing or levels; or
DTMF is not being correctly decoded when converted from audio to digital; or
You are using VoIP and you are trying to decode inband DTMF sent over a voice codec (e.g. G.729 or GSM) rather than a >= 3.1kHz audio one; or
You only have one AMI session and it is busy waiting for a response to an action, and queueing up asynchronous events for later; etc.
Generally you are asking people to guess based on insufficient information.
What debugging information would help you?
The relevant parts of the channel technology configuration file. If the channel technology supports dtmfmode selection, a protocol trace for that technology driver. If the channel technology uses RTP, “rtp set debug on” output. The DTMF debugging channel from the Asterisk logs (see logger.conf). A trace of the AMI.
When I enabled rtp set debug on I could notice something interesting. For the calls for which I’m not getting any DTMF events I’m also not getting any RTP packets. I’m not sure why is that happening. Please take a look at logs from a call that is ok and logs from a call for which we failed to collect DTMF.
ok.txt (36.8 KB)
failed.txt (13.3 KB)
You need to double check the media addresses (c= line) in the SDP. Whilst I note that the failed case has a different media address from the signalling address, that is perfectly possible and should only affect outbound media.
Otherwise you need to track the RTP through the network, and find out where it is getting lost.
Hmmm… what I noticed is that asterisk chose a port outside of range 10000-20000 for the failed call. Why is asterisk doing that? It should be by default using that range. Any ideas why is this happening?
Are you sure you haven’t modified rtp.conf, as there is no reason why it would violate the rtp.conf settings, and it would affect so many people if it did that it would be found very quickly.
Thank you for helping on this.
If I set the port range in rtp.conf then it starts to work but when I remove rtp.conf then it stops to work. Very strange.
Isn’t there something else in asterisk configuration that can change the ports?
That’s because 10000 to 20000 isn’t the real default:
Hmmm… Interesting. Thanks for finding this.
What actually noticed is that Twilio (our SIP trunking provider) is using symmetric RTP which means that it ignores the port that asterisk proposed and it uses the port they generated in the INVITE. Is it possible that there is a strange race condition when asterisk will open the RTP port later? What I observe is that this problem does not happen when the EAGI binary responds with STREAM FILE when the call starts. Is it possible that STREAM FILE is actually opening the port? Is it possible that when the call does not start with STREAM FILE, asterisk sometimes opens the RTP port and sometimes does not?
How can I verify that this is actually happening?
There is some terminology confusion in chan_pjsip with respect to symmetric RTP, but in the strict sense (RFC 4961) it is what Asterisk normally does, which is to use the port that it sends in the SDP as the source port when sending RTP. I think that is necessary for the next interpretation.
I think chan_pjsip for the same meaning as comedia in chan_sip, which means that it will send RTP to the address and port from which it receives RTP, after a pause for learning. You can’t have a situation where both ends actually need this NAT workaround, as you would get a stalemate, but Asterisk resolves this when the reality is that the other side doesn’t need it by sending according to the SDP until it learns otherwise. I think it may lose a few frames at the start confirming the address details.
Asterisk will open the port before it sends the SDP nominating the port.
The port in the SDP offer (what I think you meant by the INVITE) is never a proposal as to the port that the other side should listen on but only ever a statement of the port that the local side intends to listen to (assuming that things like NAT don’t get in the way).
So what do you think might be happening there? Why am I receiving the RTP packets only for some of the calls?
Your NAT or firewall rules pass 10000 to 20000 but you are using the default port range of 5000 to 31000.
Thanks for the help. It looks like changing the port range in rtp.conf solved the problem.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.