[Asterisk-Dev] Petition for IAX firmware
Paul
digium-list at 9ux.com
Wed Apr 6 10:02:43 MST 2005
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.
More information about the asterisk-dev
mailing list