[EMAIL PROTECTED] 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
_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
