[asterisk-users] rtpmap encoding parameters & the 'unknown codec' problem?

[Ray Jackson]

We seem to have a problem with Asterisk 1.4 when a client sends through 
their SDP information but includes encoding parameters on the end of 
their SDP information.  For example some phones send:

a=rtpmap:18 G729/8000/1

instead of the usual:

a=rtpmap:18 G729/8000

in the SDP...

It seems that when the encoding parameter '/1' is included at the end of 
the rtpmap statement, Asterisk doesn't recognise the codec internally 
and then has trouble transcoding giving errors such as 'Unable to find a 
codec translation path from unknown to unknown'.  'sip show channels' 
also shows the 'Form' as 'unkn' during a call.  This behaviour only 
appears to happen though when the encoding parameter is included.  
According to RFC2327:

    The general form of an rtpmap attribute is:

    a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding
    parameters>]

    For audio streams, <encoding parameters> may specify the number of
    audio channels.  This parameter may be omitted if the number of
    channels is one provided no additional parameters are needed.  For
    video streams, no encoding parameters are currently specified.


So, the encoding parameter part looks like an optional but perfectly 
valid part of the rtpmap SDP definition.

Interestingly calls often seem to work fine out to the PSTN etc. but 
Asterisk has problems transcoding between 2 local clients.  Has anybody 
seen this behaviour in Asterisk 1.4?  Is this a bug or a feature that I 
haven't setup in Asterisk I am yet to discover?

Cheers,
Ray
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20070502/3fb2ff01/attachment.htm