[Asterisk-Dev] Petition for IAX firmware

Wai Wu wwu at calltrol.com
Wed Apr 6 07:23:14 MST 2005


Hi,

Just find out this thread. My question is. If companies like Sipura already
makes SIP (which can work with *), why do they want to add support for IAX.
After all, that's extra resource they have to spend to get that done. I have
no doubt what you guys talking will work; but does adding IAX support makes
business sense for them?

-----Original Message-----
From: Steve Kann [mailto:stevek at stevek.com]
Sent: Wednesday, April 06, 2005 9:49 AM
To: Asterisk Developers Mailing List
Subject: Re: [Asterisk-Dev] Petition for IAX firmware


Paul wrote:

> Steve Kann wrote:
>
>>
>> On Apr 5, 2005, at 10:49 PM, Paul wrote:
>>
>>> denon wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've put together a quick petition, in hopes that we can possibly 
>>>> persuade Sipura (or any other large-scale IP handset manufacturer) 
>>>> to include firmware support for IAX. The IAXy has proven that an 
>>>> IAX product is in demand, and very useful, and I think we'd all 
>>>> like to see a handset manufacturer follow Digium's lead. I'm not 
>>>> particularly endorsing Sipura, however I do know that they have 
>>>> seriously considered support for IAX, and have decided to hold off 
>>>> until "the demand is there". I'm hoping that with some numbers, we 
>>>> can prove to them that the demand is already here, and that IAX is 
>>>> already a viable technology.
>>>>
>>>> I'd like to encourage everyone to show your support -- hopefully 
>>>> Sipura, and/or other manufacturers will see these hard names and 
>>>> numbers, and realize it's time to move something into production.
>>>>
>>>> Petition:
>>>> http://www.petitiononline.com/IAXPhone
>>>>
>>>> Thanks,
>>>>
>>>> -d
>>>
>>>
>>>
>>> I like to see IAX support in any phone or ata. As for the benefits 
>>> of IAX trunking: Suppose that you have 4 SPA-2000 devices at a 
>>> branch office with IAX trunking back to headquarters? You won't be 
>>> getting the best bandwidth usage unless you also run a * server at 
>>> the branch office to aggregate those 8 extensions into one trunk. 
>>> Otherwise you have 4 trunks to the * server at headquarters. With 8 
>>> IP phones it's even worse.
>>>
>>> So it looks like I need to have a linux box running at each location 
>>> where I want to use IAX trunking. I'm sure I can get the cost of 
>>> that down to something reasonable. I guess the next question is: It 
>>> is much easier to do IAX trunking if all the ata's and IP phones use 
>>> IAX2 instead of SIP? A good example would be 8 IAXy devices as 
>>> compared to 4 2-port SIP ata's. Is the configuration going ot be 
>>> easier? How about performance and stability?
>>>
>>> Rather than petition Sipura, I would prefer that we convince Digium 
>>> to go further with the IAXy concept. Give us a base unit that 
>>> accepts a mix of fxo or fxs modules. Offer it in 2, 4 and 8 port 
>>> versions. If those 3 sizes will do trunking and offer the best free 
>>> codecs, it will eliminate the need for a * server to do trunking at 
>>> a lot of locations. Digium should do it first and let the others 
>>> play catch-up when they finally see the light.
>>>
>>
>> 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
>
>
> There are a few linux-compatible boards being used right now for 
> applications such as wireless ISP's. A trunk-aggregator should not do 
> any transcoding. That would be handled by the * server at the other 
> end of the trunk(if needed). The dial plan is also handled by the 
> "master server". And so on and so on. That means maybe we can do it 
> with a fanless pentium-compatible board that boots from a compact 
> flash card. I have seen fanless products ranging from 133 to 800 mhz 
> cpu speed.


You probably don't even need that.   If you code it well, you can easily 
do a whole lot of channels of this kind of thing on a gumstix 
(www.gumstix.com), or even a less powerful chip.

>
> 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? 

Computational requirements won't change much, but the code you'll need 
will be a lot larger.

You can probably write (from scratch), a 500-1000 line C program which 
can aggregate single IAX2 calls from multiple sources into trunks to 
particular destinations.  A version which handled SIP as well would need 
to be several times that much code.

> 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?


It shouldn't, unless there's bugs :)

-SteveK



_______________________________________________
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20050406/2677a681/attachment.htm


More information about the asterisk-dev mailing list