>>>>> Fredrik Thulin (FT) writes:

 FT> On Tue, 2010-06-01 at 15:52 +0400, Alexander Zhukov wrote:
 FT> ...
 >> 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> address.

 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.

-- 
Alexander Zhukov
_______________________________________________
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel

Reply via email to