[asterisk-bugs] [Asterisk 0011853]: bindaddr problems

[noreply at bugs.digium.com]

A NOTE has been added to this issue. 
====================================================================== 
http://bugs.digium.com/view.php?id=11853 
====================================================================== 
Reported By:                zenon
Assigned To:                
====================================================================== 
Project:                    Asterisk
Issue ID:                   11853
Category:                   Channels/chan_sip/General
Reproducibility:            N/A
Severity:                   major
Priority:                   normal
Status:                     new
Asterisk Version:           1.4.17 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
====================================================================== 
Date Submitted:             01-27-2008 18:45 CST
Last Modified:              01-30-2008 09:56 CST
====================================================================== 
Summary:                    bindaddr problems
Description: 
I run asterisk on a machine with six IP addresses not counting loopback,
four public and two private, the latter connecting VPNs. I want SIP on only
one public and one private IP address and absolutely not on the rest. 

As far as I have been able to figure by trial and error (yeay
documentation!), there is no way to tell chan_sip to bind to two addresses;
bindaddr will only accept one single address and can only occur once in
sip.conf. So, since I need SIP on two addresses and must not advertise it
on the other four, using bindaddr=0.0.0.0 and firewalling UDP 5060 on the
remaining addresses seems to be the only solution. 

I have a NAT'ed Linksys PAP2 SIP client that keeps causing problems. It
works just fine with bindaddr=[public SIP address] in sip.conf, but keeps
failing with bindaddr=0.0.0.0. Debugging SIP with bindaddr=0.0.0.0 shows
"Contact: <sip:[account]@[wrong_public_address]>" headers being sent by
asterisk in the "Trying" message of the registration process, followed by
"401 Unauthorized". The wrong public address that is sent is the "real"
public address of the machine, the rest being aliases on the same physical
interface. 

My (uncertain) conclusion is that, if bindaddr=0.0.0.0, asterisk puts the
first address it can find on the machine in the Contact: header of its
response to a registration attempt, thereby causing the client to send
authentication data to the wrong address and authentication to fail. 

If this conclusion is correct, the solution should be easy: don't go
guessing addresses and don't send the Contact: header at all, but just let
the client continue talking to the IP address that it was already talking
to. 


====================================================================== 

---------------------------------------------------------------------- 
 zenon - 01-30-08 09:56  
---------------------------------------------------------------------- 
Uh, I can hardly read code, let alone write it, that's why I asked whether
it's three lines of code OR a major rewrite. Anyway, taking into account
oej's reply and the new version policy, would it be correct to assume that
the fix might make it into 1.6 but will not make it into 1.4? 

The bottom line of these questions is that I'm trying to figure how to
deal with this problem in the meanwhile and how long that meanwhile might
be. All the workarounds I can think of are extremely messy and the only
other alternative, to move asterisk to a machine of its own, is costly, so
that's what's on my mind; not an argument. 

Talking about workarounds, let me ask: if bindaddr=0.0.0.0 and some other
application has already bound to port 5060 on some of many IP addresses on
the machine when asterisk is started, will asterisk just bind to the
remaining addresses or will it fail to start? 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
01-30-08 09:56  zenon          Note Added: 0081431                          
======================================================================