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

 >> 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.

 FT> Just to check - do you really have a netmask that makes 10.10.16
 FT> and 10.10.18 be on the same network? All my vmnet interfaces have a
 FT> 255.255.255.0 netmask.

vmnet8: 192.168.194.1/255.255.255.0
eth0:   10.10.18.71/255.255.240.0
It seems to be correct for me :)

 >> 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.

 FT> I agree about the principle. IIRC, YXA opens a separate UDP socket
 FT> per interface to be able to distinguish the IP address someone
 FT> sends packets to. There might be better ways to do this, and I'm
 FT> not sure it was the only reason.

Sorry, I do not understand it. Why do you need to distinghuish the IP
adresses by interfaces? Again, I'm no expert in Erlnag networking but I
can't think of any reason to have a separate UPD socket per interface.

>From my point of view it can be as simple as this:

1. One listening UPD socket. It will receive incoming packets from all
   interfaces.

2. Some number of unbound UDP sockets to send outgoing packets.

This way you should not think about interfaces at all. And it seems to
be quite portable.

 FT> So, what a running YXA server has to use for sending datagrams is a
 FT> list of UDP sockets. All sockets are tried (see
 FT> src/transportlayer/sipsocket_udp.erl function do_send/5) until the
 FT> OS says that a socket worked for sending to that particular
 FT> destination.

I do no like the idea. Just the ability to send a packet do warrant you
nothing. To do the right thing you should be able to send a "reply"
packet by the same interface you got the "initial" packet. Or, more
generally, the choice of the interface should be based on the dest IP
and the interface IP. Going this way you may end up writing a small IP
router inside YXA aplication.  (OK, this was a joke :) I do not want to
offend anybody.)

 FT> Perhaps it would be possible to send packets on an unbound UDP
 FT> socket instead, as Dmitriy Kargapolov said something about, while
 FT> still having the complete list of listening UDP sockets? You are
 FT> most welcome to give it a try.

Thank you very much for your suggestion :)) The primary reasons I do not
want to change anything right now are that I do not have any means to
test the results and know almost nothing about YXA network
internals. But I promise that if I ever come with a patch I will sent it
to the list for discussion ;)

BTW, I hate to express ideas about thing I know nothing about. But I was
really shocked when I saw the way the INVITE to my second ciscophone had
gone. So I pray to excuse me for my questions and suggestions ;)

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

Reply via email to