[Asterisk-Users] Re: How far is IAX to be a Standard

[Steve Underwood]

niels at wxn.nl wrote:

>Hello
>
>IAX really isn't the 'one and only' perfect signaling protocol because
>many people forget one thing
>
>IAX has one technical issue (by design) which makes it difficult to ever
>get accepted by the big boys, a real big problem for carriers who have
>big loads on their systems like we do.
>
>With IAX the audio (RTP) and signaling goes embedded over one port. We
>  
>
IAX doesn't use RTP.

>all know that the big advantage ofcourse is that this makes it an
>excellent performer behind a NAT, but the big disadvantage is that there
>is not any DSP chip available in the market which is able to get the
>codecs encoded and put into this embedded rtp+signaling channel, and I
>wander if there ever will be because another piece of software does the
>signaling (asterisk in this case) asterisk would have to 'tell' the DSP
>chip the signaling packets to embed into the IAX/RTP channel.. That
>would be a whole new DSP standard, Will any chipmaker (besides digium)
>ever see the need to design such a chip?
>  
>
This paragraph makes no sense whatsoever.

>Anyhow, the situation now, is that there is no DSP chip, that means ..
>Your main processor has to encode the channel in total (3 to 4 E1's
>absolute is the max possible with dual xeon 3 ghz I read somewhere in
>this case) 
>  
>
Most * implementations today do not use custom DSP chips. They often 
don't need to. They can if the need arises. Echo cancellation is an area 
where custom DSP would be a big help, and has seriously been considered. 
This has nothing to do with IAX, though.

>Another method is to send the incoming IAX on asterisk out again with
>SIP to a gateway with hardware DSP's.. (like we do).. This needs less
>performance ofcourse because asterisk doesn't have to do codec encoding,
>but nevertheless will still have to transcode to get the signaling and
>RTP merged and submerged from/to this one IAX port to separate
>Signaling/RTP ports.. Our setup now is the second scenario.. And my
>first (rough) calculations are that a dual xeon 3.0 ghz can handle about
>500 concurrent channels in this scenario...
>  
>
You are just trying to make use of existing hardware. This says nothing 
about the merits of the protocols involved. Do you trunk your RTP, or 
accept a huge data flow? RTP trunking isn't properly standardised, but 
it is on the way, because RTP overheads make a joke of high performance 
low bit rate codecs.

>Ever wandered why there isn't any codec (DSP) hardware availiable for
>asterisk?? I think here is the answer, because it is very hard to make,
>Digium should then be able to design a totally new DSP chip design ..
>And that's much more difficult than to design an E1 board. 
>  
>
It isn't hard to make. It is very straightforward. Getting enough volume 
to justify the development has been the issue. Lots of commercial DSP 
cards to do the job exist, but they are priced high for a low volume 
market. Its a chicken and egg problem - expensive cards have a small 
market, cheap cards would have a possibly large but somewhat unproven 
market. There are no real technicals issues here, just commercial ones.

>Our case is that we have about 200 E1's of voip (h323 and sip) traffic
>and are still expanding. If we would have this all on IAX this would be
>unmanageable, we would need 50 linux boxes.
>  
>
For that much traffic you obviously have quite a bit of some kind of 
hardware. What would be the problem if that were 50 cheap, almost 
disposable, Linux boxes? If you bring those E1s in bundled on a couple 
of OC-somethings you can't bring them into a pure * system today, but 
just wait a while and see. This has nothing to do with the IAX protocol, 
though.

>Conclusion.. IAX Is a good performer behind NAT and perfect for small
>setups but to work in an enterprise, Much work has to be done.
>  
>
True. Much work has to be done. However, the real barriers are all 
commercial. The technical ones are quite small, and most of what you 
said it not really relevant to the barriers at all.

Steve