[Home]

Summary:ASTERISK-24518: Avaya Asterisk sip trunk DTMF mis negotiated
Reporter:Jonathan White (londonnet)Labels:
Date Opened:2014-11-13 18:00:49.000-0600Date Closed:2015-02-21 11:05:16.000-0600
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_read
Versions:11.12.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:Centos 6.4Attachments:( 0) capture201412061210.pcap
( 1) full
Description:I am upgrading from Asterisk ver 11.5.1 to 11.12.0
An existing sip trunk is built from an Avaya Session Manager V6 to Asterisk
rfc2833 is configured in sip.conf

Asterisk V 11.5.1 negotiates and receives DTMF correctly (RTP type 101)
Asterisk V 11.12.0 Does not receive DTMF but shows (RTP type 127)

The Sip.conf and rtp.conf files are the same. There is no change to the Avaya configuration

I have tried auto and inband in the sip.conf to see if I can match type 127 but this does not work either.
Comments:By: David Woolley (davidw) 2014-11-14 03:08:55.955-0600

For more details see http://forums.asterisk.org/viewtopic.php?f=1&t=91670

I'm under the impression that this is a known bug (Asterisk getting confused when the telephone events codec number isn't 101), but I can't find the bug report for it at the moment.
By: Michael L. Young (elguero) 2014-11-14 15:46:30.671-0600

David - Is this the bug you are thinking of?  ASTERISK-22789 or this one which is related ASTERISK-23279
By: Michael L. Young (elguero) 2014-11-14 15:50:49.524-0600

Jonathan, can you please attach your packet captures and any dtmf logs you have?

Thanks
By: Jonathan White (londonnet) 2014-11-14 20:03:03.424-0600

Two examples attached. V1.5.1 which passes DTMF and V11.12.0 which is not sending the correct format.

The .78 address is the asterisk server
By: Jonathan White (londonnet) 2014-11-14 20:03:20.174-0600

Packet captures attached
By: Jonathan White (londonnet) 2014-11-14 20:04:55.557-0600

Some logs from Asterisk
By: Matt Jordan (mjordan) 2014-11-15 08:48:24.160-0600

The negotiation looks correct in 11.12.0.

If the DTMF isn't being detected, we'll need a full debug log with 'sip set debug on' and 'rtp set debug on' enabled showing a call negotiating DTMF and the digits being received.

Instructions for gathering a debug log can be found on the Asterisk wiki:

https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
By: Jonathan White (londonnet) 2014-11-15 09:12:00.747-0600

Are you sure it looks right?

sip.conf is set to dtmfmode=rfc2833 yes I see RTP type 127 and not 101

I have some debug info. Uploading now.

Thanks for taking a look
By: Jonathan White (londonnet) 2014-11-15 09:16:08.439-0600

Sip debug enabled and DTMF logging
By: Jonathan White (londonnet) 2014-11-15 09:16:28.679-0600

Attached sip debug
By: David Woolley (davidw) 2014-11-18 07:21:51.691-0600

Certainly one of those two issues if not both.
By: Rusty Newton (rnewton) 2014-11-18 18:34:05.203-0600

[~londonnet] it looks like you didn't get DEBUG messages or the output of 'rtp set debug on' in your log: https://issues.asterisk.org/jira/secure/attachment/51509/V11.12.0%20SIP%20Debug%20enabled%20and%20DTMF%20logging.log

You can follow the [Collecting Debug Information|https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information] guide for specific instructions. Before you attach the output, make sure you see messages starting with DEBUG (the DEBUG channel type log messages) and you should see a whole lot of RTP spam.
By: Jonathan White (londonnet) 2014-11-27 13:24:43.545-0600

I am gaining access to the users site to perform a new set of tests
By: Jonathan White (londonnet) 2014-12-06 10:19:54.695-0600

No DTMF Packet capture
By: Jonathan White (londonnet) 2014-12-06 10:20:30.118-0600

