Summary:	ASTERISK-10994: Asterisk providing SIP proxy with incorrect routing information
Reporter:	Patrick Baker (patbaker82)	Labels:
Date Opened:	2007-12-07 16:17:11.000-0600	Date Closed:	2008-03-03 11:57:36.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Channels/chan_sip/Interoperability
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) analysis.txt ( 1) sip-debug.txt ( 2) sip-tcpdump.txt ( 3) sip-tcpdump-pcap
Description:	In attempts to setup asterisk with openSER, I've encountered many issues with asterisk providing incorrect information to the proxy.  In turn the proxy is attempting to use provided information and unable to communicate ACKS and BYE messages back to asterisk. ****** ADDITIONAL INFORMATION ****** ## SIP.CONF ### [general] matchexterniplocally=yes canreinvite=no externip=xxx.206.xxx.136 localnet=10.3.1.0/255.255.255.0 context=default           bindport=5061             bindaddr=0.0.0.0         sipdebug=yes             nat=yes [openser] type=friend context=default insecure=very externalnotify=yes allow=all host=10.3.1.31 nat=no ### NOTES ### SIP client: 10.3.1.115 OPENSER: 10.3.1.31:5060 ASTERISK-SIP: 10.3.1.31:5061 PUBLIC-IP: xxx.206.xxx.136 In this current setup, when an INVITE is sent to asterisk and the INVITE is coming from the "localnet", from bug 0008821, I would assume setting "matchexterniplocally=yes" would replace the contact header and SDP with the localIP 10.3.1.31.  Instead it seams to be replaced with the externip and since the SIP client is within the localnet it will not be able to route back out and in the firewall ( elbow route ). I've also attempted to turn off "matchexterniplocally", with no success.  I've also played with the nat settings as well.  The only resolution that I can find is to comment out the "externip", but unfortunately this breaks clients existing outside the local network. I will attach SIP debug and SIP tcpdump information to outline the issue more.
Comments:	By: Patrick Baker (patbaker82) 2007-12-12 11:08:47.000-0600 Has anyone had a chance to peak at this? By: Patrick Baker (patbaker82) 2007-12-13 12:02:58.000-0600 It would appear with SVN r92526 the reverse is happening.  Internal clients are now working again, but external clients are having issues responding with ACK / BYE messages as previously stated. By: a3ulafia (a3ulafia) 2007-12-13 13:41:23.000-0600 get rid of nat=yes By: Patrick Baker (patbaker82) 2007-12-14 10:44:57.000-0600 Please review the analysis.txt. Removing nat=yes did not resolve the issue. It would appear that asterisk isn't handling NAT for media correctly.  The contact address in the sdp is not being changed from the 10.x private address. By: Joshua C. Colp (jcolp) 2008-01-15 20:56:41.000-0600 So here's the issue: Asterisk determines whether something is local or not by looking at the IP address the packet was received from. Since you are using a SIP proxy in between the outside world and the inside world Asterisk has no idea that it actually came from the outside, to it it came from the proxy (as it did). Is this a bug? Sure, unique to your specific scenario and setup currently. Presently I can't think of a way to solve it either. By: Olle Johansson (oej) 2008-01-22 09:29:53.000-0600 Why don't you use NAThelper in OpenSER to do the translation for you? Using externip in combination with SER seems very messy. By: Olle Johansson (oej) 2008-01-22 09:34:33.000-0600 A patch that could solve this would be to parse the via header, the bottom via header indicates the address of the actual device. But that would require some extra coding. With a proxy in between, NAT=yes can be bad, depending on the layout of your network. By: Patrick Baker (patbaker82) 2008-01-25 10:40:44.000-0600 Thank you all for your comments.   To be "matter of fact", would the recommendation be to configure this within the NATHelper module of openser as suggested, or take the route of fixing the bug within Asterisk.  I feel from the comments that their is a teetering balance of which route to take. Regards By: Joshua C. Colp (jcolp) 2008-03-03 11:57:08.000-0600 I'll step in here and make the final decision for this... in your scenario it is much better to do the NAT handling at your proxy instead of Asterisk.