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
_______________________________________________
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
