[asterisk-dev] Asterisk 13: Media improvements update

[Matthew Jordan]

On Mon, Feb 24, 2014 at 4:57 AM, Olle E. Johansson <oej at edvina.net> wrote:
> Adding to the mix:
>
> I would like to se us being able to switch codecs on the fly based on RTCP input.
>

I agree, this would be very cool. The good news is this is already
very close to being possible. Here's what's currently available for
that:

(1) Stasis messages for RTCP that are tied to specific channels. A
module can subscribe for said messages and handle the ones that
pertain to send/receiver reports. There's actually a module I just
wrote that does this for HEP - although it isn't up for code review
yet, you can see it in a team branch here:
http://svn.asterisk.org/svn/asterisk/team/mjordan/12-hep/res/res_hep_rtcp.c

(2) APIs in the PJSIP stack to initiate an INVITE request on demand.
Once you've set the formats to use (and I'll get to that in a bit),
you would call ast_sip_session_refresh to send a re-INVITE. You can
find the documentation for this function in res_pjsip_session.h.

So, today, it is possible to write a module that listens for RTCP
statistics from all channels and, on the fly, initiates a
re-INVITE/UPDATE request to the endpoints associated with a channel if
it feels like it. The function I proposed in my previous e-mail that
would set the allowed formats on a channel and then issue a
re-INVITE/UPDATE request to change them would use option (2) to
construct that - the actual dialplan function would be a thin wrapper
over that.

There's a few things to consider:

(1) Currently, the formats that are added to the SDP in an outbound
request are based on the formats configured on the endpoint. Endpoints
are treated as being immutable - if you want to change the endpoint,
you have to update it via sorcery, not just change in the in memory
representation of it (otherwise you're out of sync with the backing
storage!) In this particular case, you don't really want to do that -
you're adapting to changing network conditions, not changing what is
technically allowed by the thing you are talking to. There's two ways
of handling this:
  (a) Cache the allowed formats on the endpoint somewhere else that is
mutable (such as the ast_sip_session object itself), and use that in
res_pjsip_sdp_rtp when adding the formats to the outbound SDP. This is
what would be modified by the module when it sees that it wants to
change the formats being used.
  (b) Don't change them! ast_sip_session_refresh lets you provide a
callback handler that will be called when the SDP is constructed and
added to the request, but before that request is sent out. That lets
you modify the SDP on the fly, so that you only request the formats
that you want.
  Both approaches have some pros/cons, but both would work in terms of
offering only what media formats you want.

  Note: part of the work I outlined in my e-mail would have to do this
as well. Currently, I'm leaning towards option (1a), as I want the
change to affect the entire lifetime of the channel, and option (1b)
is much more suited for manipulating the SDP when you know it will
return back to its original state at some point. For example,
res_pjsip_t38 uses it to switch to an image media stream only when it
needs to negotiate to T.38.

(2) I think it's worth thinking about how such a module would be
written to be flexible enough for everyone's business needs. What
kinds of things should it watch for, and with what tolerances? Does it
defer any part of its processing to an external source? For example,
instead of actually making the decision itself to switch to a lower
bandwidth codec, it could raise an AMI event that says "hey, this
channel looks like its dropping a lot of packets". It could register a
new AMI action ("ChangeTheCodecs") that would allow an external source
to initiate the change.

(3) Technically, you could defer all of the logic outside of Asterisk.
An AMI client can listen for RTCP statistics today and determine if a
channel (since they're now associated with the RTCP information) is
having packet loss issues due to some factor that could be alleviated
by switching to a lower bandwidth codec. Once the previously mentioned
dialplan function is written that lets someone switch the formats
being used on a channel to a different set of formats, they can then
issue an AMI action "Set" to change the formats and issue a new
re-INVITE/UPDATE request.

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