[Asterisk-Dev] Petition for IAX firmware

[Paul]

Greg Hill wrote:

> 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

So is there a consensus that the trunking-detrunking and SIP-IAX2 
"housekeeping chores" will not use much CPU? I have 66 and 100 mhz 486 
parts. I have one 75 mhz pentium and various K6, p2 and p3 up to 500 
mhz. So maybe I will make the first pass on a decent p4 workstation and 
then try migrating it downward until it breaks. In order to do that I 
will need a decent test setup. There is another whole project that could 
be based on asterisk. An asterisk server that just answers and makes 
test calls to generate a lot of work for the trunker-detrunker.

Since codec stands for coder-decoder maybe a trunker-detrunker should be 
called a trudet or a trundet.