> 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!
_______________________________________________
--Bandwidth and Colocation Provided by http://www.api-digital.com--
asterisk-biz mailing list
To UNSUBSCRIBE or update options visit:
Posts
No comments:
Post a Comment