<html>
<body>
<div style="font-family: Verdana, Arial, Helvetica, Sans-Serif;">
<table bgcolor="#f9f3c9" width="100%" cellpadding="8" style="border: 1px #c9c399 solid;">
<tr>
<td>
This is an automatically generated e-mail. To reply, visit:
<a href="https://reviewboard.asterisk.org/r/4453/">https://reviewboard.asterisk.org/r/4453/</a>
</td>
</tr>
</table>
<br />
<pre style="white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">I have made the following wiki changes based on feedback:
* Fixed grammar and formatting of SRTP section on RFC notes page
* Removed language about buffering/synchronization on RTP engine replacement page
* Added section at the end of RTP engine replacement with my current opinion about refactoring over rewriting
* Removed language about buffering/synchronization on RTP task list page, replacing it instead with an RTP packet handler
There are still some unaddressed action items:
* Native RTP bridging. Matt suggested a change to native RTP bridging code. As I pointed out before, I'm fine with the idea of improving how native RTP bridges work, but it does go beyond the original scope of the project. Since my current leaning for the RTP work is a refactor of res_rtp_asterisk rather than a writing a new RTP engine, I think there is a bit of wiggle room for expanding the scope, though.
* Testing. Frankly, I'm hesitant to write out testing ideas before the idea of what all is changing gets nailed down. If you had asked me about what I envisioned as a test plan prior to the original round of feedback, I would have told you that most tests would have been all about buffering, reordering, and synchronization of RTP streams. However, since that has been removed from the scope of the RTP engine, it means that the focus of testing has to be changed too. However, I do think I could take some action now in writing *how* testing could be performed without having to rely on channel drivers, etc. I just haven't done that yet.</pre>
<br />
<p>- Mark Michelson</p>
<br />
<p>On February 27th, 2015, 6:47 p.m. UTC, Mark Michelson wrote:</p>
<table bgcolor="#fefadf" width="100%" cellspacing="0" cellpadding="8" style="background-image: url('https://reviewboard.asterisk.org/static/rb/images/review_request_box_top_bg.ab6f3b1072c9.png'); background-position: left top; background-repeat: repeat-x; border: 1px black solid;">
<tr>
<td>
<div>Review request for Asterisk Developers.</div>
<div>By Mark Michelson.</div>
<p style="color: grey;"><i>Updated Feb. 27, 2015, 6:47 p.m.</i></p>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Description </h1>
<table width="100%" bgcolor="#ffffff" cellspacing="0" cellpadding="10" style="border: 1px solid #b8b5a0">
<tr>
<td>
<pre style="margin: 0; padding: 0; white-space: pre-wrap; white-space: -moz-pre-wrap; white-space: -pre-wrap; white-space: -o-pre-wrap; word-wrap: break-word;">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?</pre>
</td>
</tr>
</table>
<h1 style="color: #575012; font-size: 10pt; margin-top: 1.5em;">Diffs</b> </h1>
<ul style="margin-left: 3em; padding-left: 0;">
</ul>
<p><a href="https://reviewboard.asterisk.org/r/4453/diff/" style="margin-left: 3em;">View Diff</a></p>
</td>
</tr>
</table>
</div>
</body>
</html>