[asterisk-dev] New codec support in Asterisk 10

[Tilghman Lesher]

On Fri, Oct 14, 2011 at 1:35 PM, Kevin P. Fleming <kpfleming at digium.com> wrote:
> On 10/14/2011 01:10 PM, Tilghman Lesher wrote:
>>
>> On Fri, Oct 14, 2011 at 12:28 PM, Simon Perreault
>> <simon.perreault at viagenie.ca>  wrote:
>>>
>>> On 2011-10-14 13:15, Tilghman Lesher wrote:
>>>>
>>>> On Fri, Oct 14, 2011 at 11:53 AM, Jason Parker<jparker at digium.com>
>>>>  wrote:
>>>>>
>>>>> In Asterisk 10, we've changed the way codecs are defined, to expand the
>>>>> number
>>>>> of codecs that we can support.  However, due to protocol limitations,
>>>>> many
>>>>> channel drivers (pretty much everything but chan_sip) can only support
>>>>> a limited
>>>>> number of codecs.  As an example, chan_iax2 uses a 32-bit bitfield on
>>>>> the wire,
>>>>> which means the codec list on each side can never change.
>>>>
>>>> One small correction:  chan_iax2 uses a 64-bit bitfield on the wire,
>>>> with approximately
>>>> 30 of those bits unallocated.  (Testlaw can be removed; it's just a
>>>> duplicate of ulaw.)
>>>
>>> (just trolling a little bit)
>>>
>>> So chan_iax2 doesn't follow the RFC?
>>>
>>>   While IAX is very effective, addressing many of today's
>>>   communications needs, it does have a few limitations.  For instance,
>>>   IAX uses a point-to-point codec negotiation mechanism that limits
>>>   extensibility because every IAX node in a call path must support
>>>   every used codec to some degree.  In addition, the codec definition
>>>   is controlled by an internally defined 32-bit mask, so the codecs
>>>   must be defined in the protocol, and the maximum number of
>>>   simultaneous codecs is, therefore, limited.
>>>
>>> http://tools.ietf.org/html/rfc5456#section-1.2
>>
>> For interoperability reasons, chan_iax2 actually sends both a 32-bit
>> codec mask AND a 64-bit codec mask.  So in answer to your question,
>> yes, it's backwards-compatible.
>
> ... but no document has been produced to document this information element
> (nor for the other information elements we've already added since the RFC
> was published).

I'm not opposed to creating such a document, but the question is,
where should this information be published, and if it's formal, such
as the IETF RFC forum, should it wait until IAX2 can handle an
effectively unlimited number of codecs?