[Asterisk-Dev] Petition for IAX firmware

[Greg Hill]

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