>>>>> 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 [email protected] https://lists.su.se/mailman/listinfo/yxa-devel
