[Serdev] ipv6 to ipv4 proxying

[Bert Vermeulen]

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

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

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


Bert Vermeulen
bert at biot.com