| Age | Commit message (Collapse) | Author |
|---|
|
Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does three things:
1. It provides a Surrogate channel technology with a consolidated
"implementation detail flag" on the channel technology. This tells
consumers of Stasis that the creation of this channel is an implementation
detail in Asterisk and can be ignored (if they so choose). This
consolidates the conference recorder/announcer flags as well - these flags
had no additional meaning beyond "ignore this channel please".
2. It modifies allocation of a channel in two ways:
(a) If a channel technology can be determined from the name, we set it
directly in the allocation routine. This prevents the initial
publication of the message from going out with a NULL channel technology
where possible. This lets Stasis consumers get the right channel
technology on the first publication.
(b) It reorganizes allocation to make use of the 'finalized' property on the
channel. This was already used to know that a channel had completely
finished its construction in the masquerade routine; now we also use it
to know whether or not the setting of certain channel properties is
occurring during or post construction. The various set routines were
modified accordingly as well.
3. The masquerade event is now dead, Jim. It no longer served any purpose
whatsoever - if you perform a call pickup you'll get a Pickup event;
if you perform an attended transfer you will still get those events; if you
steal a channel to put it elsewhere you'll get the corresponding NewExten or
BridgeEnter events.
Review: https://reviewboard.asterisk.org/r/2740
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Adds a new channel driver for creating channels for specific purposes
in bridges, primarily to act as either recorders or announcers. Adds
ARI commands for playing announcements to ever participant in a bridge
as well as for recording a bridge. This patch also includes some
documentation/reponse fixes to related ARI models such as playback
controls.
(closes issue ASTERISK-21592)
Reported by: Matt Jordan
(closes issue ASTERISK-21593)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2670/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
