[Asterisk-Dev] IAX2 Spec?

[Michael Giagnocavo]

SteveK: Yep. Figuring it out via source, etc. etc. -- I'm guessing that's
why a lot of people can't or haven't implemented IAX2 firmware. I know from
just trying to add transfers... it's a PITA.

Well, it sounds like we have a good start. I'll compile more information
that I can gleam from the IAX source, but someone else who actually
understands things in depth has to help out too :)...

-Michael

-----Original Message-----
From: asterisk-dev-bounces at lists.digium.com
[mailto:asterisk-dev-bounces at lists.digium.com] On Behalf Of Steve Kann
Sent: Friday, April 08, 2005 4:25 PM
To: Asterisk Developers Mailing List
Subject: Re: [Asterisk-Dev] IAX2 Spec?

Derek Smithies wrote:

>Hi,
>
>  
>
>>Michael Giagnocavo wrote:
>>
>>    
>>
>>>I've been working on improving the IAX2 firmware for the PA168. It's no
fun
>>>working from Ethereal and reverse engineering Asterisk :). 
>>>      
>>>
>yup,
> it is no fun working from ethereal and reverse engineering Asterisk to 
>see how iax2 works.
>Ethereal 0.10.10 has been released, and does a reasonable job of decoding 
>iax2 packets. Earlier versions of ethereal would crash when attempting to 
>decode some packets. 
>The code is, well, not 100% clear.
>
>  
>
>>http://voip.cornfed.com/index.php?p=7
>>
>>There's a PDF of an RFC here.
>>    
>>
>yes - it is a great start.
>However, missing bits of information are:
>  
>

You'll also find that things change, as we've added elements recently.

>Description of the 52 (or is it more) Information Elements
>  
>
That would be nice, but they are described in iax2.h

>Description of which IEs are used in which full frame packets
>Description of what iseqno/oseqno and timestamp are used in ack frames
>  
>
This describes what full frame sequence number you're acknowledging.

>Description of the finer points of full frames. Like lagrq and lagrp 
>frames. Resends of lagrq and lagrp is not allowed - as this makes the 
>calculation of the roundtrip time a bit difficult.
>  
>
The LAGRQ and LAGRP stuff is really broken, and should go away; if 
there's a time skew between the two endpoints, it gives nonsensical 
results to calculate "LAG" this way. That's why I added the "netstats" IEs.

>Description of the trunking mechanism
>Description of the encryption mechanism
>
>other than those few things, the document is a good start.
>  
>

The things you mentioned aren't the most complicated and can be 
documented easily, or figured out from the source. What's more 
difficult, though, is some of the details about the state models that 
each side is required to keep, i.e. keeping track of the 32 bit full 
timestamp based on the 16 bit timestamps, handling transfers, 
discontinuous audio transmission, and stuff like that.

It's fun, especially when the receive side is mostly implemented in one 
1300 line function (socket_read()) :)

-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