When more than one call using the same codec type enters into a softmix bridge
and no audio is present for a channel the bridge optimizes the out frame by
using the same one for all channels with the same codec type. Unfortunately,
when that number (channels with same codec type) dropped to <= 1 the codec
was not dereferenced. At least not until all parties left the bridge. Thus in
the case of G.729 the license was not released. This patch ensures that the
codec is dereferenced immediately when the optimization no longer applies.
ASTERISK-24797 #close
Reported by: Luke Hulsey
Review: https://reviewboard.asterisk.org/r/4429/
........
Merged revisions 432174 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432175 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432176 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 addresses some aesthetic issues in Asterisk. These are all just
minor tweaks to improve the look of the CLI when used in a variety of
settings. Specifically:
* A number of chatty verbose messages were removed or demoted to DEBUG
messages. Verbose messages with a verbosity level of 5 or higher were -
if kept as verbose messages - demoted to level 4. Several messages
that were emitted at verbose level 3 were demoted to 4, as announcement
of dialplan applications being executed occur at level 3 (and so the
effects of those applications should generally be less).
* Some verbose messages that only appear when their respective 'debug'
options are enabled were bumped up to always be displayed.
* Prefix/timestamping of verbose messages were moved to the verboser
handlers. This was done to prevent duplication of prefixes when the
timestamp option (-T) is used with the CLI.
* Verbose magic is removed from messages before being emitted to
non-verboser handlers. This prevents the magic in multi-line verbose
messages (such as SIP debug traces or the output of DumpChan) from
being written to files.
* _Slightly_ better support for the "light background" option (-W) was
added. This includes using ast_term_quit in the output of XML
documentation help, as well as changing the "Asterisk Ready" prompt to
bright green on the default background (which stands a better chance of
being displayed properly than bright white).
Review: https://reviewboard.asterisk.org/r/3547/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414798 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
Add an option to enable a periodic beep to be played into a call if it
is being recorded. If enabled, it uses the PERIODIC_HOOK() function
internally to play the 'beep' prompt into the call at a specified
interval. This option is provided for both Monitor() and
MixMonitor().
Review: https://reviewboard.asterisk.org/r/3424/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Playing back a file to a channel in an ARI bridge would attempt to wait until
the playback concluded before returning. The method used involved signaling the
waiting thread in the ARI custom playback function.
The problem with this is that there were some corner cases that were not accounted for:
* If a bridge channel could not be found, then we never would attempt the playback but
would still attempt to wait for the playback to complete.
* If the bridge playfile action failed to queue, we would still attempt to wait for the
playback to complete.
* If the bridge playfile action were queued but some circumstance caused the playback
not to occur (the bridge dies, the channel is removed from the bridge), then we would
never be notified.
The solution to this is to move the waiting logic into the bridge code. A new bridge
API function is added to queue a synchronous action on a bridge. The waiting thread
is notified when the queued frame has been freed, either due to an error occurring
or due to successful playback. As a failsafe, the waiting thread has a 10 minute
timeout just in case there is a frame leak somewhere.
Review: https://reviewboard.asterisk.org/r/3338
........
Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 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
The crash is caused by a race condition when switching between native RTP
and softmix bridging technologies. In this situation, the bridging
technology is switched from native RTP to softmix, and then back to native
RTP fast enough that the softmix private data gets destroyed before the
softmix mixing thread gets started.
Thanks to Kinsey Moore for the crash analysis.
* Fix race condition when starting the softmix mixing thread and switching
to another bridge technology.
(closes issue ASTERISK-22678)
Reported by: John Bigelow
Patches:
jira_asterisk_22678_v12.patch (license #5621) patch uploaded by rmudgett
Tested by: John Bigelow
........
Merged revisions 400849 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400850 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
DTMF start/end and hold/unhold events have state because a DTMF begin
event and hold event must be ended by something.
The following cases need to be handled when a channel is moved around in
the system.
* When a channel leaves a bridge it may owe a DTMF end event to the
bridge.
* When a channel leaves a bridge it may owe an UNHOLD event to the bridge.
(This case is explicitly ignored because things like transfers need
explicit control over this.)
* When a channel leaves the bridging system it may need to simulate a DTMF
end event to the channel.
* When a channel leaves the bridging system it may need to simulate an
UNHOLD event to the channel.
The patch also fixes the following:
* Fixes playing a file and restarting MOH using the latest MOH class used.
(closes issue ASTERISK-22043)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2791/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397577 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The cause code needs to be passed from the disconnecting channel to the
bridge peers if the disconnecting channel dissolves the bridge.
* Made the call to an app_agent_pool agent disconnect with the busy cause
code if the agent does not ack the call in time or hangs up before acking
the call.
(closes issue ASTERISK-22042)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2772/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397472 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added an option flags parameter to interval hooks. Interval hooks now
can specify if the callback will affect the media path or not.
* Added an option flags parameter to the bridge action custom callback.
The action callback now can specify if the callback will affect the media
path or not.
* Made the holding bridge technology reexamine the participant idle mode
option whenever the entertainment is restarted.
* Fixed app_agent_pool waiting agents needlessly starting and stopping MOH
every second by specifying the heartbeat interval hook as not affecting
the media path.
* Fixed app_agent_pool agent alert from restarting the MOH after the alert
beep. The agent entertainment is now changed from MOH to silence after
the alert beep.
* Fixed holding bridge technology to defer starting the entertainment. It
was previously a mixture of immediate and deferred.
* Fixed holding bridge technology to immediately stop the entertainment.
It was previously a mixture of immediate and deferred. If the channel
left the bridging system, any deferred stopping was discarded before
taking effect.
* Miscellaneous holding bridge technology rework coding improvements.
Review: https://reviewboard.asterisk.org/r/2761/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Suspend and unsuspend callbacks are added to the holding bridge so
that entertainment can be disabled and re-enabled when operations
would suspend a channel on the bridge (such as playback operations).
This fixes entertainment so that when those operations end, the
entertainment can pick back up and it also serves as an optimization.
Also, this patch fixes a bug caused by triggering ringing frames
immediately instead of pushing them to the queue which created a race
condition where sometimes parking with ringing during attended
transfers would cause the ringing to be interrupted by an unhold
frame.
(closes issue ASTERISK-22006)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2711/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396189 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most hook callbacks did not need the bridge parameter. The pointer value
could become invalid if the channel is moved to another bridge while it is
executing.
* Fixed some issues in feature_attended_transfer() as a result.
* Reduce the bridge inhibit count in
attended_transfer_properties_shutdown() after it has restored the bridge
channel hooks.
* Removed basic bridge requirement on feature_blind_transfer(). It does
not require the basic bridge like feature_attended_transfer().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed feature limits to not use special members of struct
ast_bridge_features.
* Fixed memory leak in off nominal paths of bridge_builtin_set_limits().
* Fixed off nominal path in ast_bridge_features_limits_construct() freeing
unallocated memory if it was not called by bridge_builtin_set_limits().
* Made bridge_builtin_interval_features.so unloadable.
* Simplified parking's use of its duration interval hook.
* Made BridgeWait S option not depend upon another module being loaded.
(closes issue ASTERISK-22107)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2701/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395559 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
This patch does the following:
* It pulls out bridge_channel and puts it into its own translation unit
* It adds public and protected headers for bridging_channel. Protected
functions are appropriate only for the Bridging API and sub-classes of a
bridge.
(issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395253 65c4cc65-6c06-0410-ace0-fbb531ad65f3