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

[Steve Kann]

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
>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?
>  
>
I think this is a non-issue.

splitting up the data from the signaling is very easy to do, and in a 
two-chip solution (general purpose + DSP), the GP CPU will handle the 
IAX (and UDP, and IP, etc) protocols, and hand only the codec payload to 
the DSP for processing.

With RTP, it is still handled the same way, because the GP CPU will 
still be handling the UDP and IP layers, and I would imagine 
unwrapping/wrapping up RTP as well.

RTP makes some kinds of QoS simpler to do, because the signaling and 
media are separated, but there really doesn't seem to me to be any kind 
of major loss from having signalling in the same QoS realm, since it is 
so small and insignificant compared to the media itself.

IAX' biggest problem is that the market momentum is behind RTP-based 
protocols, and the market will probably (eventually) build it's 
advantages (NAT-transparency, trunking) into SIP or something, before 
they switch to IAX.  (I.e. you could enhance SIP to have an option of 
presenting data and control on the same port, or do perform some kind of 
trunking, etc).  Not being documented is probably it's second biggest 
problem.  Third is that it isn't as feature-complete as RTP/RTCP, etc.