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

[Matt Jordan]

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


Review: https://wiki.asterisk.org/wiki/display/AST/RTP+task+list

I think it is worth putting somewhere on the task list the notion of testing RTP independent of a channel driver. That is, I'd like to be able to pass RTP packets into Asterisk, have them echo'd back to me (or otherwise transformed and sent back to something that can receive RTP), and not have to go through the SIP/PJSIP/Motif/etc. layers.

This could be a simple extension to chan_rtp, or it could be signalling set up through ARI. The goal should be to let the Asterisk Test Suite inject RTP into Asterisk and verify that things behave appropriately.

It may be worthwhile writing a tool that does this completely as a separate project outside of the Asterisk Test Suite (ala SIPp - RTPp?) to make it easier for others to contribute to. Either way, I think being able to write a lot of tests that exercise the new RTP implementation will be key to getting this work done.

-- Section: Bare-Bones calls

{quote}
The first milestone will be to get the RTP engine written to the point that we can successfully pass media through Asterisk. This means successfully constructing the media flows as described in the parent page and putting some basic setup in place. For this phase, it is encouraged to use hard-coding in place of pluggable elements. The sooner we can get to a point where we have successful calls, the easier it is to rapidly develop new features (and tests!) with confidence that they work as intended.
{quote}

I think we're assuming here that we are writing something from scratch. After reading through your state of the world and the state of current RFCs, how do you feel about refactoring res_rtp_asterisk?

If we went with that approach, the first task may be:
(1) Write tests that exercise the current implementation with basic capabilities
(2) Refactor res_rtp_asterisk into different units (modules and/or separate files)
(3) Prove out the validity of the threading model, using the tests to exercise both functionality as well as the performance impact

I'm not sure on the correct way to go here - and I'd expect that most of the RTP/RTCP code to get heavily re-worked/re-written - but given that res_rtp_asterisk is substantially smaller than our other "legacy" modules, it may be possible to simply refactor it as opposed to re-writing the whole thing from scratch.

-- Section: Destruction

{quote}
Once a call is hung up, we need to be able to clean up the RTP
{quote}

This is missing the end of its phrase :-)



- Matt Jordan


On Feb. 27, 2015, 12: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, 12: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/20150302/508a2c82/attachment-0001.html>