[asterisk-dev] Potential change to outgoing codec offers (new topic)

[Kevin P. Fleming]

Brian Candler wrote:

> (However, I have no idea what these devices would do if you completed the
> call, and then they had to use the 'WIBBLE' codec to send audio...)

I don't think that my proposal is practical; instead, what I am going to
do is to modify the channel drivers to not offer formats (audio or video
codecs) which either don't match the incoming channel's format, or are
not transcodable to that format. The translation core already has all
the information needed to do this.

While this won't have the complete effect you wanted (forcing the 'B'
endpoint to only select the no-transcode-needed format), it will be
close, given that we put the no-transcode-needed format at the top of
that list in the SDP. If the 'B' endpoint chooses another format which
requires transcoding in spite of our stated preference, there's no
simple way for us to deal with it.

These changes will at least keep Asterisk from offering codecs it cannot
use to complete the call setup; in combination with a modified version
of the G.729 codec binary, we will even be able to get Asterisk to stop
offering G.729 when the licenses are all in use (I think... haven't
tested it yet).