[asterisk-dev] Asterisk 13: Media improvements update

[Matthew Jordan]

Hey everyone -

As Josh pointed out awhile back [1], he's been working hard on making
improvements to Asterisk's handling of media to get some better
performance in Asterisk 12/13. As he's been going along, he's been
documenting the API changes and its effects on a project planning page
on the Asterisk wiki [2]. Recently, I updated the page with some media
use cases from a PJSIP negotiation perspective. Some of these use
cases require some thought on how the channel driver should behave
when negotiating media; hence, this e-mail!

Today, in chan_sip, format negotiation follows a set of rules that
aggressively attempts to minimize the chances of transcoding. The best
documentation for these rules is from chan_sip itself:

{quote}
/* add_sdp: */

/* Now, start adding audio codecs. These are added in this order:
   - First what was requested by the calling channel
   - Then preferences in order from sip.conf device config for this peer/user
   - Then other codecs in capabilities, including video
*/
{quote}

This approach has some benefits, but also has some limitations that
have become evident over the years:
1. There are times when you want to enforce transcoding. For example,
you may want to force a low bandwidth codec to be used, even when that
isn't the preferred codec offered by a UA.
2. There are times when you don't want the preferred codec to be used
by the UA. The system administrator who set up Asterisk may have a
better handle on what codecs should be used then the endpoints
connecting to their system.

Note that there are other limitations here as well, namely with how
Asterisk treats audio/video - but some of those are more a facet of
the core, and less of the mechanics of negotiation. For now, I'm
trying to hit the negotiation aspects.

For chan_pjsip, we already have started down the path of being a bit
different. If I can sum up the guidelines for format negotiation, it
would be:
1. Trust the endpoint configuration, and do what it says. If that
leads to transcoding, defer to run-time behaviour to prevent that.
2. Let the dialplan (or whatever API is being used to create the
channels) override the behaviour at run-time.

What that results in is the following set of rules:

1. For an inbound channel with a set of format capabilities, Asterisk
should respond to that set of formats with the intersection of the
offered capabilities and what is configured for the endpoint for that
channel. The format preference order should be based on the
configuration of the endpoint.

1a) If the system should accept a different set of formats, a dialplan
function can be used to set which formats (and their preference order)
are accepted on the channel at run-time. To configure the formats
negotiated with an inbound channel, the function would set the formats
on the channel prior to being answered. If being done from the Dial
application, this can be achieved via the MASTER_CHANNEL function and
the U/M options. If this occurs after the channel has been answered,
see (4).

1b) If the system would like to restrict the device to a single
format, a dialplan function or configuration option can be set so that
Asterisk will only ever respond with the preferred format.

2. For an outbound channel, Asterisk should offer the formats that
have been configured for that endpoint, with the format preference
order based on the configuration of that channel's endpoint.

2a) If the system should offer a different set of formats, a dialplan
function can be used to set which formats should be offered via a
pre-dial handler.

2b) If the system would like to restrict the outbound channel such
that it only has a single format, a dialplan function or configuration
option can be used such that Asterisk only offers a single format.

3) Prior to entering a bridge, a dialplan function can be used to set
whether a channel will attempt to make itself compatible with whatever
it is in the bridge with it. If set to do so, then, when a channel
enters a bridge with another channel that has a format it supports, it
will attempt to switch the channel to the bridged channel's format to
facilitate native bridging. This would trigger a re-INVITE, and open
successful negotiation of the re-INVITE, the bridge would switch to a
native bridge. If not configured to do so, the channel will by default
transcode. Note that this has no bearing in multi-party bridges, where
everyone is transcoded.

4) At any point in time, a dialplan function can be used to set the
allowed set of formats on the channel, with whatever ordering. This
will cause the channel to re-negotiate to the set of formats specified
by the function. Note that the negotiation can fail, but a user has
the ability at any time to change the formats to something else.

We've started down the path of writing tests for this functionality,
but there's a lot of work to do - in particular, the previously
mentioned functions and dialplan options don't exist yet! Some help
with that implementation, as well as testing out the format
negotiation, would be hugely appreciated. But before we get too far,
if there's any thoughts, opinions, flames, or otherwise on these
rules, I'd love to get some feedback now before we start writing too
much code.

[1] http://lists.digium.com/pipermail/asterisk-dev/2014-January/064463.html
[2] https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite

Thanks!

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org