On 02/08/2012 04:29 AM, Tony Mountifield wrote:
In article<4f324279.70...@message-id.plonk.de>,
Jakob Hirsch<j...@plonk.de> wrote:
Raj Mathur (राज माथ�र), 2012-02-08 03:27:
Packets not going out on the same interface as the one they were
received on is a general IP issue, not just for connectionless
Right, this was a inaccuracy. It should say "Asterisk does not reply
with the IP address with which packets were received". Asterisk (as most
applications) does not care about network interfaces, it just handles IP
addresses.
protocols. The same behaviour can be seen with TCP too. Unless you
mangle with iptables or something, all information about the received
A tcp connection is defined by the tuple (source host&port, destination
host&port), so if you write to a tcp socket, the kernel knows which
source address it has to use (and also which destination address, so the
application doesn't need to know that at all).
As there's no such relation in udp, the application has to provide the
destination address. The kernel then decides which source address to
use, as long as the application did not bind() to a specific address.
This is why some UDP servers such as for DNS and NTP create a separate
socket bound specifically to each local IP address. Then by sending a
response via the same socket as the request was received on, it can be
reasonably sure that the response will go out on the right interface.
Maybe Asterisk does or could do the same. I haven't checked.
Well, 'Asterisk' is very broad, because really you are talking about
each Asterisk module that can bind to sockets... and there are many of them.
In the case of chan_iax2, multiple bindings are possible, and manual
configuration could be done to individually bind to each address you
want to provide services on (even if some of those addresses are
configured on the same interface). Responses will be sent over the same
socket the request was received on.
In the case of chan_sip, only one UDP binding is possible (and one
TCP/TLS binding). The code *could* be improved to handle multiple
bindings, but it would be a large and invasive effort to do so.
I've had thoughts in the past about this, and it would even possible to
make this automatic (for systems where virtual hosting is being done),
and have sockets automatically bound to new IP addresses that are
discovered at run time... but that would still require that chan_sip be
improved to properly handle fully multi-threaded operation for all of
its data structures and operations.
Alternatively, Olle Johannson has some patches that allow multiple
instances of chan_sip to be loaded simultaneously; this could also be
used to provide the sort of 'multiple binding' being talked about here.
--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kflem...@digium.com | SIP: kpflem...@digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
