[Asterisk-Dev] removing limitation of ast_channel::nativeformats to one codec (with patch)

[Kevin P. Fleming]

Valentin Nechayev wrote:

> I've read #3346 and it seems to be rather orthogonal to the idea I showed.
> #3346 focuses on having one preferred codec and keeping current situation
> that codecs of both directions have to be the same (I saw
> preferred_codec_rev2.diff.txt in the ticket; at least for chan_sip.c it keeps
> the problem). Our requirement is to allow work in situation when codecs on
> input and output can be different.

That is true, but the whole point of that patch is to allow the user 
(via the dialplan) to affect the 'preferred codec' decision for outbound 
calls, and also to allow chan->nativeformats to go back to holding all 
formats that the peer supports, not just the currently selected one. 
That part is not in the patch at this point, but it's the next step that 
Mark and I have discussed doing.

Once that is done, then the ast_make_compatible() function can do a 
better job of choosing codecs for a bridge, including possibly even 
re-negotiating the codecs that were already chosen.

Also keep in mind that your patch allows chan_sip to tell an application 
it can send media in a different format than was negotiated, but this is 
not always safe to do without doing a re-invite first to make that "the" 
codec. For example, if you have an SPA-2000 that negotiates a G.711-ulaw 
call with you (but supports G.729 and you remember that), you may not be 
able to send it G.729 without re-inviting to G.729 first, because it has 
only a single G.729 license and may not be able to handle the incoming 
packets.

Even though RTP and IAX2 support every single frame being in a different 
codec from the last one, that does not mean you can safely just send a 
different format to the peer than the you negotiated to use.