Re: [reSIProcate] resip, ares, and IPv6

[Adam Roach <adam@xxxxxxxxxxx>]

On 5/11/11 10:39 AM, David Stuart wrote:
> OK, sounds reasonable.
>
> Does anyone recall why resip forked ares to begin with? What am I losing
> by switching over to c-ares?

The big reason for the fork is that ares had gone dead, and the original 
maintaners did not respond to emails. Resip had to "fork" the dead code 
just to fix bugs and add features. It's the same reason c-ares ended up 
forking ares, although they've clearly had different enhancements added 
since the fork.

Here is Brad's list of features that resip-ares had but c-ares did not. 
This refers to c-ares 1.5.3, and I know that Brad was working with the 
c-ares team to get some features added, so this might not be completely 
accurate any longer:

On 11/22/08, Brad Spencer wrote:
> I have identified a set of "obvious" features that resiprocate depends
> on simply by looking at the API differences between contrib/ares and
> c-ares.  I have not searched for embedded behavioural changes that may
> have been made to contrib/ares without API changes.  However,
> especially if c-ares vs contrib/ares were to remain a choice at
> configuration time, I think this is okay, at least as a starting point
> because c-ares "works".
>
> The attached patch will allow resiprocate to be configured against the
> trunk version of c-ares (1.5.3 + patches).  Of course, it still allows
> resiprocate to be configured to use contrib/ares as well.  With this
> patch against resiprocate-1.4.1, the following features are missing
> only when using c-ares:
>
>   1. TryServersOfNextNetworkUponRcode3
>
>     I've read the mailing list history on item 7, and I'm still
>     digesting that.  It seems to be only supported on Windows in the
>     current contrib/ares source, though.
>
>   2. AfterSocketCreationFuncPtr
>
>     I haven't been able to find much information about the purpose of
>     the AfterSocketCreationFuncPtr feature, except I found some note
>     about it being related to QoS.
>
>     Is there a reason only UDP sockets from ares are identified via
>     this function?  If I can supply the reasons this is important for
>     QoS, and we can figure out what to do about TCP, there's probably a
>     good argument to be made for adding an analogue of this to c-ares.
>
>   3. DNS servers with IPv6 addresses themselves
>
>     contrib/ares can have IPv4 and IPv6 addresses of DNS_servers_
>     configured (via the additionalNameservers argument and via built-in
>     config parsing), while c-ares can only contact IPv4 addressed DNS
>     servers at the moment.  Note that this has nothing to do with AAAA
>     record lookups, which work fine when using c-ares.
>
>     This seems like a good candidate for a new c-ares feature, and I
>     will ask about it on the c-ares list and report back.

After some quick poking around, I think #2 has been added to c-ares (as 
of 1.6) and integrated into resip's c-ares support; and I think #3 is 
fixed in c-ares (as of 1.7.1) but is not yet integrated.

Derek MacDonald also pointed out that resip-ares had added some features 
to multi-lan failover support when hosts have multiple configured 
interfaces. I think that's what #1 in the list above means, but I can't 
recall.

Byron Campbell noted, back in 2008, that c-ares is substantially faster 
than the resip version (it can do about twice as many DNS transactions 
per second).

/a