Summary:	ASTERISK-02273: chan_sip does not pass digits while using nat
Reporter:	jets (jets)	Labels:
Date Opened:	2004-08-25 15:50:24	Date Closed:	2008-01-15 15:06:04.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) versions.tar.gz
Description:	After the 8/17/2004 CVS chan_sip has a reproducible bug where digits are being ignored in a multiple network interface scenario. ****** ADDITIONAL INFORMATION ****** My test system has two interfaces, eth0, 216.190.35.60, and eth1 172.16.10.1.  Cisco 7960 Phones (IP: 172.16.10.10) register to the 172.16.10.1 interface. Externip is configured for 216.190.35.60 and localnet is configured for 172.16.10.0/255.255.255.0 Asterisk in both situations advertises the contact: sip header as sip:asterisk@216.190.35.60 however with the new CVS asterisk whether i'min authenticate(), in voicemail, or anywhere, asterisk will not recognize digits. Using the newest CVS and just copying chan_sip.c from 8/17 also resolves the problem.  Setting bindaddr=172.16.10.1 does resolve this problem, however i need access to sip calls coming from my public interface, as well as my registered phones. This bug was confirmed on the mailing list by Jamie Ferrara on 8/25/2004.  He has multiple interfaces and is experiencing the same bug. My box is available for someone to log in as root and test this bug.
Comments:	By: jets (jets) 2004-08-25 15:54:43 I apologize, the title is misleading.  I meant to say "multiple interfaces" there is no NAT between the phone and the Asterisk server, they are on the same collision domain (switched network) communicating directly with each other -- there are no filtering firewalls (iptables, etc.) By: Brian West (bkw918) 2004-08-25 16:11:11 Setting externip and localnet doesn't fix it? By: Mark Spencer (markster) 2004-08-25 16:37:09 Can you provide the diff or the versions in which the problem is introduced? By: jets (jets) 2004-08-25 17:02:58 Attached file versions.tar.gz on 8/25 contains: chan_sip.8172004.c from 8/17, .version: CVS-D2004.08.17.06.00.00-08/25/04-14:04:47 chan_sip.8252004.c from 8/25, .version: CVS-HEAD-08/25/04-14:34:04 sipDiff: A simple diff of these two files. ---- bkw: Regarding externip and localnet, previous to the 8/25 upgrade (using cvs from 8/17), my sip.conf had the same externip and localnet settings.  It worked.  Now on 8/25 using the same configuration it breaks. I did a few packet dumps, and Asterisk appears to still be handling externip/localnet the same in the SIP headers. I first thought the newest chan_sip was breaking because the 'contact' sip header had the external ip (Contact: <sip:asterisk@216.190.35.60>) and the phones would then try to contact the external ip.  *However*, the old 8/17 version of the contact: header is exactly the same, which makes me think it's something else. Packet Dumping from the monitoring port on my Cisco Switch, I never see the phone try to contact the external ip address (in case it read the contact: and decided to start talking on the external ip). Brian By: blaxer (blaxer) 2004-08-25 20:12:25 I added externip and localnet and no go (this is Jamie Ferrara BTW) By: Mark Spencer (markster) 2004-08-25 22:04:25 I'm asking you for the diff between the version where it works and the version where it doesn't work.  Those should be TWO CONSECUTIVE versions of the code, not the code from 8/17 vs. the code from 8/25.  There should be something in between where it stopped working.  Thanks. By: Olle Johansson (oej) 2004-08-26 01:53:00 Just checking if I understand correctly: * Is the problem that the Contact: header is the same, regardless of interface used? * Or is it something with "not understanding digits"? If I'm right about the first problem, is there no routing from the 172 network to the other network? You want the Asterisk SIP channel to know which interface we're using and pick a Contact that works on that interface? Maybe you should bind the sip interface to the 172 network with bindaddr= to force the 172 network to be the default network and used in Contact: if we are not outside of the localnet network. That would force the externIP to work for all other networks, including the 216 network. I am guessing, haven't tested since I haven't got a multihomed machine. Please test and verify if this works or if I had to much French wine :-) By: blaxer (blaxer) 2004-08-26 11:06:07 This is very close to the test I tried yesterday, my enviornment is slightly different thought. I have 1 nic serving all VOIP on a 192.x net, the other is on a 10.x network to access the rest of the LAN. There is no routing between the two. Last night I tried setting the bindaddr and localnet to the 192.x network and the externip to the 10.x net there was no change, I was still unable to get digits keyed from the phones to be recognized by *. By: Mark Spencer (markster) 2004-08-26 23:22:10 *taps on monitor* jets, are you there? By: raburton (raburton) 2004-08-29 13:18:49 This problem does not just affect multiple network interface scenarios. I have asterisk running on a box with a single network interface 192.168.7.6. I moved from running 0.9 to CVS-HEAD-08/29/04-16:46:12 and found that an x-lite client (192.168.7.5) and a Cisco 7960 (192.168.7.10) cannot send digits to any application (voicemail, echo test(# to end), etc.). This applies to both local apps and remote apps running on asterisk 0.9 at a friends, connected via iax2. By: Mark Spencer (markster) 2004-08-29 13:25:32 Digits not working doesn't necessarily mean a code problem.  The vast majority of the time, it is caused by configuration issues. By: cloos (cloos) 2004-08-29 14:16:02 I don't know how relevant it is to what others here are reporting, but I noticed dtmf from a cisco ata stop working as well after a cvs up. Turned out I hadn't explicitly included dtmf=rfc2833 in the context; adding that in fixed it. So, what appears to have changed is the need for a dtmf= config line; it used to work w/o one and now you need to specify it. By: raburton (raburton) 2004-08-29 14:42:37 Thanks cloos, that's it. I had just finished tracking down where this change was made. It was between 1.473 & 1.474 (Make sure jointcapability really indicates joint capability (bug ASTERISK-2181)). Perhaps it would be worth modifying the default sip config file. That's where I went to see if it was a changed config option, but there was nothing to indicate in there that I needed to make a change to retain the existing behaviour. It appears that this is required by Cisco devices (plus x-lite, and I'm sure others), it may be worth adding this to the sample Cisco devices in the sample sip config. Also, the correct option is dtmfmode=rfc2833 (not dtmf=rfc2833). Richard. By: Mark Spencer (markster) 2004-08-29 14:55:13 Okay try latest CVS and let me know. By: Mark Spencer (markster) 2004-08-29 14:56:13 (i.e. to clarify, it should restore the original behavior that the global setting works for any given peer/user) By: cloos (cloos) 2004-08-29 15:06:56 > Also, the correct option is dtmfmode=rfc2833 (not dtmf=rfc2833). err, yes.  I was typing from memory .... By: raburton (raburton) 2004-08-29 15:27:57 markster: that's fixed it for me. Thanks! By: Mark Spencer (markster) 2004-08-29 21:41:46 Okay we're going to guess this is fixed.  If not, feel free to reopen! By: Digium Subversion (svnbot) 2008-01-15 15:06:04.000-0600 Repository: asterisk Revision: 3676 U   trunk/channels/chan_sip.c ------------------------------------------------------------------------ r3676 | markster | 2008-01-15 15:06:04 -0600 (Tue, 15 Jan 2008) | 2 lines Set DTMF modes by peer/user properly (bug ASTERISK-2273) ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=3676