[asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements

Thu Mar 5 08:43:11 CST 2015

> On March 2, 2015, 6:18 p.m., Matt Jordan wrote:
> > Review of https://wiki.asterisk.org/wiki/display/AST/Notes+on+RTP+standards
> > 
> > -- Section SRTP (RFC 3711)
> > 
> > {quote}
> > This document creates a new RTP profile, called RTP/SAVP. From section section 3:
> > {quote}
> > 
> > "section" repeated twice. The formatting of section 3 is also a little wonky.
> > 
> > -- Section RTP/AVPF (RFC 4585)
> > 
> > {quote}
> > In section 3.2, it outlines the rule changes from RFC 3550 with regards to RTCP transmission intervals. The minimum 5 second interval is not enforced and instead the bandwidth of the connection is used to determine the interval (though a minimum may still be optionally selected). Sending packets early is referred to, appropriately, as "early RTCP". Early RTCP follows its own rules about what types of RTCP packets can make up the compound RTCP packet. Honestly, it's a bit of a mess. The rules are:
> > 
> >     I decide I need to send a feedback packet, and I want to send it NOW, not at the next interval
> >     I wait a brief period to make sure no one else that noticed the event has already sent their own feedback packet.
> >     I have to check if early feedback is permitted.
> >     I can send an an early feedback packet if all the above are fulfilled.
> > 
> > So in order to send RTCP feedback, I modify timing with regards to sending RTCP, I can violate those timers and send early feedback, I have to insert small intervals in timing to allow for other feedback senders to send their feedback first, I have to determine permissiveness of sending early feedback.
> > 
> > Or I can just add feedback to my compound RTCP packets I'm already sending. I think I know how I'd implement this if given the choice...
> > {quote}
> > 
> > I think it's fine to just make a recommendation that we add feedback to the compound RTCP packets. That being said, the scheduling algorithms for this and other feedback mechanisms (such as NACK) are relatively difficult and may end up conflicting with each other. Have you thought about how scheduling different types of RTCP reports should be handled?

{quote}
Have you thought about how scheduling different types of RTCP reports should be handled?
{quote}

Assuming you're not talking about RTP/AVPF-specific RTCP here, the answer is sort of yes and no. Yes in the sense that since we have a scheduler as part of the architecture, we can regulate when we send RTCP packets out, to include taking bandwidth into account when determining the interval for packets. When it comes to which packets to include in each RTCP transmission, however, that is not specified since, to me that is more of an application-level detail rather than something that is fundamental to the architecture.

If you are talking about RTP/AVPF-specific RTCP, I agree with your recommendation of just sending RTCP feedback packets along with regularly-scheduled RTCP. Since most everything in the architecture is pluggable, the idea here would be that the RTCP sender gets told to send RTCP. The RTCP sender would put together its compound packet with SR/RR, SDES, etc. and would then call into any plugins that could add onto the RTCP packet currently being created. This would then go through the outflow stack and get sent out.

- Mark

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4453/#review14568
-----------------------------------------------------------

On Feb. 27, 2015, 6:47 p.m., Mark Michelson wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4453/
> -----------------------------------------------------------
> 
> (Updated Feb. 27, 2015, 6:47 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Description
> -------
> 
> I've created a series of wiki pages that discuss the idea of writing an improved RTP architecture in Asterisk 14.
> 
> To regurgitate some details from the linked page, the current RTP engine in Asterisk (res_rtp_asterisk) gets the job done but has some issues. It is not architected in a way that allows for easy insertion of new features. It has dead code (or code that might as well be dead). And it has some general flaws in it with regards to following rules defined by fundamental RFCs.
> 
> I have approached these wiki pages with the idea of writing a replacement for res_rtp_asterisk.c. The reason for this is that there are interesting media-related IETF drafts (trickle ICE and BUNDLE, to name two) that would be difficult to implement in the current res_rtp_asterisk.c code correctly. Taking the opportunity to re-engineer the underlying architecture into something more layered and extendable would help in this regard. The goal also is to not disturb the high-level RTP engine API wherever possible, meaning that channel drivers will not be touched at all by this set of changes.
> 
> The main page where this is discussed is here: https://wiki.asterisk.org/wiki/display/AST/RTP+engine+replacement . This page has a subpage that has my informal rambling notes regarding a sampling of RTP and media-related RFCs and drafts I read. It also has a subpage with more informal and rambling notes about the current state of RTP in Asterisk. While these pages are not really part of the review, you may want to read them anyway just so you might have some idea of where I'm coming from when drawing up the ideas behind a new architecture.
> 
> I also have a task list page that details a list of high-level tasks that would need to be performed if a new RTP engine were to be written: https://wiki.asterisk.org/wiki/display/AST/RTP+task+list . This should give some idea of the amount of work required to make a new RTP engine a reality. The tasks with (?) around them are tasks that add new features to Asterisk's RTP support, and it is therefore questionable whether they fit in the scope of this work at this time.
> 
> Some things to consider when reading through this:
> * Refactor or rewrite? When considering current issues with RTP/RTCP in Asterisk, and considering the types of features that are coming down the pipe, which of these options seems more prudent?
> * Does the proposed architecture make sense from a high level? Is there confusion about how certain areas are intended to work?
> * Are there any glaring details you can think of that have been left out?
> * Are there any questions about how specific features would fit into the described architecture?
> 
> 
> Diffs
> -----
> 
> 
> Diff: https://reviewboard.asterisk.org/r/4453/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20150305/259c8bd2/attachment-0001.html>