>>>>> Fredrik Thulin (FT) writes:
FT> On Tue, 2010-06-01 at 15:52 +0400, Alexander Zhukov wrote:
>> 192.168.67.1 is an IP of the vmnet8 (virtual network interface used
>> by vmware workstation) on the host where incomingpproxy is running.
>> When I stopped vmware virtual interfaces the call was established
>> without problems.
>> The question is: is this is a bug or a feature?
>> If an additional info is required I'm ready to supply it.
FT> Can't be called a feature, but I'm not sure it could be said to be
FT> a bug in YXA that it does not work when you have unusable IP
FT> addresses on interfaces in your server =).
FT> The code in siphost.erl tries to avoid unusable interfaces, such as
FT> those that are down (function usable_if), or has a loopback
FT> Since someone might actually _want_ to run YXA on a vmnet
FT> interface, we can't just ignore those interfaces.
FT> I can't think of any other solution than for you to configure the
FT> list of "good" IP addresses for your server. See the configuration
FT> option 'myips'. From the README :
FT> myips (no default) For some platforms autodetection of the IP
FT> addresses of the network interfaces doesn't work. If you have that
FT> problem, list your IP addresses in this configuration parameter.
Thank you very much for your answer!
I added myips option and it works.
But I still do not undestand some points.
In my case incomingproxy should send an INVITE to the 10.10.16.157. The
correct interface to send the packet by is one with an address from the
same network -- 10.10.18.71.
Why incomingroxy sets source IP address of the outgoing packet? Usually
this job is done by an IP stack. Application which sits on the
"application" level should not bother with such low level details.
Yxa-devel mailing list