asterisk users - Jul 2012 - chan_sip sending from wrong source, address when multiple interfaces are used

> I must be missing something. If a phone sends a UDP packet to 
> 192.168.1.1, how does that get routed to (arrive at) the 10.0.2.1 
> interface on the Asterisk server? The only way I can imagine that 
> happening is if a router in between the phone and the server has been 
> told that 192.168.1.0/24 is reachable *through* 10.0.2.1, which seems 
> like a bizarre way to construct a network. Getting replies from Asterisk 
> *back* to the phone would also require the IP stack on the Asterisk 
> server to route those replies back over the 10.0.2.0/24 interface 
> instead of the 192.168.1.0/24, which doesn't make any sense either.
This can and will happen, if the multi-interface Asterisk server is
also being used as the router between these networks.

In this case, the packet sent by the client system to 192.168.1.1, is
being sent by the client to the client's active (possibly default/only)
routing gateway, which will be 10.0.2.1.  The packet arrives at the
server/router, and because it matches the IP address assigned to one of
the server's network adapters (and Asterisk is bound to all of them)
it's delivered to Asterisk.

When Asterisk replies, it's doing so via a socket which is bound
to 0.0.0.0.  Since there's no specific IP address bound to this
socket, the kernel has to pick one of the host's IP addresses to
put into the packet it sends... and the one it picks is the one
assigned to the network adapter on which it chooses to transmit
the port.  In this case, that will be 10.0.2.1.

So, the client sends a packet to 192.168.1.1 and gets a response
from 10.0.2.1, which is a huge WTF situation for many protocols.

This is not just an issue for SIP.  I've had exactly this same
problem with IAX2 clients and Asterisk, and had to apply the
exact same cure - I tell IAX2 to bind itself only to my
host's externally-routable public IP address, and not to
0.0.0.0.  Then, if I specify the public IP address as the server
in each IAX2 client configuration, everything works fine.

This is probably a not-unusual configuration if you're setting up
a modest-size "VoIP-only" or "VoIP-mostly" network on a
budget...
a Linux or other Unix-ish system running Asterisk will often
have enough CPU power to handle the RTP routing between networks,
saving you the cost of a dedicated router.  I have this very issue
on my own system - a modest home network with a couple of internal
LANs, some IP ranges set aside for VPNs of various sorts, and one
externally routable IP address.
> chan_sip does have the ability to use connect()-ed sockets for dialogs 
> now, since that is required for TCP, TLS and WebSocket support. It 
> wouldn't be a huge leap to use them for UDP as well, if that was
beneficial.
Would be well worthwhile... and if you can port similar code over
into chan_iax2, it would fix the problem there as well.