According to the Freeswitch developpers, Asterisk is using a home made DNS resolver.
This resolver is synchronous, this means that a query need to be finished before to continue. This explain why Asterisk lock during the DNS timeout. Queries must be completed one at a time which slows everything down and generaly make the server fully unusable.
Freeswitch is using the Sofia SIP stack, where DNS queries are asynchronous. This means that in case of DNS problems, this does not produce a complete standstill like in Asterisk. Only the trunk where DNS fail cannot be opened.
This confirm the general feeling i have from Asterisk : the software has not been developped with industrial strenght, like this should be the case for a telephony software, being opensource or commercial.
Asterisk is certainly working nicely when using Digium cards, but as soon as we try to make full IP telephony, this does not work really well. Or at least we need to use some workaround to avoid problems.
I think that using IAX is not the best solution.
-
IAX is missing TCP support, this is important for full IP telephony on DSL WAN networks.
-
IAX cause some problems with signalisation mapping. Even in the SIP world, full IP telephony is far from been standardized regarding signaling (very often we receive congestion instead of busy, or vice versa) . Using IAX for provider links make things more worst.
As you know, telephony service cannot suffered from interuptions for professional use as well as for home use. Simply because in the first case the company rely on it for sales, and in the second case we rely on it for urgency calls.
A service level of at least 99.98 % (ideally 99,998 % like most of the POTS providers in our country) should be targeted.
A service level of 99.98 % is about 8 minutes of down time during one month.
Today this level of service is not possible to achieve with only one VoIP provider. This show that signaling is very important, because in case of a trunk failure, it is very important that Asterisk got the right signaling to try or not the next trunk.
A second big problem we have with all VoIP software is the lack of support for bandwith reservation. In some cases, this can produce missed calls with bad signalisation, or even cause problems on active calls.
This problem to me eyes need to be adressed in futur SIP software versions, as it will never be possible to mimic the service level of POTS without a serious bandwith reservation support.
Olivier ADLER
FRANCE IP