[Asterisk-Dev] IAX Spec online

[Kenny Shumard]

> You may want to notate somewhere in this document that the protocol
> that you have labelled IAX is actually commonly known as IAX2.
> Otherwise, this is likely to be a source of confusion.

I think the idea is to *not* label the protocol as IAX2 after this. I
haven't heard a valid argument yet that it should still be called IAX2
when it is the only existing (?) IAX version.
> 
> In the table on pages 33-35, it would be helpful to include an
> argument octet size next to each IE type.  For example, IE 42
> (CAUSECODE) takes a single octet as an argument, while IE 21
> (CALLNO) takes two octets.  I realize the information is included
> in each of the descriptions, but as long as you're including a table,
> that summary information is most helpful.
> 
In one version I wrote, I included this. I decided not to include it
in the published version because it didn't seem to add that much --
most IEs have variable length, and very few require a certain size.
What are others' thoughts about this? Should the table include the
length in octets of the data length for each IE?

> IE 16 specifies an MD5 result without actually specifying what
> specific information, in what order, is to be hashed.  I mention
> this specifically because there is a criticism (in the Asterisk code
> itself) that the SIP spec does not include an example of what is to be
> hashed.

I'll look at the code and work on this.
> 
> It should be explicitly stated that for multi-byte encoded numbers,
> the format should be Network Order.
> 
Noted.

> Also, I believe that CAUSECODE _should_ be sent with any frame
> containing a CAUSE IE.  The CAUSE IE is good for spitting out error
> messages on the console and into logs, but CAUSECODE is far more
> useful programatically, considering it has a limited number of values,
> each of which are well-defined (and can be subsequently passed to
> other types of channels without translation).
> 
Mark's general philosophy is not to require anything unless the
absence of it will break something else. Because these IEs are
strictly informational, they're completely optional. We could require
CAUSECODE to be sent with CAUSE, but it doesn't break anything not to
so I didn't write it like that.

I think Mark is flexible on this pending support from the list. Does
anyone else have input on it?

~K