<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
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.&nbsp; For example some phones send:<br>
<br>
a=rtpmap:18 G729/8000/1<br>
<br>
instead of the usual:<br>
<br>
a=rtpmap:18 G729/8000<br>
<br>
in the SDP...<br>
<br>
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'.&nbsp;
'sip show channels' also shows the 'Form' as 'unkn' during a call.&nbsp;
This behaviour only appears to happen though when the encoding
parameter is included.&nbsp; According to RFC2327:<br>
<tt><br>
</tt>
<blockquote><tt>The general form of an rtpmap attribute is:</tt><br>
  <br>
  <tt>a=rtpmap:&lt;payload type&gt; &lt;encoding name&gt;/&lt;clock
rate&gt;[/&lt;encoding parameters&gt;]</tt><br>
  <br>
  <tt>For audio streams, &lt;encoding parameters&gt; may specify the
number of</tt><br>
  <tt>audio channels.&nbsp; This parameter may be omitted if the number of</tt><br>
  <tt>channels is one provided no additional parameters are needed.&nbsp; For</tt><br>
  <tt>video streams, no encoding parameters are currently specified.</tt><br>
</blockquote>
<br>
So, the encoding parameter part looks like an optional but perfectly
valid part of the rtpmap SDP definition.<br>
<br>
Interestingly calls often seem to work fine out to the PSTN etc. but
Asterisk has problems transcoding between 2 local clients.&nbsp; Has anybody
seen this behaviour in Asterisk 1.4?&nbsp; Is this a bug or a feature that I
haven't setup in Asterisk I am yet to discover?<br>
<br>
Cheers,<br>
Ray<br>
</body>
</html>