[asterisk-dev] New codec support in Asterisk 10

[Tilghman Lesher]

On Fri, Oct 14, 2011 at 1:50 PM, Kevin P. Fleming <kpfleming at digium.com> wrote:
> On 10/14/2011 01:42 PM, Tilghman Lesher wrote:
>> On Fri, Oct 14, 2011 at 1:35 PM, Kevin P. Fleming wrote:
>>> On 10/14/2011 01:10 PM, Tilghman Lesher wrote:
>>>> On Fri, Oct 14, 2011 at 12:28 PM, Simon Perreault wrote:
>>>>> On 2011-10-14 13:15, Tilghman Lesher wrote:
>>>>>> On Fri, Oct 14, 2011 at 11:53 AM, Jason Parker 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?
>
> It should be written as an Internet-Draft, requesting that IANA register the
> information element(s) being used, with a complete description of their
> usage. Whether it gets pushed through the RFC process as an independent
> submission or not is a question we can ask later; it's not mandatory as the
> IANA registry in question only requires 'expert review' and a document
> published elsewhere can easily be reviewed by the expert (Cullen Jennings,
> in this case). It would obviously be easiest for all concerned, though, if
> the document was published as an Informational RFC.

The information elements in question appear to be already registered,
although their format and use are not:
http://www.iana.org/assignments/iax-parameters/iax-parameters.xml#iax-parameters-6

> Any future enhancement to the protocol allowing for more flexible codec
> negotiation would warrant its own document and information elements.

It's possible, given that the CAPABILITY2 and FORMAT2 IEs have a
version number, that additional IEs will not be necessary (just bump
the version number).

-Tilghman