Summary: | ASTERISK-21333: Bridge API Enhancements - refactor all uses of a jitter buffer to use func_jitterbuffer | ||
Reporter: | Matt Jordan (mjordan) | Labels: | Asterisk12 |
Date Opened: | 2013-03-29 08:58:20 | Date Closed: | 2013-04-25 14:29:28 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Core/Bridging |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ||
Description: | Please see the [Bridge Construction|http://svn.asterisk.org/svn/asterisk/team/group/bridge_construction/] Team project for the current status of this work.
Previously, when two channels were in a bridge, the bridging code explicitly would use the jitter buffers set up on a channel. When a frame was read from a channel, if the outbound channel had a jitter buffer, the frame was written into the jitter buffer. This has several drawbacks: # The jitter buffer code was integrated tightly into the bridging code # The jitter buffers were placed on the 'wrong side' of a channel. De-jittering makes the most sense on the read side of a channel, before the frames are put into the Asterisk core. In Asterisk 10, {{func_jitterbuffer}} was added that puts the jitter buffer on a channel as a frame hook. This puts it on the read side of a channel and does so in a dynamic fashion. This task is to migrate all use of jitter buffers over to use {{func_jitterbuffer}}. This entails: * All channel drivers that create a jitter buffer explicitly should, when they call the set up jitter buffer function and enable a jitter buffer, automatically put a {{func_jitterbuffer}} on the channel (if {{func_jitterbuffer}} is loaded) * {{func_jitterbuffer}} needs to be modified to handle SRCUPDATE/SRCCHANGE control frames. These should resync the jitter buffer automatically (this was currently handled by the bridging code) * The various API calls that the bridging layer was explicitly calling should be removed. | ||
Comments: |