[asterisk-dev] New codec support in Asterisk 10

Kevin P. Fleming kpfleming at digium.com
Fri Oct 14 13:50:08 CDT 2011


On 10/14/2011 01:42 PM, Tilghman Lesher wrote:
> 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?

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.

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

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: kfleming at digium.com | SIP: kpfleming at digium.com | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org



More information about the asterisk-dev mailing list