On Wed, 2010-06-02 at 14:42 +0400, Alexander Zhukov wrote:
...
> >> 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.
The interface is not important, but a SIP server with IP1 and IP2 on
interface A and B _must_ be able to tell if a received datagram was sent
to IP1 or IP2 - at least for Outbound, but I think it was the case even
before I implemented Outbound although I don't remember the reason
clearly right now.
> >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.
Requires another way to tell what IP the sending side used as
destination - is there another way to tell (in Erlang)?
> 2. Some number of unbound UDP sockets to send outgoing packets.
Hmm, I wonder if you are not required to listen on the ports you use for
sending... some NAT circumvention techniques will surely result in
responses being sent to the same IP and port that you sent something out
from. "rport" would definitely require that, although you are of course
not forced to use rport (it isn't even used by default).
> 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.
Me neither, but it's the best I've been able to come up with. I wonder
why a gen_udp:send/4 call on the _wrong_ socket in your case does not
result in {error, einval} - see sipsocket_udp:do_send2/4?
> To do the right thing you should be able to send a "reply"
> packet by the same interface you got the "initial" packet.
Yes - this is what Oubound requires and it is what is done - at least
when Outbound is requested by the client. It might not be a correct
general case though. A SIP server that receives a packet on eth1 might
have a default route that could (and should) be used for the reply on
eth0.
/Fredrik
_______________________________________________
Yxa-devel mailing list
Yxa-devel@lists.su.se
https://lists.su.se/mailman/listinfo/yxa-devel
