[Asterisk-Dev] IAX2 protocol question

[Tim Robbins]

Steve Kann wrote:

> Tim Robbins wrote:
>
>> Matt Riddell wrote:
>>
>>> Tim Robbins wrote:
>>>
>>>>  From reading the Asterisk sources, it looks as if the FORMAT 
>>>> information element, when sent as part of an ACCEPT frame, lets the 
>>>> calling IAX endpoint know which formats are supported by both 
>>>> parties. However, libiax2 (and therefore the majority of IAX 
>>>> softphones) does not send a FORMAT IE as part of the ACCEPT. In 
>>>> this situation, what is the "right" way to determine which format 
>>>> voice frames should be sent in?
>>>>
>>>> Thanks for any suggestions.
>>>
>>>
>>>
>>>
>>> The iaxclient libraries have just recently had multiple codecs 
>>> added. You might want to check that you have the latest version.
>>
>>
>>
>> I was actually more interested in how codec negotiation is supposed 
>> to work in the IAX2 protocol itself (and specifically, what an 
>> endpoint should do if the ACCEPT frame is missing a FORMAT IE), not 
>> any particular implementation.
>
>
> That's a good question.  Here's what I just wrote to iaxclient-devel:
>
>
> 1) The caller sends both format and capabilities when it makes a new 
> call.
> 2) The remote side chooses a format, based on it's own capabilities, 
> preferences, and the caller's capabilities and preferences.
> 3) The remote side ACCEPTs the call, and sends back the format to use.
>
> So, this is what I implemented in iaxclient and libiax2.
>
> In step2, asterisk seems to do this:
>
> 1) Use the caller's preferred format, if it supports it,
> 2) Choose amongst all capabilities, using a hard-coded order of 
> preference.
>
> In step2, in iaxclient, I implemented it as:
> 1) Use the caller's preferred format, if we support it,
> 2) Use _our_ preferred format, if they support it,
> 3) Finally, look at the union of capabilities, and (the same) 
> hard-coded order.

(Apologies for the late response.)

I've looked over the changes you committed to iaxclient CVS, and I'm 
glad to see that there will be many fewer broken IAX clients around that 
send ACCEPT without a FORMAT IE! :-)

However, I suspect there will be interoperability problems with older 
(broken) clients, which is the problem I was trying to solve when I 
posted my original message to the list. At the moment, iaxclient (as of 
iax.c rev. 1.27) will reject ACCEPT w/o FORMAT with "Unable to negotiate 
codec". I came up with three possible solutions:
- hold off sending voice frames until we receive one, then encode frames 
using whatever format we receive
- assume GSM
- reject the call

It would be nice if there was a consensus among IAX implementors on how 
to handle this or some kind of semi-official decision.


Tim