No DTMF Packet capture
By: Jonathan White (londonnet) 2014-12-06 10:21:11.960-0600

Debug no dtmf
By: Jonathan White (londonnet) 2014-12-06 10:22:03.042-0600

New debug and packet capture attached.
By: Jonathan White (londonnet) 2014-12-06 10:22:44.855-0600

New packet capture and debug data attached
By: Michael L. Young (elguero) 2014-12-06 10:34:21.372-0600

Jonathan,

Your log is still missing the information requested.  Please make sure you are turning this on by doing, 'rtp set debug on' and 'sip set debug on' in addition to running 'core set debug 5' at the cli.  While all of this is turned on, reproduce your problem so we can see everything that is going on.

Thanks
By: Jonathan White (londonnet) 2014-12-06 13:14:59.493-0600

Full debug
By: Jonathan White (londonnet) 2014-12-06 13:15:52.374-0600

I have attached the full debug file I created for the same call. I will take another capture and double check I have enabled everythig
By: Jonathan White (londonnet) 2014-12-06 13:46:21.884-0600

full log
By: Jonathan White (londonnet) 2014-12-06 13:48:05.636-0600

packet capture
By: Rusty Newton (rnewton) 2014-12-09 17:02:20.863-0600

So, I see the RTP and RFC2833 traffic in the pcap, but in I don't see the inbound RTP traffic in the RTP debug output from Asterisk.

I may be overlooking something, but it doesn't appear the RTP is getting into Asterisk.

Besides DTMF, does inbound audio from Avaya to Asterisk work at all? That is, can you call into a Record and record a sound file, or call to another peer?


By: Jonathan White (londonnet) 2014-12-09 18:31:30.983-0600

Are you happy you have the right level of debug data coming in the log file now?
We tried inband, setting this both sides, Avaya and asterisk and we got the same results.
This sip configuration is via an Avaya Session Manager over udp but we also tried creating a sip trunk directly from Avaya Communication Manager over rcp, same results and finally a H.323 trunk direct from Avaya Communication Manager. So has little to do with call control and more to do with audio (expected) which is handeled in this instance by multiple G450 gateways.  
We found dialling in with X-Lite worked fine.
By: Jonathan White (londonnet) 2014-12-09 18:32:24.410-0600

comment added
By: Jonathan White (londonnet) 2014-12-09 18:33:54.141-0600

We are going to run up a test of Asterisk 13 this week to see if the result is the same
By: Michael L. Young (elguero) 2014-12-10 11:42:42.880-0600

One thing that might be causing a difference would be this patch: ASTERISK-23279.  Asterisk now respects the requested RTP mapping as of version 11.9.

edit:

I just removed my comments because I just realized I was looking at the wrong thing... sorry about that.
By: Rusty Newton (rnewton) 2015-01-08 09:40:47.517-0600

Jonathan, let us know what you find in 13. I'm not sure what is going on here yet.
By: Rusty Newton (rnewton) 2015-01-29 18:27:26.318-0600

Jonathan - I noticed on the forum you have provided an update, but not here:

{quote}
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.
{quote}

Is this the latest on the issue?
By: Jonathan White (londonnet) 2015-01-30 10:03:07.166-0600

We are trying to arrange a maintenance window so we can perform an upgrade which we will retest later version of Asterisk.

After raising a ticket with Avaya we currently suspect the arp cache of the Avaya G450 gateways which are responsible for transcoding and RTP in this instance.

It is possible that the method we used to upgrade the service Asterisk provides is the issue. We down the current server and bring up a second upgraded server on the same IP. The trunk comes up but the arp tables on the G450's do not refresh for 4 hours.

We will not know for sure if this the true issue until we can get back to the customers site to retest.

Thanks fir the support, I will update this ticket once we have retested
By: Matt Jordan (mjordan) 2015-02-21 11:03:37.375-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines