[Serdev] ipv6 to ipv4 proxying

[Andrei Pelinescu-Onciul]

comments inline.

On May 05, 2004 at 03:55, Bert Vermeulen <bert at biot.com> wrote:
> Maxim Sobolev wrote:
> 
> >Bert Vermeulen wrote:
> 
> >>Unfortunately, this requires rtpproxy from CVS, which is broken at the 
> >>moment. I've had no luck getting this working.
> >
> >It doesn't mean that it is broken.
> 
> Of course not, but in this case it's segfaulting (in ishostseq(), called 
> from main.c:800).

If it's segfaulting could you put the core, the sources and the
compiled rtpproxy at fault on some web/ftp site and send an url?
If there are small enough you could also send them to me by mail and
probably to Maxim (I don't know if he likes receiving coredumps by mail
 though :-)).
> 
> >>In any case, I must disagree that this is the way to go. Quite simply 
> >>SER supports IPv6 in theory only; actually turning it on breaks all 
> >>connectivity to non-IPv6 registered clients. In other words, enabling 
> >>IPv6 in SER makes it an IPv6-only SIP proxy.
> >
> >Huh? What makes you think so??? You can specify both IPv4 address to 
> >listen for SIP packers as well as IPv6 addresses. This in no way will 
> >make SER "an IPv6-only SIP proxy" or break IPv4 or IPv6 connectivity, at 
> >least if the config is correct and you don't try to contact IPv4 client 
> >using IPv6 and vice versa ;).
> 
> Let me restate that: enabling IPv6 in SER makes it an IPv6-only SIP proxy 
> for clients that support IPv6, and an IPv4-only proxy for IPv4 clients; and 
> never the twain shall meet.
> 
> >>It seems wrong to have a simple "listen" directive that makes the 
> >>server listen on IPv6, yet this breaks everything unless you then also 
> >>set up:
> >>
> >>- an undocumented RTP proxy
> >>- an equally undocumented nathelper module
> >>- two extra tables in the database, created manually
> >>- a bunch of logic in the config file to make it all work together
> >
> >Well, no offence, but it is how free software works. You are getting 
> >software for free, you are getting no technical support, you may or may 
> >not get documentation, you may or may not get a help from the mailing list.
> 
> That's not the point here. I've done my bit with free software, and know 
> full well how it works, thanks. My point is you have to kludge around quite 
> a lot, for something that IMHO could easily be standard behavior in SER: 
> fix connection info on the fly, to enable IPv4-only clients to talk to IPv6 
> clients.
> 
> >>A client that uses IPv4 to register can be assumed to not support IPv6 
> >>at all, since IPv6-aware clients "prefer" IPv6. Therefore, the SIP 
> >>proxy that is about to connect the two together can be sure the call 
> >>is going to fail.
> >
> >Why? I can't follow your logic here. The proxy can use IPv4 to talk to 
> >IPv4 clients and IPv6 to talk to IPv6 clients.
> 
> But it also tries to make an IPv4-only client talk to an IPv6 client, with 
> IPv6, which can't work. What's the point of forwarding a request with IP6 
> connection info to an IPv4 client? Might as well send back a 404 instead, 
> it won't work anyway.
> 
> I'm suggesting either sending back an error to the originating client, or 
> rewriting connection info. Simply forwarding it, as happens now, is 
> pointless; it won't ever work.

IMHO by default a proxy should not care about the message body. It should not
check it, just forward it. If you want to mangle the SDP you must
specifically modify your configuration to do so (e.g. use nathelper).


> 
> >>Instead of relaying the INVITE through as is, knowing that it'll fail 
> >>eventually, wouldn't it be more interesting to e.g. at least replace 
> >>the request's
> >>"IN IP6 <ipv6 address>" with "IN IP4 <resolved hostname>"? This gives 
> >>the IPv4-only client at the other end at least a fighting chance to 
> >>complete the call.

So you want the proxy to do reverse dns lookups on the ipv6 address in
the hope that a record might exist (you would be surprised to see how
many addresses do not have a reverse dns map), and then replace the ip
in sdp with it hoping again that the name will be also ipv4 resolvable.
This would mean a lot of time lost for the proxy (all this dns lookups
take lots of time, especially if the answer is negative) and again I
don't think the proxy should touch the sdp unless instructed to do so.
> >
> >This is actually what nathelper/rtpproxy in bridge mode do.
> 
> Er? Surely you don't need an RTP proxy to rewrite the originating client's 
> IPv6 address to its resolved name?
> 
> As much as I appreciate nathelper -- there's a need for this obviously, and 
> rtpproxy (which I actually quite like, even if it doesn't work for me at 
> the moment), I don't think they're really necessary to solve the IPv4-IPv6 
> connection problem.
> 
> 


Andrei