Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4453/#review14697 --- Ship it! I think this addresses the complexity that would be involved if we tackle this task, and outlines the necessary steps to get started. - 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 -- _ -- 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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4453/ --- (Updated March 16, 2015, 5:40 p.m.) Status -- This change has been marked as submitted. 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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4453/#review14599 --- 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. - 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:
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
On March 2, 2015, 6:27 p.m., Matt Jordan wrote:
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 :-)
{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?
{quote}
Keep in mind from the description on this review that the task list details a
list of high-level tasks that would need to be performed *if a new RTP engine
were to be written* (emphasis mine). The task list serves two details
1) Put in perspective the amount of work required to write a new RTP engine so
we can decide if it's worth the time investment
2) If we do decide it's worth the time investment, this provides a blueprint
for getting it done
Based on feedback I've been receiving so far, my current opinion is that a
refactor is a better idea than a rewrite. Essentially refactor the current RTP
engine to work in a more layered approach, possibly associate streams together
in a session, and be done with it. Most of the other improvements discussed
could (and should) be made at a different layer than the RTP layer (such as
synchronization of related streams). The risk and time associated with a
rewrite outweigh the benefits, in my opinion.
- Mark
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4453/#review14569
---
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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4453/#review14566
---
Review of https://wiki.asterisk.org/wiki/display/AST/RTP+engine+replacement
-- Section: A glossary of terms
{quote}
* RTP stream: RTP instances created by Steel Zebra will be referred to as RTP
streams.
* RTP session: A structure created by Steel Zebra that contains related RTP
streams and coordinates activities between streams where necessary.
{quote}
Since RTP instances are created separately by a channel driver, how will the
RTP engine be notified that multiple RTP instances (that is, streams) are
related? This may be answered in another section, but it might be good to know
that this will require changes in the RTP engine here.
-- Section: Media Flow: Incoming Media
{quote}
Buffering/reordering
RTP may be received in bursts, out of order, or in other less-than-ideal ways.
Asterisk will implement reception buffers to place incoming RTP traffic into,
potentially reordering packets as necessary if they arrive out of order.
{quote}
While I'm not against buffering in the RTP stack, have you given any thought
how that would be set up? As it adds delay, I would expect that not every RTP
stream should be buffered; consequently, this would need to be driven by
configuration or by some dialplan construct. Configuration may work in some
cases (for example, when you know that some endpoint is always jittery); in
other cases, dialplan is probably a better approach. In both cases however,
these would require manipulation at a layer higher than the RTP stack itself,
which would mean drilling down through the RTP engine into the RTP instance -
which ends up sound something like our current jitter buffer approaches. What
advantages are there to buffering in the stack itself, versus simply expanding
the jitter buffers to handle more than just VOICE frames? Would we want to
provide buffering in native RTP bridges, or let the far endpoints handle the
re-ordering?
-- Section: Other Stuff
{quote}
Native local RTP bridges
Native local RTP bridges have a few considerations when implementing a new RTP
engine.
First, bridge_native_rtp requires that the RTP engine's local_bridge method has
to be the same for each of the bridged RTP instances. If we create a new RTP
engine, it will not have the same local_bridge method as res_rtp_asterisk. This
means that calls that use res_rtp_asterisk will not be able to be locally
bridged with calls that use the new RTP engine. I think it is possible to
rework the inner workings of native local bridges such that they can be between
different RTP engines. However, if the goal is the total removal of
res_rtp_asterisk from the codebase, then such considerations are not as
necessary.
Second, native local RTP bridging is performed at the main RTP API layer by
having the bridged RTP instances point at each other. It is up to the
individual RTP instances to detect that this has occurred and act accordingly.
It might work better if the job of setting bridges on RTP instances were passed
down to the engines themselves in case they want to perform other side effects
besides changing a pointer.
{quote}
I think it is arguable whether or not the local_bridge code should be in
res_rtp_asterisk still. Ideally, an RTP implementation would simply have a
direct write/direct read callbacks that the bridge itself would call into,
rather than let the RTP implementation do the actual bridging. This has a few
advantages:
(1) We could implement some other more interesting RTP bridges (such as a
multi-party RTP forwarding bridge or a RTP bridge w/ RTP recording)
(2) It simplifies the thread boundaries. Right now, it's a little tricky
managing the safety of calling into an RTP implementation from
bridge_native_rtp. Having a more concrete boundary between the bridge and the
RTP implementations would be advantageous.
Of course, if res_rtp_asterisk is refactored as opposed to replaced, that makes
altering and/or supporting the native bridging in any fashion easier.
I think you might be referring to this in your second point, but I'm not
entirely sure if this is what you meant in it.
- 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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
On 02 Mar 2015, at 16:54, Matt Jordan reviewbo...@asterisk.org wrote:
{quote}
Buffering/reordering
RTP may be received in bursts, out of order, or in other less-than-ideal
ways. Asterisk will implement reception buffers to place incoming RTP traffic
into, potentially reordering packets as necessary if they arrive out of order.
{quote}
By default, asterisk should forward RTP packets without any buffer, without
reordering or doing anything. Today Asterisk renumbers packets - thus hiding
packet loss and reordering. This is bad.
Forwarding with packet loss and reordering is quite ok as default. The endpoint
in the call will sort it up with a jitter buffer.
In some cases Asterisk is the endpoint of the RTP stream (IVR, protocol
conversion). In that case we can apply a buffer like any endpoint. But not by
default.
I guess cases with transcoding involved also requires a jitter buffer.
/O--
_
-- 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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements -session
Mark, One thing I think we have to look into is grouping of media sessions. You do not mention that, but you point to the bundle RFC. There are a few cases, like video conferences with left/right video and different options for audio - from high bandwidth to low bandwidth, lossy compression. Alternatives in the group and stuff that belongs together. Sorry for making your hair turn grey, but I think it's time. And this will of course go beyond RTP. /O -- _ -- 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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
On March 2, 2015, 3:54 p.m., Matt Jordan wrote:
Review of https://wiki.asterisk.org/wiki/display/AST/RTP+engine+replacement
-- Section: A glossary of terms
{quote}
* RTP stream: RTP instances created by Steel Zebra will be referred to as
RTP streams.
* RTP session: A structure created by Steel Zebra that contains related RTP
streams and coordinates activities between streams where necessary.
{quote}
Since RTP instances are created separately by a channel driver, how will
the RTP engine be notified that multiple RTP instances (that is, streams)
are related? This may be answered in another section, but it might be good
to know that this will require changes in the RTP engine here.
-- Section: Media Flow: Incoming Media
{quote}
Buffering/reordering
RTP may be received in bursts, out of order, or in other less-than-ideal
ways. Asterisk will implement reception buffers to place incoming RTP
traffic into, potentially reordering packets as necessary if they arrive
out of order.
{quote}
While I'm not against buffering in the RTP stack, have you given any
thought how that would be set up? As it adds delay, I would expect that not
every RTP stream should be buffered; consequently, this would need to be
driven by configuration or by some dialplan construct. Configuration may
work in some cases (for example, when you know that some endpoint is always
jittery); in other cases, dialplan is probably a better approach. In both
cases however, these would require manipulation at a layer higher than the
RTP stack itself, which would mean drilling down through the RTP engine
into the RTP instance - which ends up sound something like our current
jitter buffer approaches. What advantages are there to buffering in the
stack itself, versus simply expanding the jitter buffers to handle more
than just VOICE frames? Would we want to provide buffering in native RTP
bridges, or let the far endpoints handle the re-ordering?
-- Section: Other Stuff
{quote}
Native local RTP bridges
Native local RTP bridges have a few considerations when implementing a new
RTP engine.
First, bridge_native_rtp requires that the RTP engine's local_bridge method
has to be the same for each of the bridged RTP instances. If we create a
new RTP engine, it will not have the same local_bridge method as
res_rtp_asterisk. This means that calls that use res_rtp_asterisk will not
be able to be locally bridged with calls that use the new RTP engine. I
think it is possible to rework the inner workings of native local bridges
such that they can be between different RTP engines. However, if the goal
is the total removal of res_rtp_asterisk from the codebase, then such
considerations are not as necessary.
Second, native local RTP bridging is performed at the main RTP API layer by
having the bridged RTP instances point at each other. It is up to the
individual RTP instances to detect that this has occurred and act
accordingly. It might work better if the job of setting bridges on RTP
instances were passed down to the engines themselves in case they want to
perform other side effects besides changing a pointer.
{quote}
I think it is arguable whether or not the local_bridge code should be in
res_rtp_asterisk still. Ideally, an RTP implementation would simply have a
direct write/direct read callbacks that the bridge itself would call
into, rather than let the RTP implementation do the actual bridging. This
has a few advantages:
(1) We could implement some other more interesting RTP bridges (such as a
multi-party RTP forwarding bridge or a RTP bridge w/ RTP recording)
(2) It simplifies the thread boundaries. Right now, it's a little tricky
managing the safety of calling into an RTP implementation from
bridge_native_rtp. Having a more concrete boundary between the bridge and
the RTP implementations would be advantageous.
Of course, if res_rtp_asterisk is refactored as opposed to replaced, that
makes altering and/or supporting the native bridging in any fashion easier.
I think you might be referring to this in your second point, but I'm not
entirely sure if this is what you meant in it.
{quote}
Since RTP instances are created separately by a channel driver, how will the
RTP engine be notified that multiple RTP instances (that is, streams) are
related? This may be answered in another section, but it might be good to know
that this will require changes in the RTP engine here.
{quote}
This is addressed in the Media Setup section, subsection The actual Setup .
{{ast_rtp_instance_new()}} takes an engine-specific void pointer as the final
parameter. The new RTP engine will take a structure that contains the channel
that the RTP instance is being created for. This channel is used as a key to
determine if a session has been set up yet.
{quote}
Stuff
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
On 03/02/2015 10:22 AM, Olle E. Johansson wrote:
On 02 Mar 2015, at 16:54, Matt Jordan reviewbo...@asterisk.org
mailto:reviewbo...@asterisk.org wrote:
{quote}
Buffering/reordering
RTP may be received in bursts, out of order, or in other less-than-ideal ways.
Asterisk will implement reception buffers to place incoming RTP traffic into,
potentially reordering packets as necessary if they arrive out of order.
{quote}
By default, asterisk should forward RTP packets without any buffer,
without reordering or doing anything. Today Asterisk renumbers packets
- thus hiding packet loss and reordering. This is bad.
Forwarding with packet loss and reordering is quite ok as default. The
endpoint in the call will sort it up with a jitter buffer.
In some cases Asterisk is the endpoint of the RTP stream (IVR,
protocol conversion). In that case we can apply a buffer like any
endpoint. But not by default.
I guess cases with transcoding involved also requires a jitter buffer.
/O
After reading this response and thinking about it for a while, I think
you're 100% correct here. In fact, I think the best course of action is
not to perform buffering or reordering at the RTP layer under any
circumstances. Instead, the application can be responsible for deciding
what is appropriate. When I say application here, I don't mean the
dialplan application Asterisk is running, but a high-level description
of what is happening, media-wise.
So for instance, if a native local RTP bridge is being used, then RTP
comes in one side and is directly sent out the other side. We can make
the assumption that the RTP-capable endpoints will perform their own
buffering, re-ordering, and synchronizing. We just need to make sure
that we provide proper timestamps so that a receiver can accurately
reconstruct the stream.
If other types of bridges are being used, then it is dependent on the
channel technology and the number of parties in the bridge whether we
want to buffer/synchronize. And if we do want to perform buffering or
synchronization of streams, that should be taken care of at the channel
or bridge level, not at the RTP level.
For IVRs or call recording, then like you mentioned,
buffering/synchronizing is always a good idea. But again, this doesn't
need to happen at the RTP layer.
My plan here is to remove the language about buffering and
synchronization from the RTP layer. Does anyone object to this?
--
_
-- 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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4453/#review14568
---
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?
- 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
Re: [asterisk-dev] [Code Review] 4453: Asterisk 14: RTP improvements
---
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
