[asterisk-bugs] [Asterisk 0018513]: IAX2 REGAUTH Failure dependent on Trunk Name

[Asterisk Bug Tracker]

The following issue has been SUBMITTED. 
====================================================================== 
https://issues.asterisk.org/view.php?id=18513 
====================================================================== 
Reported By:                netfuse
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   18513
Category:                   Channels/chan_iax2
Reproducibility:            random
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           Addons-1.6.2.1 
JIRA:                        
Regression:                 No 
Reviewboard Link:            
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Request Review:              
====================================================================== 
Date Submitted:             2010-12-21 10:16 CST
Last Modified:              2010-12-21 10:16 CST
====================================================================== 
Summary:                    IAX2 REGAUTH Failure dependent on Trunk Name
Description: 
Hi

I have seen intermittently on customer trunks that work the vast majority
of the time, Asterisk sending incorrect REGAUTH packets back to the host.

In fact, they do not even appear in Asterisk's `iax2 set debug` output -
the customer's REGISTER packet is shown as RX, but the TX packet is not.

Taking a network capture of the communication shows that Asterisk is
indeed sending replies, but they are totally incorrect. If the protocol
structure were followed, they are packet type 0x40 with an IE of 0x36...!

Naturally, the Asterisk at the other end ignores these packets and they
don't show up in any debug views/logs.

This issue is actually resolved in this example by rebooting the
customer's router (i.e. resetting the NAT port) and Asterisk seems to be
able to communicate for some time again. I am presuming there is a table of
IAX calls that has become corrupt. All other connections work ok though.

I have hundreds of customers running with the same automatically-generated
trunk info, and only one customer has this issue, with only a different
username and password. I am guessing it's because this particular customer
has a longer IAX username than most and/or it contains the text "iax" at
the end - the former seems more likely. The example as used in the trace
is:

  iax_customer_trunk_01__iax

I have attached this in pcap format so you can see exactly how mangled the
response is!

Thanks,
Leo
====================================================================== 

Issue History 
Date Modified    Username       Field                    Change               
====================================================================== 
2010-12-21 10:16 netfuse        New Issue                                    
2010-12-21 10:16 netfuse        Asterisk Version          => Addons-1.6.2.1  
2010-12-21 10:16 netfuse        Regression                => No              
2010-12-21 10:16 netfuse        SVN Branch (only for SVN checkouts, not tarball
releases) => N/A             
======================================================================