When bridging channels we were trying to match the audio
formats of both sides in combination with the configured
formats. While this is allowed in SDP in practice this
causes extra reinvites and problems. This change ensures
that audio streams use the formats of the first existing
active audio stream. It is only when other stream types
(like video) exist that this will result in re-negotiation
occurring for those streams only.
ASTERISK-28871
Change-Id: I22f5a3e7db29e00c165e74d05d10856f6086fe47
Some places in Asterisk did not treat the formats on a stream
as immutable when they are.
The ast_stream_get_formats function is now const to enforce this
and parts of Asterisk have been updated to take this into account.
Some violations of this were also fixed along the way.
An additional minor tweak is that streams are now allocated with
an empty format capabilities structure removing the need in various
places to check that one is present on the stream.
ASTERISK-28846
Change-Id: I32f29715330db4ff48edd6f1f359090458a9bfbe
This change adds support to bridge_softmix to allow the addition
and removal of additional video source streams. When such a change
occurs each participant is renegotiated as needed to reflect the
update. If another video source is added then each participant
gets another source. If a video source is removed then it is
removed from each participant. This functionality allows you to
have both your webcam and screenshare providing video if you
desire, or even more streams. Mapping has been changed to use
the topology index on the source channel as a unique identifier
for outgoing participant streams, this will never change and
provides an easy way to establish the mapping.
The bridge_simple and bridge_native_rtp modules have also been
updated to renegotiate when the stream topology of a party changes
allowing the same behavior to occur as added to bridge_softmix.
If a screen share is added then the opposite party is renegotiated.
If that screen share is removed then the opposite party is
renegotiated again.
Some additional fixes are also included in here. Stream state is
now conveyed in SDP so sendonly/recvonly/inactive streams can
be requested. Removed streams now also remove previous state
from themselves so consumers don't get confused.
ASTERISK-28733
Change-Id: I93f41fb41b85646bef71408111c17ccea30cb0c5
During capabilities selection (joint capabilities of us and peer,
configured capability for this peer, or general configured
capabilities), if sip_new() does not keep framing information,
then directmedia activation will fail for any framing different
from default framing.
ASTERISK-28637
Change-Id: I99257502788653c2816fc991cac7946453082466
If two channels enter different native rtp bridges at the same time it is
possible that the framehook interface data pointer can be corrupted
because the struct variable was declared static.
* Fixed the reentrancy corruption by changing the framehook interface
struct static variable to a stack local variable.
* Moved the hook.data assignment outside of the channel lock. It did not
need the lock's protection. It probably was giving a false sense of
security.
The testsuite
channels/pjsip/basic_calls/two_parties/nominal/alice_initiated/bob_hangs_up
test caught this with MALLOC_DEBUG and DO_CRASH enabled.
Change-Id: If9e35b97d19209b0f984941c1d8eb5f7c55eea91
When two channels were early bridged in a native_rtp bridge, the RTP description
on one side was not updated when the other side answered.
This patch forbids non-answered channels to enter a native_rtp bridge, and
triggers a bridge reconfiguration when an ANSWER frame is received.
ASTERISK-27257
Change-Id: If1aaee1b4ed9658a1aa91ab715ee0a6413b878df
* Fix framehook to test frame type for control frame.
* Made framehook exit early if frame type is not a control frame.
* Eliminated RAII_VAR in framehook.
* Use switch instead of else-if ladder for control frame handling.
Change-Id: Ia555fc3600bd85470e3c0141147dbe3ad07c1d18
The video stream was using the audio stream RTP instance addresses to
check if the video RTP gets directed to an allowed direct media Access
Control List (ACL) address. There is no guarantee that the video RTP
instance uses the same addresses as the audio RTP instance.
This looks like it has been a bug since v11 when direct media ACL was
first added to chan_sip and then faithfully reproduced through a couple
code refactorings into the new bridging architecture.
Change-Id: I8ddd56320e0eea769f3ceed3fa5b6bdfb51d681a
There have been reports of deadlocks caused by an attempt to send a frame
to a channel's rtp instance after the channel has left the native bridge
and been destroyed. This patch effectively causes the bridge channel to
keep a reference to the glue and both the audio and video rtp instances
so what gets started will get stopped.
ASTERISK-26978 #close
Reported-by: Ross Beer
Change-Id: I9e1ac49fa4af68d64826ccccd152593cf8cdb21a
This change adds a deferred queue to bridging. If a bridge
technology determines that a frame can not be written and
should be deferred it can indicate back to bridging to do so.
Bridging will then requeue any deferred frames upon a new
channel joining the bridge.
This change has been leveraged for T.38 request negotiate
control frames. Without the deferred queue there is a race
condition between the bridge receiving the T.38 request
negotiate and the second channel joining and being in the
bridge. If the channel is not yet in the bridge then the T.38
negotiation fails.
A unit test has also been added that confirms that a T.38
request negotiate control frame is deferred when no other
channel is in the bridge and that it is requeued when a new
channel joins the bridge.
ASTERISK-26923
Change-Id: Ie05b08523f399eae579130f4a5f562a344d2e415
The bridge_native_rtp module did not properly handle the case where
a smart bridge operation occurs while a channel is suspended. In this
scenario the module would incorrectly set up local or remote RTP
bridging despite the media having to flow through Asterisk. The remote
endpoint would see two media streams and experience wonky audio.
The module has been changed so that it ensures both channels are
not suspended when performing the native RTP bridging and this
requirement has been documented in the bridge technology.
ASTERISK-26781
Change-Id: Id4022d73ace837d4a293106445e3ade10dbc7c7c
In native_rtp_bridge_compatible_check()
* Made one variable declaration per line.
* Extracted if test assignment to make the test easier to see.
* Made long if tests easier to see the combinatorial logic.
* Added bridge id to a couple debug messages.
Change-Id: I65bc5732aa7c9a2537f062f106fbea711cf2daad
native_rtp_bridge_compatible() didn't lock the bridge channels before
checking the channels for native bridging ability. As a result, one of
the channel's native format capabilities structure got replaced out from
under the native bridge check. Use of a stale pointer to freed memory
causes bad things to happen.
MALLOC_DEBUG, DO_CRASH, and the
tests/channels/pjsip/transfers/blind_transfer/caller_direct_media
testsuite test caught this.
* Add missing channel locking in native_rtp_bridge_compatible().
Change-Id: If25fdb3ac8e85563c4857fb8216b3d9dc3d0fa53
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.
Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename
This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled. This variable was only used in lock.c so it
is now initialized in that file only.
ASTERISK-26480 #close
Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
The bridge_native_rtp module adds a frame hook to channels which are in
a native RTP bridge. This frame hook is used to intercept when a hold
or unhold frame traverses the bridge so native RTP can be stopped or
started as appropriate. This is expected but exposes a specific bug
when attended transfers are involved.
Upon completion of an attended transfer an unhold frame is queued up
to take one of the channels involved off hold. After this is done
the channel is moved between bridges.
When the frame hook is involved in this case for the unhold it
releases the channel lock and acquires the bridge lock. This
allows the bridge core to step in and move the channel
(potentially changing the bridging techology) from another thread.
Once completed the bridge lock is released by the bridge core.
The frame hook is then able to acquire the bridge lock and
wrongfully starts native RTP again, despite the channel no longer
being in the bridge or needing to start native RTP. In fact at
this point the frame hook is no longer attached to the channel.
This change makes it so the native RTP bridge data is available to
the frame hook when it is invoked. Whether the frame hook has
been detached or not is stored on the native RTP bridge data and
is checked by the frame hook before starting or stopping native
RTP bridging. If the frame hook has been detached it does nothing.
ASTERISK-25240 #close
Change-Id: I13a73186a05f4e5a764f81e5cd0ccec1ed1891d2
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
When a channel enters the bridging system it is first made compatible with
the bridge and then the bridge technology makes the channel compatible
with the technology. For all but the DAHDI native and softmix bridge
technologies the make channel compatible with the bridge step is an
effective noop because the other technologies allow all audio formats.
For the DAHDI native bridge technology it doesn't matter because it is not
an initial bridge technology and chan_dahdi allows only one native format
per channel. For the softmix bridge technology, it is a noop at best and
harmful at worst because the wrong translation path could be setup if the
channel's native formats allow more than one audio format.
This is an intermediate patch for a series of patches aimed at improving
translation path choices.
* Removed code dealing with the unnecessary step of making the channel
compatible with the bridge.
ASTERISK-24841
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4600/
........
Merged revisions 434424 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After r425242 the fax/sip/directmedia_reinvite_t38 test started failing due to
the surviving channel not being re-INVITEd back from T.38 to audio. This patch
fixes that bug - a deeper explanation of what happened follows.
When two RTP channels are in a native bridge, the bridging layer will
investigate each via the get_rtp_info glue callback. This callback returns the
native bridge preference of the channel *at that moment in time* (that part is
key). At different points during the bridging, the native bridging layer will
inform the RTP capable channels of the status of the bridge via the update_peer
glue callback.
In a T.38 scenario with audio direct media, the sequence of events will often
look like the following:
* SIP/A and SIP/B both have audio and enter a native bridge.
* Asterisk re-INVITEs audio between SIP/A and SIP/B directly (via an
update_peer callback).
* SIP/A sends a re-INVITE to T.38, which causes Asterisk to send a re-INVITE
to T.38 to SIP/B. Assuming everyone 200 OKs the process, the UDPTL stack
receives UDPTL packets in Asterisk from both endpoints. From the perspective
of the channels, we are now in a local bridge for T.38, even though we are
technically still in a remote bridge in bridge_native_rtp. (YAY!)
* When one side hangs up, bridge_native_rtp is told to stop bridging. It then
re-evaluates the channels and asks them how they are bridged - and since
T.38 is enabled, they reply with a Local bridge (which is correct), but is
wrong because the audio portion is still technically in a remote bridge.
* Asterisk releases the surviving channel, whose audio is *not* re-INVITED
back to Asterisk as bridge_native_rtp incorrectly assumes that it was in a
local bridge.
Ironically, prior to r425242, this used to work mostly due to a fluke in the
bridging layer.
The purpose of the get_rtp_info callback shouldn't be modified: it should tell
the bridging layer what kind of bridge the channel prefers at that moment in
time. If you have T.38 enabled, that *must* be a local bridge, as the UDPTPL
stack must be in the media path. As such, this patch does not modify that
part of the code.
However, we have to tell the channels to re-evaluate themselves when they come
out of a native bridge, since we can no longer trust the get_rtp_info callbacks
when the native bridge is being stopped. Something else may have changed in the
channels, and they may now be lying to us. As such, this patch makes it so that
we unilaterally tell the channels that they are no longer bridged via the
update_peer callback. This is actually what the channels expect anyway: code in
both chan_sip and chan_pjsip's callbacks look at the T.38 state and - if they
were in T.38 - send a re-INVITE to get the audio back to Asterisk.
Review: https://reviewboard.asterisk.org/r/4157/
........
Merged revisions 427582 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427583 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a native RTP bridge that is remotely bridging its participants switches
to a softmix bridge, it may not properly re-INVITE the media for one or both
participants back to Asterisk. This is due to the current bridge_native_rtp
code only re-INVITEs if it believes the channel will survive the bridge
operation. Currently, that code is failing, as it expects the channels to
have a soft hangup flag set on it indicating that a redirect has occurred
or that the channel is going to leave the bridge. (The code did not take into
account a smart bridge operation).
This patch also renames a few things to be more reflective of the underlying
types.
Review: https://reviewboard.asterisk.org/r/3997/
ASTERISK-24327 #close
........
Merged revisions 425760 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425761 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425762 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a smart bridge operation occurs and a bridge transitions from one
technology to another the old technology is provided the channels formerly
in it and told that they are leaving. Unfortunately the bridge provided
along with them is incomplete. The bridge, despite there being channels in it,
contains none. This forces technology implementations to have additional
logic when channels are leaving or to store their own duplicated
state.
This change makes the bridge more complete so it contains the expected
channels. Now that the bridge is complete special logic within
bridge_native_rtp is no longer needed and has been removed.
Review: https://reviewboard.asterisk.org/r/4057/
........
Merged revisions 425242 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425243 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Whenever possible, audiohooks and framehooks will now be copied over
to the channel that the masquerading channel gets cloned into. This
should occur for all audiohooks and most framehooks. As a result,
in Asterisk 12.5 and up, the AUDIOHOOK_INHERIT function is now
deprecated and its behavior is essentially the new default for all
audiohooks, plus some additional audiohooks/framehooks.
Review: https://reviewboard.asterisk.org/r/3721/
........
Merged revisions 418914 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418936 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is a re-do of r414122.
When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft
hangup flags have a catastrophic effect on the pbx core if they leak out from
the bridge layer: the channel gets hung up. With the number of threads
involved in a blind transfer, and with the initial patch, it was likely that
this would occur. This caused a large number of test failures
This patch is nearly identical with the one proposed in r414122, save for the
following changes:
- We explicitly clear the UNBRIDGE flag when setting an after goto on a
channel in a bridge
- Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it
https://reviewboard.asterisk.org/r/3585/
........
Merged revisions 415443 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415444 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge_native_rtp module currently uses the bridge result of the first
channel that joins a bridge as the ultimate result. This means that if the
first channel has direct media enabled but the second does not a direct
media bridge will still occur.
This change makes it so that both sides are taken into account. If either
side forbids the bridge or responds with a local bridge result then
either a generic or local bridge occurs.
ASTERISK-23541 #close
Reported by: Justin E
Review: https://reviewboard.asterisk.org/r/3577/
........
Merged revisions 414975 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes issues with direct media bridges that occur after a blind
transfer. These issues were caught by the (currently failing)
pjsip/transfers/blind_transfer/caller_direct_media test.
The test currently fails primarily for two reasons:
(1) When Bob and Charlie (the transfer target and the transfer destination)
enter a bridge together, the framehook remains on the transfer target
channel until both channels are in the bridge. As it consumes voice frames,
the initial bridge type is a simple bridge. The framehook is removed when
both channels are in the bridge; however, this does not currently cause the
bridging framework to re-evaluate the bridge. This patch adds a
AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a
framehook is removed so the bridge can re-evaluate itself.
(2) When a channel leaves a native RTP bridge, it may be leaving due to being
hung up. Sending a re-INVITE to a channel that is about to be hung up is
not nice - in fact, there's a good chance we'll send the BYE request before
the channel has had a chance to send back a 200 OK. To be somewhat nicer,
this patch adds a function to channel.h that allows the bridging framework
to query for exactly why a channel is leaving a bridge via the channel's
soft hangup flags. This allows it to only send the re-INVITE if there's a
chance the channel will survive the native bridging experience.
Review: https://reviewboard.asterisk.org/r/3535/
........
Merged revisions 414122 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414123 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.
This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.
ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close
Review: https://reviewboard.asterisk.org/r/3522/
........
Merged revisions 413681 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.
This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.
ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close
Review: https://reviewboard.asterisk.org/r/3522/
........
Merged revisions 413650 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible for a channel to be masqueraded out of a bridge which
means it may no longer have RTP glue to check upon leaving said bridge.
If this situation occurred (it's possible at least during dial and call
pickup) then Asterisk would crash. This change makes sure the glue is
checked before use.
(closes issue AST-1290)
Reported by: John Bigelow
........
Merged revisions 409900 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@409904 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The change contains a slightly adjusted patch that was on the issue
(submitted by kmoore). A fix was made by adding in a bridge lock
while calling bridge_start/stop from the framehook callback. Since
the framehook callback is not called from the bridging core the bridge
is not locked, but needs to be before calling bridge_start.
(closes issue ASTERISK-22749)
Reported by: Kinsey Moore
Review: https://reviewboard.asterisk.org/r/3066/
Patches:
lock_inversion.diff uploaded by kmoore (license 6273)
........
Merged revisions 403767 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a bridge transitions away from one tech to another, the tech going
away is provided a dummy bridge with no channels in it to tear down.
Currently this means that the teardown code exits prematurely and does
not tear anything down. This change tears down RTP bridging for the
channel provided in the leave bridge tech callback.
This also reverts the majority of r400403 since it is now redundant.
(closes issue ASTERISK-22628)
(closes issue ASTERISK-22676)
Reported by: John Bigelow
Reported by: Kevin Harwell
Tested by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2905/
Patches:
native_rtp_fix.diff uploaded by Kinsey Moore (License 6273)
........
Merged revisions 402148 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402149 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a party leaves a bridge, there may be more participants in the bridge than expected.
As such, it is important not to make assumptions regarding the list of channels in a
bridge.
This change makes it so that when a party leaves a native RTP bridge, we unbridge it and
the party it was bridged with. Previously, the first and last channels in the list were
unbridged since it was assumed that these were the two channels that had been bridged. As
previously stated, a new party had been inserted into the bridge, so this logic did not
work properly.
(closes issue ASTERISK-22615)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2899
........
Merged revisions 400403 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
These refleaks were causing bridged calls not to close their RTP ports. Thus
a call would leave open 4 ports (RTP for party A, RTCP for party A, RTP for party
B, and RTCP for party B). This led to an eventual depletion of available RTP
ports.
........
Merged revisions 399924 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399925 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Issuing hold/unhold would lead to odd behavior. Between two chan_sip devices,
a hold could cause an endless chain of updates while with pjsip a similar chain
would begin but then end somewhat randomly. This patch fixes that by no longer
tweaking the RTP glue on both sides of the call for every
HOLD/UNHOLD/UPDATE_RTP_PEER frame.
(issue ASTERISK-22217)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2794/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397578 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
* Extract a useful routine from the softmix bridge technology for other
technologies. Make other technologies use it if they can.
* Made native and 1-1 bridges write to all parties if the bridge channel
writing the frame into the bridge is NULL. Softmix will also do the same
for frame types that make sense.
* Tweak the bridge write routine return value meaning and adjust the
bridge technologies to match.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392514 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two memory leaks:
* A memory leak in packing channels into a multi-channel blob payload when
publishing dial messages. The multi-channel blob payload does not steal
the references - this approach was chosen because it works well with the
RAII_VAR macro. Unfortunately, this does mean that you actually have to use
the RAII_VAR macro (or manually deref it yourself)
* RTP instances returned as a result of one of the glue operations are ref
counted and have to be de-ref'd appropriately. We now do that, as saying
that we should do it and then not would be silly.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Joshua C. Colp
Frederic LE FOLL
Robert Cripps
Richard Mudgett
Jean Aunis
George Joseph
Joshua Colp
Corey Farrell
Alexander Traud
Matt Jordan
George Joseph
Jonathan Rose
Kinsey Moore
Kevin Harwell
Mark Michelson