Re: [reSIProcate] Multiple Addresses on the same interface
Just an addition:
After thinking about it I realized the described problem not only
applies to when there are multiple addresses on the same interface, but
always when there are multiple routes to the target.
Best regard,
gabriel
Gabriel Hege wrote:
Hi!
I have a problem using the resiprocate stack on a (Windows) machine with
multiple IP addresses assigned to the same interface.
The setup is the following:
To be able to run multiple services on the same port on a single
machine, it has multiple IPs from the same subnet assigned to its
network interface. When I tell the stack to not bind to the primary
address but to any other address of this interface, it can't send any
locally initiated transactions, but fails with the following message:
SIP/2.0 503 No matching transport found
Replying to incoming messages works properly.
I think the problem lies in how the outgoing transport is chosen:
WinCompat::determineSourceInterfaceWithoutIPv6() only returns the first
matching entry from GetIpAddrTable(), but in my case for example the
second would actually be the right one. So I see two solutions to this
problem:
1. Either checking if we have got a transport for the chosen address in
determineSourceInterfaceWithoutIPv6() and else trying the next one.
2. Or having determineSourceInterfaceWithoutIPv6() return a list of
matching addresses and calling findTransportBySource() on all of them in
TransportSelector::transmit() until we find a matching one.
Are there any better solutions to this problem?
I get the same error, when compiling with NO_IPHLPAPI. I haven't looked
into this code yet, but I guess the problem is pretty much the same and
might also apply on Unix/Linux.
By the way, why is there all this windows-specific code for iphlpapi.dll
when doing it the standard way works as well? Especially seeing the
following comment in front of determineSourceInterfaceWithoutIPv6():
// !slg! - This function is horribly slow (upto 200ms) and can cause
serious performance issues for servers.
// We should consider finding more efficient APIs, or caching
some of the results.
best regards,
gabriel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxx
https://list.resiprocate.org/mailman/listinfo/resiprocate-devel