On Mon, Feb 24, 2014 at 4:57 AM, Olle E. Johansson <[email protected]> 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 -- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
