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

[Brian Candler]

On Wed, Oct 18, 2006 at 12:25:06PM -0500, Kevin P. Fleming wrote:
> It's pretty late in the game to make a change like this for Asterisk 1.4,
> but I suspect given the number of people that experience this problem
> every day it's likely the community would be happy if we did it.
> 
> Thoughts?

Personally I don't mind either way - I don't use asterisk in production
(yet), just as a convenient VoIP test platform.

But if bug #8152 applies to 1.4 as well as trunk, which I expect it does,
then I guess you have either got to push forward with a new codec
negotiation strategy, or roll back to the 1.2 behaviour for now and do this
in trunk/1.6.

For this new strategy I think you'll want wide test coverage across a range
of phones and ATAs. Doing it in a beta will give you this, but may
disappoint a lot of people if it turns out to be problematic.

A more cautious approach for 1.4 might be:
- put back the 1.2 behaviour (i.e. two leg setup followed by re-INVITE)
- also implement the enhanced behaviour as discussed
- make the 1.2 behaviour the default, but have an option to turn on the
  enhanced behaviour for those who want to try it.

I think that gives you the best of both worlds, and the enhanced behaviour
can be made default in 1.6 if it works well.

As well as this option, I think there should be a way to set for each peer
the error code(s) which it may generate on codec mismatch, e.g.

  codecreject=606,403   ; when sending an INVITE to this peer offering only
                        ; a subset of codecs, these error codes can be
                        ; interpreted as codec mismatch and should cause a
                        ; second INVITE with RTP forced via Asterisk

Then if you come across a phone which generates (say) 488, you can easily
accommodate it.

I guess you could make this the on/off switch too; e.g. codecreject=no means
use the 1.2 behaviour when placing a call to this endpoint.

Or maybe there's an opportunity to change the 'canreinvite' option into
something more meaningful: e.g. nativebridge=no|reinvite|immediate ?

Regards,

Brian.