[Asterisk-Dev] IAX2 Spec?

[Steve Kann]

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