[Serdev] ipv6 to ipv4 proxying

Jan Janak jan at iptel.org
Wed May 5 13:42:41 UTC 2004


On 05-05 03:55, Bert Vermeulen wrote:
> Maxim Sobolev wrote:
> 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.

  I do not understand this statement, if you enable IPv6 in ser then it
  will able to use both, IPv6 and IPv4.

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

  Why don't you use two listen directives, one with IPv4 address and
  another one with IPv6 address ?
 
  If you have dual-stack clients that can do both IPv4 and IPv6 then
  they should imho advertise both IP addresses in SDP and IPv4-clients
  will then use IPv4 to send media to them.

  If you have IPv6-only user agents then you must use rtpproxy to
  convert media from IPv6 to IPv4 and vice versa.

  Rewriting of Contacts in SIP messages is not necessary because if SER
  has record routing enabled and has access to both IPv4 and IPv6 then
  it will do the conversion for you automatically. 

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

  Maybe we don't understand each other properly, what's "connection
  info" exactly ? SDP, Contact, anything else ?

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

  SER does not check if what do you write in config file makes sense, it
  is up to you to write a config file that makes sense.

  It's like wondering why it is possible to write something like this in
  C:

  int a, *b;
  b = 0;
  a = *b;

  Everybody knows that it will crash and yet it is possible to write and
  compile such a program.
  	
> 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.

  It will work if dual-stack user agents advertise both IPv6 and IPv4
  addresses. So it is not that pointless.

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

  Sure, that can be done if there is a PTR record for the IPv6 address
  and if the hostname you get has an A record. If one of the conditions
  fail then you need rtpproxy again.

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

  Well, it is necessary if you want to solve the IPv6-IPv4 problem in
  general without making any assumptions about DNS entries and
  dual-stack user agents.

  If you have IPv6-only and IPv4-only user agents or if there is no way
  of deducing IPv4 address from an IPv6 address then you need RTP proxy.

  In conclusion, is there any problem with SER that needs to be fixed or
  are you just arguing that the sample configuration file is useless ?

    Jan.




More information about the Serdev mailing list