>>>>> Mikael Magnusson (MM) writes: > >> 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. >> MM> YXA needs to know which IP address it receives requests on over UDP to MM> be able to support symmetric response routing (RFC 3581), I MM> think. When using symmetric response routing it isn't enough to MM> send the response to the IP address and port you received it from, MM> you also need to send the response from the same IP address and MM> port you received the request on. This is to play nice with NAT:s MM> sitting between the two SIP devices.
OK, I can see the logic. >> >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. >> MM> Then you need to use recvmsg, which I think is not supported in MM> Erlang. {ok, Socket} = gen_udp:open(Port), gen_udp:recv(Socket, Length) >> 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. >> MM> Requires sendmsg, again unsupported in Erlang. gen_udp:send(Socket, Address, Port, Packet) I can be wrong, bug it looks very like C interface. May be it was unsupported at the time YXA was started. 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.) >> MM> There isn't a one-to-one mapping between interface and IP-addresses. Any MM> number of IP addresses can be bound to one interface. And these IP MM> addresses can be in the same or different networks. Yes, you are right. One can attach more than one IP to the eth0. But most applications most of the time deal with logical interfaces which have only one IP attached to it. Looking this way YXA should open UDP socket for every logical interface. May be it does. The problem arises when YXA needs to send some "inital" packet, like it was in my case. The packet in not a reply packet, there is no info that will help you to choose the right logical interface. One need to take "routing decision" based solely on the destination address. It looks very like usual IP router works ;) In my case the problem was with vmnet interface. I guess it was intentionally configured like a oneway gateway, that is the packet send by it can go happily to the outside world but nobody in the outside world knows anything about it. Thank you very much for your comments. I'm still not satisfied completely but I have at least two points now: "symmetric response routing" and (my guess) "historical reasons" :) -- Alexander Zhukov _______________________________________________ Yxa-devel mailing list Yxa-devel@lists.su.se https://lists.su.se/mailman/listinfo/yxa-devel