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