[Asterisk-Dev] IAX2 protocol question

Steve Kann stevek at stevek.com
Mon Oct 25 19:52:56 MST 2004


On Oct 25, 2004, at 10:20 PM, Tim Robbins wrote:

> 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.
>

Although I'm in charge of iaxclient, I'd have to say that the old 
behavior is broken.

You gave three choices:

> 1 hold off sending voice frames until we receive one, then encode 
> frames using whatever format we receive
> 2 assume GSM
> 3 reject the call

I'd add a fourth:

4) Assume the other end accepted our preferred codec.

We used to do (2).  We're presently doing (3) you say (I haven't 
checked, but I don't see why you'd lie :)).

(2) is definately wrong.
(3) is probably the correct thing to do, because the other end violated 
the (undocumented) protocol.

(1) or (4) might be things one could do to manage to work with older, 
broken clients.  But, if it's only iaxclient that was broken in the 
first place, I'd just keep doing (3), since iaxclient to iaxclient 
calls aren't all that common (most of the time, people are going 
through asterisk anyway).

I don't have a strong opinion, but I'd ask on the iaxclient list too, 
in case anyone there does (although, I guess those guys all read this 
too).





More information about the asterisk-dev mailing list