[asterisk-users] ITSP's no longer supporting IAX?

Jon Pounder jonp at inline.net
Sat Mar 28 12:13:06 CDT 2009


Roger Marquis wrote:
> Steve Totaro wrote:
>   
>> I understand you are a developer and you want IAX2 to be great.
>> That is your job, but the fact is that it is not and has caused
>> audio and security problems for YEARS in EVERY release. It
>> should "bug" you and everyone at Digium that waves the IAX2
>> flag.
>>     
>
> Can you elaborate on these "audio and security problems" Steve?  Looking
> at the two protocol specs I cannot see a basis for your claim.  IAX
> doesn't embed the local IP address in the packet data but that's surely no
> substantive security.  It does separate data and signaling at the
> application-level, but again, that's no basis for such a claim.
>
> Protocols must be looked at separately from their implementations.  From
> the various responses it appears that Asterisk 1.4's implementation of IAX
> has flaws.  These do not necessarily reflect on the protocol.  OTOH, there
> are a lot of engineers with SIP skill and experience who, naturally, are
> concerned with their investment in time, education, and experience.  While
> this may or may not apply to Sonicwall engineering, it's also true that any
> streaming protocol will be better handled by devices that process packets
> in ASICs (high-end firewalls) rather than CPUs (PCs and low-end firewalls).
>   

This sounds like a bunch of gobbledegook spewed out by those very "high 
end" firewall vendors.
Call it what you want but anything that processes packets in any way and 
makes a decision on what to do is by definition a CPU. And a general 
purpose CPU is not exactly poor at the job. If you look at utilization 
levels and latency on a typical CPU you would have thrown away already 
as a server, its barely even noticable utilization running a complex set 
of rules on a high volume data stream.
> FWIW (2 data points) I get uniformly better service from our IAX trunk
> provider than our SIP trunk provider.  No idea whether that's protocol,
> implementation (1.4 on my side), or provider-related though I suspect the
> later.
>
> Roger Marquis
>
> _______________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users
>
>   




More information about the asterisk-users mailing list