|Summary:||ASTERISK-06469: SIP Responds on incorrect IP|
|Reporter:||Jason Burbage (jburbage)||Labels:|
|Date Opened:||2006-03-03 12:43:10.000-0600||Date Closed:||2006-03-03 17:12:48.000-0600|
|Environment:||Attachments:||( 0) tcpdump.txt|
|Description:||When Asterisk receives any type of request via SIP, it always responds on (apparently) the first IP bound to the first ethernet interface, even when sip is bound to all.|
I attempted to register a SIP device from 188.8.131.52 to the server configured as above, which has a single ethernet interface configured with two IP addresses. eth0 is set to 184.108.40.206 and eth0:1 is set to 220.127.116.11. The phone can register and place calls if it is configured to register with 18.104.22.168, but not 22.214.171.124.
tcpdump -An udp port 5060 and host 126.96.36.199
Attempted to register to 188.8.131.52, and saw the output in the attached file. SIP debug output is not helpful in this case since it does not contain originating IP information for outgoing packets.
However, you can see from the tcpdump that asterisk repeatedly attempts to respond to the SIP device on an IP from which it received no requests.
This behavior also appears to extend to all SIP methods including NOTIFY and INVITE, as you can see from the tcpdump. It may even be broader than just chan_sip, however that's what I was able to test.
****** ADDITIONAL INFORMATION ******
I mentioned this briefly to OEJ at AstriCon Training in Miami December 5-9.
To reproduce, configure your ethernet interface with two IP addresses and attempt to use the second, with SIP bound to all addresses (0.0.0.0).
SIP does appear to bind to the second address if explicitly configured to do so.
|Comments:||By: Andrey S Pankov (casper) 2006-03-03 16:06:29.000-0600|
Why do you think asterisk should respond from 184.108.40.206?
I'm about sure that 'ip route get 220.127.116.11' will show you that your kernel would chose 18.104.22.168 as src address.
By: Tilghman Lesher (tilghman) 2006-03-03 17:12:48.000-0600
This has been asked many times before, and the answer is still the same. We simply don't support this behavior. We do, however, support a multihomed host, as long as the system routes match up to use a different interface to send to that address. Or, in other words, you cannot alias your Ethernet interface to multiple addresses and expect it to work.