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.
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?
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?
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).