[Asterisk-Dev] Petition for IAX firmware

[hwstar at rodgers.sdcoxmail.com]

May I suggest trying  this on a WRT54G running Asterisk to see what type of load it presents to the MIPS processor?
This could be  a cheap and effective aggregator which will not require a proprietary solution.

Steve.

> 
> From: Greg Hill <gregh-asteriskd at hillnet.us>
> Date: 2005/04/06 Wed AM 11:41:07 EDT
> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
> Subject: Re: [Asterisk-Dev] Petition for IAX firmware
> 
> On Wed, 6 Apr 2005, Steve Kann wrote:
> 
> > Greg Hill wrote:
> >
> >> On Wed, 6 Apr 2005, Paul wrote:
> >> 
> >>> Steve Kann wrote:
> >>> 
> >>>> 
> >>>> I have two points to make:
> >>>> 
> >>>> 1) If I were a vendor, and there was documentation on the IAX2 protocol 
> >>>> (not even an RFC, but at least some kind of semi-official documentation), 
> >>>> I'd be a lot more likely to implement it.
> >>>> 
> >>>> 2) The idea of an IAX2 trunk-aggregator is interesting. This is probably 
> >>>> something that doesn't need a whole x86 linux box -- taking multiple IAX2 
> >>>> streams and putting them into trunks is trivial in terms of computational 
> >>>> requirements.. A small microcontroller or an ARM chip is more than enough 
> >>>> for this, and would be a neat idea of virtual PBX deployments..
> >>>> 
> >>>> -SteveK
> >>> 
> >>> 
> >> (snip)
> >> 
> >>> But I still don't know the answer to my question about SIP vs. IAX2. 
> >>> Suppose the remote site has a mix of SIP and IAX2 devices. Does the 
> >>> presence of SIP devices increase the computational requirements much? My 
> >>> thinking is that any SIP ata's or phones at the remote site are going to 
> >>> be extensions of the master * pbx. Hopefully that makes it easier on the 
> >>> trunk-aggregator cpu. Also I expect that in most situations where this was 
> >>> deployed a codec other than g.711 would be used since there is a 
> >>> motivation to conserve bandwidth. So we have SIP traffic from a provider 
> >>> to the master server, IAX2 trunking to the remote slave server and back to 
> >>> SIP over the LAN to somebody's deskset. Will that conversion back to SIP 
> >>> to reach the deskset degrade the call quality?
> >> 
> >> 
> >> SIP and IAX are control protocols. They don't deal with audio coding. 
> >> Converting a call between SIP and IAX protocols should require minimal 
> >> (no?) re-writing of the audio packets if the same codec is used on each 
> >> side. So it seems (to me) that a translation between SIP and IAX wouldn't 
> >> be a computationally expensive task.
> >
> > I'm quite aware of what SIP and IAX are :)
> >
> > If you're trying to say that SIP and IAX both use RTP for the media stream, 
> > that's wrong. For SIP (and h.323 and others), the media is carried in a 
> > separate RTP stream. For IAX2, the media is carried in IAX2 packets. But, 
> > taking the media from one format to another, while computationally simple, 
> > still requires unpacking and repacking the individual packets, translating 
> > metadata (timestamps, etc).
> 
> hmm, I thought I was replying to Paul's question about your post, not 
> to your directly.. oh well. :)
> 
> Anyway, yes, the media really is integrated in the same stream with 
> control in IAX2. I sort of glossed over that, because the point I was 
> getting at is that the audio codec is semi-independent of the signal 
> protocol. That implies, as you later stated, that audio quality need not 
> be degraded by a SIP-to-IAX conversion because multiple encode-decode 
> operations can be avoided by simply using the same codec on both sides of 
> the link. Though I'm not familiar with the specifics of packing/unpacking 
> packets and metadata, I speculated that surely that overhead pales in 
> comparison to an audio transcoding operation. So, based on that, I 
> concluded that a relatively wimpy processor would be likely to do the job 
> fairly easily, as you had stated. It was an attempt to fill in the logic 
> to demonstrate how you concluded that IAX trunk aggregation (and, by 
> extension, SIP+IAX aggregation) need not be done on a high-power CPU.
> 
> Greg
> 
> _______________________________________________
> Asterisk-Dev mailing list
> Asterisk-Dev at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>