Why we do not suggest to use IAX2
Main reasons:
- IAX2 does not return correct HANGUP CAUSE codes! So solving interconnection problems between servers can be difficult.
- IAX2 can only use 1 thread - that means it can't handle a lot of calls at one time.
Also:
On Thu, 2008-03-27 at 14:38 -0400, Steve Totaro wrote:
> IAX is junk. Never figured out what causes the quality to be so poor,
> maybe it is simultaneous usage, maybe it is trunking enabled, maybe it
> is just junk.
>
all received packets go through 1 and only 1 thread because of the way that udp is done and the fact that they are all going to the same port. This means that for reception you can use 1 and only 1 core/cpu.
If you look at libiax (at least historically, I havent looked for a while) you will see that its very thread unsafe, relying on the fact that 1 thread will handle the calls.
There are some alternatives to libiax that are coming out, I dont know if they are polished yet or not, but others have done their own from scratch implementation, however they too will suffer from the designed in "feature" of 1 thread for reception.
>From a provider point of view this is not good.
Another draw back is that if you want to do load balancing you have to rely on your customers to let that happen (or write a proxy that will do it for you). Basically you have to reinvite the call from the main server to some 2nd server to balance the load. This of course cause the initial server to end the call and totally drop out, which means that you may have 2 CDR records to merge for the same call. And if the client does not have reinvites enabled it wont work. Relying on customers to support your load management system is also not good.
There has been some work done to separate media from signalling to avoid this drawback, or at least that is what the rumor mill has churned out (hey I hear a lot of stuff, it cant all be true can it?). In this way you can operate more like the way SIP operates and lets you have a "ser like" front end for iax. But afaik that is not finished, and its certainly not compatible with older implementations (and possibly not compatible with the RFC draft).
IAX also has to churn through a linked list for each received packet to see where it goes because the media all goes to the same port, thus the same thread receiving the packets it has to find out where to send the data to (ie which call). This causes a performance limiter on it for larger than SOHO use, ie providers that offer this as a 'feature' to their customers. Going through the linked list also requires a mutex to prevent other stuff from changing it, something libiax at least used to not do, thus requiring 1 thread to access it only. This may have been fixed, but a mutex just means that 1 thread can prevent all others from writing and can slow stuff down if it takes a long time to enumerate the list.
If blocking goes on it can mean that the interarrival time of packets is off, and there is a potential for delays so great that audio is noticably disrupted.
So with 2 built in bottlenecks and a requirement that customers participate in your load management system I personally cant recommend this protocol for anything but SOHO use.
Now sip supports more than asterisk sip supports. SIP RFC requires tcp support for example, yet its not in trunk yet. There is CRTP as well (rtp and sip are separate technically), which can be used in some situations for saving bandwidth. There is also trunking ability with RTP although most never use it. The whole point of a SSRC in the rtp is so that the ip/port pair does not need to be used to identify who the stream is for. Asterisk does not fully support any of this (in all fairness neither do many other things).
It wouldnt even be hard to have a media proxy that would take CRTP trunked calls and distribute them to the proper media gateway, but I also havent seen this done, although it wouldnt be that hard to write one. I however would do it different than the way that the asterisk stuff is done creating a structure for the rtp headers so coding is easier and you dont have to do what looks like odd things in the code :)
In this way you can support CRTP+RTP trunking with devices that otherwise do not support them since they would see a normal RTP stream. CRTP is about 17 years old now as well.
Basically the CRTP stuff takes a 40 byte header and turns it into 2 but you have to own both endpoints for that. There are rfc drafts of trunking that were done in 2000 or so that rely on compressed l2tp and crtp to pull it all off with a overhead savings at the end of the day.
So as good as sip may be it can still be better through the use of some older standards :) -- Trixter http://www.0xdecafbad.com Bret McDanel Belfast +44 28 9099 6461 US +1 516 687 5200 http://www.trxtel.com the phone company that pays you!
