----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4453/#review14644 -----------------------------------------------------------
I've addressed the two items I mentioned in my last comment as follows: * On the main linked page, I have added a comment that while native RTP bridge improvements are a good idea, they don't necessarily need to be done as part of the RTP engine work. * I've created another page https://wiki.asterisk.org/wiki/display/AST/Testing+RTP . This talks about topics of RTP that should be tested and talks a bit about tools and Asterisk improvements that can be made in order to facilitate RTP testing. - Mark Michelson 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 > >
-- _____________________________________________________________________ -- 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
