I have rebuilt my asterisk server from 11.5 to 11.12 and now I am having issues with DTMF on my sip trunks from Avaya.
This shows itself by not accepting DTMF on conference bridge calls, I do not have any other menus.
If I connect directly to the asterisk server via x-lite, DTMF works just fine.
The sip.conf file is the same, what else can I check?
Thanks
Other than the config held in sip.conf I can’t see that DTMF is configured in any other config file.
The only difference I see here is the version of Asterisk.
Does this look like a bug?
Enable DTMF logging. Do a sip debug and check the DTMF method negotiated.
I have had the opportunity to perform some on site tests today and the problem persists. Asterisk version 11.5.1 will receive DTMF from and Avaya sip trunk but Asterisk Version 11.12.0 will not.
I have tried the exact same sip.conf file, bouncing the Avaya trunk etc with no result.
I have compared the output of “sip show settings” and the only difference I see is the version of asterisk, T.38 MaxDtgrm and Outbound reg retry 403:0
I turned on DTMF logging to the console and see no DTMF being received on asterisk 11.12.0
I enabled “sip set debug on” and the only reference I see in the messages that relate to DTMF are:
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|) which is the same on both server traces.
I have also captured a wire-shark trace of both servers which I will spend some time on seeing I can see why I am not getting DTMF
However I can not see why this is a problem with this version of Asterisk. Any ideas of where I can look for differences?
If you are offering telephone events, check whether the Avaya is sending telephone events for DTMF.
I think I am getting closer.
After taking some packet captures I can see a little more what is happening:
On asterisk 11.5.1 I see an RTP packet source port 2092 destine for 6374 RTP EVE
On asterisk 11.12.0 I see an RTP packet source port 2062 destine for 15840 Dynamic RTP Type 127
Initially I thought there maybe a difference in the configuration of rtp.conf but I can confirm that both are set as follows:
rtpstart=2048
rtpend=65535
(This is a default for Avaya sip trunks as far as I can see)
However I notice that defaults are rtpstart=5000 and rtpend=31000
Is there a valid range which is now implemented in later versions of asterisk or is anything valid?
Is there a command which shows what the RTP values are set to from the command line? It maybe that my settings in rtp.conf are being ignored as they are out of range in the later version.
Anyone seen rtp type 127 before? It looks like an error message.
Thanks
I don’t understand your issue with RTP port ranges. All the ports are in the specified range (although the range only applies to local ones).
Without the SDP it is not possible to know what codec type 127 is. It may well be telephone events.
There was a bug in which Asterisk was not properly coping when the peer used 101 for something other than telephone events, but that should be fixed in the latest version.
What made me think it was an RTP issue was I performed a test using x-lite which worked where the Avaya trunk didn’t.
Looking at the packet capture I can see DTMF being sent by the x-lite client but on a much higher port range than the Avaya trunk.
This made me think the type 127’s on the Avaya capture maybe related to the low port number.
I am getting audio OK which is also on a high port number. Only the failed DTMF tones come in on low port numbers.
On the older asterisk install the low port numbers used to send DTMF work just fine.
127 is not a port number.
It looks like an error code not a port number.
That particular RTP packet came in on UDP 2048 ish where as audio is coming in above 10,000
It is the RTP content type number. Very low numbers are pre-defined to represent commonly used codecs. The rest are specified in the SDP sent by the receiving side. Normally even the low numbers are specified. 127 is not a low number in this context.
No but the port number is at the bottom of the defined range the 127 number is at the top of that group.
To recap
DTMF from Avaya to Asterisk V11.5.1 on low UDP port numbers OK
DTMF from Avaya to Asterisk V11.12.0 on low UDP port numbers Fails
DTMF from x-lite to Asterisk V11.12.0 on high UDP port numbers OK
Just an observation and currently the only difference I can see
No evidence for this. Asterisk would not be listening to that port number, so you would have to capture it with tcpdump or wireshark.
The 127 is NOT A PORT NUMBER. The lowest port number for which you have any evidence is 2062.
As already hinted, you need to provide us with the contents of the SDP exchange.
At no point have I suggested 127 is a port number. It looks like an error code.
At the same point of a good call I get RTP event and DTMF is sent on a bad call instead of getting DTMF I get RTP Type 127
I have wireshark captures. What am I looking for in the SDP packets? It’s too big to dump on the forum.
Ahha!
Media Description, name and address (m): audio 2062 RTP/AVP 8 18 0 127
Media Type: audio
Media Port: 2062
Media Protocol: RTP/AVP
Media Format: ITU-T G.711 PCMA
Media Format: ITU-T G.729
Media Format: ITU-T G.711 PCMU
Media Format: DynamicRTP-Type-127
Right at the end of the an SDP packet from asterisk to Avaya it says the following
Media Attribute (a): rtpmap:127 telephone-event/8000
Media Attribute Fieldname: rtpmap
Media Format: 127
Mime Type: Telephone-event
Sample Rate: 8000
Both SDP packets look almost the same accept for sequence numbers and CSeq: 1 Invite the Allow section has Message set in addition on the later Asterisk server
But later on in the Second SDP packet there is this:
Working
Media Description, name and address (m): audio 6374 RTP/AVP 8 101
Not Working
Media Description, name and address (m): audio 15840 RTP/AVP 8 127
So what could have gone wrong here?
So this is a very informative link
community.polycom.com/t5/VoIP/FA … /td-p/4237
although this is a polycom and some other sip provider it shows quite nicly whats going on regarding DTMF.
It simply looks like Asterisk is and Avaya are negotiating the wrong DTMF type even though there is no configuration change Avaya side.
101 = RFC2833
127 = Inband
97 = Inform
Is this correct?
So if inband is being negotiated instead of RFC2833 and both sip.conf files are the same, where else should I be looking for configuration changes on the Asterisk side?
127 is RFC2833, not inband Inband uses ulaw, Alaw, or whatever music capable codec you are using for the speech.
Some versions of Asterisk, get confused when the peer tries to use anything other than 101 for RFC2833. I hope that is fixed, but you need to update to the latest version.
I had already checked the release notes for later version of Asterisk even Asterisk 13.x
11.12.0 was the latest packaged version available up until a few days ago. but again nothing in the release notes for 11.14 to indicate a fix for DTMF related issues.
Iv’e opened a ticket on the bug tracker. This is doesn’t look like a configuration issue anymore
If it is not rejected as a duplicate, you are going to need to meet the SIP bug reporting guidelines. verbosity 5, debug 5, full log enabled, and sip set debug on.
Also note that bug categories depend on how many people are affected, not the impact on you personally. This one is probably “minor”.
To complete the cross-linking, this is issues.asterisk.org/jira/browse/ASTERISK-24518 on the bug tracker.
Debug reports were provided and no conclusive issues were found.
However, and this is yet to be confirmed, there is a good theory that the issue is coursed by the Avaya G450 gateways not refreshing their arp tables when I switch from production asterisk server to test asterisk server.
This sort of behavior was witnessed after a similar issue was cleared by itself over a period of 4 hours which happens to be the timeout period for an Avaya G450 to repopulate its arp table.
We have some further testes scheduled in the new year where we will see if this theory is the root course of this issue. But for anyone who is having a problem like this now, just try clearing the arp cache on your G450 gateways and see if this fixes the issue.