When a channel already in a conference bridge is attended transfered
to another extension, or when an existing call is attended
transferred into a conference bridge, we now generate ConfbridgeJoin
and ConfbridgeLeave events for the entering and departing channels.
Change-Id: Id7709cfbceb26fbcb828b2d0d2a6b2fbeaf028e1
Currently the file sound_only_person is not played when a marked
user (with announce_only_user=yes) joins an empty conference.
This patch fixes it.
ASTERISK-28201 #close
Change-Id: I85b67687e6b220939c3af8091d83a70a7b174cf4
Replace usage of ao2_container_alloc with ao2_container_alloc_hash or
ao2_container_alloc_list.
ao2_container_alloc is now restricted to modules only and is being
removed from Asterisk 17.
Change-Id: I0907d78bc66efc775672df37c8faad00f2f6c088
Add attribute_warn_unused_result to ast_taskprocessor_push,
ast_taskprocessor_push_local and ast_threadpool_push. This will help
ensure we perform the necessary cleanup upon failure.
Change-Id: I7e4079bd7b21cfe52fb431ea79e41314520c3f6d
If a conference is ended very quickly after it was created (i.e., the
first user immediately hangs up) then the conference bridge and announcer
channels are not removed.
When a conference is created, the push_announcer() function is added to
the playback queue task processor and the conference object reference is
bumped. If a conference is ended while the push_announcer() function is
still going then the ao2_cleanup(conference) at the end of
push_announcer() will call the destructor function -
destroy_conference_bridge().
The destroy_conference_bridge() function will then add the
hangup_playback() task to the playback queue and will wait for it to end.
Since it is already a current task of the playback queue it will wait
forever.
This patch makes the conference thread call push_announcer() directly.
This way the conference object reference bump is not needed. Since the
playback queue task processor is only used by the conference thread
itself, there is no danger of trying to play announcements before the
announcer is pushed to the bridge.
ASTERISK-27870 #close
Change-Id: I947a50fb121422d90fd1816d643a54d75185a477
When an AMI client connects, it cannot determine if a user was talking
prior to a transition in the user speaking state (which would generate
a ConfbridgeTalking event). This patch causes app_confbridge to track the
talking state and make this state available via ConfBridgeList.
ASTERISK-27877 #close
Change-Id: I19b5284f34966c3fda94f5b99a7e40e6b89767c6
* Made the AMI ConfbridgeList action's ConfbridgeList events output all
the standard channel snapshot headers instead of a few hand-coded channel
snapshot headers. The benefit is that the CallerIDName gets disruptive
characters like CR, LF, Tab, and a few others escaped. However, an empty
CallerIDName is now output as "<unknown>" instead of "<no name>".
ASTERISK-27651
Change-Id: Iaf7d54a9d40194c2db060bc9b4979fab6720d977
The check for last_user == NULL needs to happen before we dereference
the variable, previously it was possible for us to check flags of a NULL
last_user.
Change-Id: I274f737aa8af9d2d53e4a78cdd7ad57561003945
* Stop using ast_module_helper to check if a module is loaded, use
ast_module_check instead (app_confbridge and app_meetme).
* Stop ast_module_helper from listing reload classes when needsreload
was not requested.
ASTERISK-27378
Change-Id: Iaed8c1e4fcbeb242921dbac7929a0fe75ff4b239
This prevents orphaned CBAnn channels from getting stuck in the bridge.
ASTERISK-26994 #close
Reported by: James Terhune
Change-Id: I5e43e832a9507ec3f2c59752cd900b41dab80457
This commit fixes two possible scenarios:
* When recording name and if during recording you hangup, file is never
removed. This is due to the fact file location is nulled.
* When recording name and if you hangup during thank-you prompt, file
is never removed.
ASTERISK-27123 #close
Change-Id: I39b7271408b4b54ce880c5111a886aa8f28c2625
When user leaves a conference, its channel calls async_play_sound_file()
in order to play the name announcement and then unlinks the sound file.
The async_play_sound_file() function adds a task to conference playback queue,
which then runs playback_common() function in a different thread.
It leads to a race condition when, in some cases, channel thread may unlink
the sound file before playback_common() had a chance to open it.
This patch creates a file deletion task, that is queued after playback.
ASTERISK-27012 #close
Change-Id: I412f7922d412004b80917d4e892546c15bd70dd3
In all non-pbx modules, AST_MODULE_LOAD_FAILURE has been changed
to AST_MODULE_LOAD_DECLINE. This prevents asterisk from exiting
if a module can't be loaded. If the user wishes to retain the
FAILURE behavior for a specific module, they can use the "require"
or "preload-require" keyword in modules.conf.
A new API was added to logger: ast_is_logger_initialized(). This
allows asterisk.c/check_init() to print to the error log once the
logger subsystem is ready instead of just to stdout. If something
does fail before the logger is initialized, we now print to stderr
instead of stdout.
Change-Id: I5f4b50623d9b5a6cb7c5624a8c5c1274c13b2b25
Confbridge announcements tend to block a channel while they are being
played. In some circumstances, this is warranted since you want that
particular channel not to hear the announcement (Example: "John Doe has
entered the conference"). For others it makes less sense.
This change first introduces methods for playing sounds asynchronously
into the conference. This is very similar to how synchronous sounds are
played, except the channel initiating the playback does not wait for the
sound to complete before moving on.
Asynchronous announcements are used for two circumstances:
* Sounds played for a user after they have left the bridge
* Sounds that play first to a single user and then the rest of the
conference (if the channel and conference use the same language)
ASTERISK-26289 #close
Reported by Mark Michelson
Change-Id: Ie486bb3de1646d50894489030326a423e594ab0a
NOTE: This patch was submitted earlier and reverted because of a failing
test. The test has been patched so that it adjusts for the changes here,
so this is being resubmitted for review.
One feature that confbridge has is the ability to play sounds to all
participants in the conference. Prior to this commit, the algorithm for
this was as follows:
* Grab the playback lock
* Push the conference announcer channel into the bridge
* Play back the sound
* Pull the conference announcer channel from the bridge
* Release the playback lock
The issue here is that the act of adding the playback channel to the
bridge and removing it for each announcement is expensive. Amongst the
expenses:
* The announcer channel is imparted into the bridge, meaning a new
thread is spun up for each playback.
* When the announcer is added or removed from the bridge, it results
in the BRIDGEPEER channel variable being set on all channels in the
bridge. This requires keeping the bridge locked and locking each
individual channel in order to set it.
* There's also just the general overhead of adding the channel and
removing it from the bridge. The bridge potentially has to reconfigure
every single time
With this commit, the paradigm for playing back announcements has
shifted.
* The announcer channel is now added to the bridge when the conference
is allocated, and it is hung up when the conference is destroyed.
* A taskprocessor is used to queue playbacks onto the announcer channel.
This keeps the behavior from before where playbacks do not overlap.
* The announcer channel is no longer placed into the bridge as
departable. Since we are not constantly removing the channel from
the bridge, it is safe to add the channel using an independent thread
and simply hang the channel up when it is time for the conference to
be destroyed.
The use of the taskprocessor for playbacks opens up the interesting
possibility of having asynchronous announcements played. In this commit,
however, the behavior is still exactly the same as it previously was.
ASTERISK-26289
Reported by Mark Michelson
Change-Id: Ica9fa4907c2f3728cdd1cf0bc564ef4eb40754a0
One feature that confbridge has is the ability to play sounds to all
participants in the conference. Prior to this commit, the algorithm for
this was as follows:
* Grab the playback lock
* Push the conference announcer channel into the bridge
* Play back the sound
* Pull the conference announcer channel from the bridge
* Release the playback lock
The issue here is that the act of adding the playback channel to the
bridge and removing it for each announcement is expensive. Amongst the
expenses:
* The announcer channel is imparted into the bridge, meaning a new
thread is spun up for each playback.
* When the announcer is added or removed from the bridge, it results
in the BRIDGEPEER channel variable being set on all channels in the
bridge. This requires keeping the bridge locked and locking each
individual channel in order to set it.
* There's also just the general overhead of adding the channel and
removing it from the bridge. The bridge potentially has to reconfigure
every single time
With this commit, the paradigm for playing back announcements has
shifted.
* The announcer channel is now added to the bridge when the conference
is allocated, and it is hung up when the conference is destroyed.
* A taskprocessor is used to queue playbacks onto the announcer channel.
This keeps the behavior from before where playbacks do not overlap.
* The announcer channel is no longer placed into the bridge as
departable. Since we are not constantly removing the channel from
the bridge, it is safe to add the channel using an independent thread
and simply hang the channel up when it is time for the conference to
be destroyed.
The use of the taskprocessor for playbacks opens up the interesting
possibility of having asynchronous announcements played. In this commit,
however, the behavior is still exactly the same as it previously was.
ASTERISK-26289
Reported by Mark Michelson
Change-Id: Ic5cd2c4b98a1eaa1715eb7a5b35d62f1a76d78a5
This patch allows for having app_confbridge register the name of the
conference as an extension into a specific context, similar to
regcontext for chan_sip. This variant is not quite as involved as the
one in chan_sip and doesn't allow for multiple contexts or custom
extensions, you can only specify the context and the conference name
will always be used as the extension to register.
ASTERISK-25989 #close
Change-Id: Icacf94d9f2b5dfd31ef36f6cb702392619a7902f
A user cannot set new bridge options after the conference is created by
the first user. Attempting to do so is documented as undefined behavior.
This patch ensures that the bridge profile options used are from the
conference and not what a subsequent user may have tried to set.
Change-Id: I1b6383eba654679e5739d5a8de98199cf074a266
* Added CONFBRIDGE_INFO(muted,) for querying the muted conference state.
* Added Muted header to AMI ConfbridgeListRooms action response list
events to indicate the muted conference state.
* Added Muted column to CLI "confbridge list" output to indicate the muted
conference state and made the locked column a yes/no value instead of a
locked/unlocked value.
ASTERISK-20987
Reported by: hristo
Change-Id: I4076bd8ea1c23a3afd4f5833e9291b49a0c448b1
This option adds the ability to specify a timeout, in seconds, for a
participant in a ConfBridge. When the user's timeout has been reached,
the user is ejected from the conference with the CONFBRIDGE_RESULT
channel variable set to "TIMEOUT".
The rationale for this change is that there have been times where we
have seen channels get "stuck" in ConfBridge because a network issue
results in a SIP BYE not being received by Asterisk. While these
channels can be hung up manually via CLI/AMI/ARI, adding some sort of
automatic cleanup of the channels is a nice feature to have.
ASTERISK-25549 #close
Reported by Mark Michelson
Change-Id: I2996b6c5e16a3dda27595f8352abad0bda9c2d98
Attempting to execute DTMF in a confbridge while file playback (prompt,
announcement, etc) is occurring is not allowed. You have to wait until
the sound file has completed before entering DTMF. This patch fixes it
so that app_confbridge now monitors for dtmf key presses during menu
driven file playback. If a key is pressed playback stops and it executes
the matched menu option.
ASTERISK-24864 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4510/
........
Merged revisions 433445 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Starting and stopping conference recording more than once causes the
recording channels to be leaked. For v13 the channels also show up in the
CLI "core show channels" output.
* Reworked and simplified the recording channel code to use
ast_bridge_impart() instead of managing the recording thread in the
ConfBridge code. The recording channel's ref handling easily falls into
place and other off nominal code paths get handled better as a result.
ASTERISK-24719 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4368/
Review: https://reviewboard.asterisk.org/r/4369/
........
Merged revisions 431135 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList
* Incremented the AMI version to 2.7.0.
* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start". The corresponding complete event always used "Complete".
* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.
* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots(). Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.
* Fixed minor protocol error in action_getconfig() when no requested
categories are found. Each line needs to be formatted as "Header: text".
* Fixed off-nominal memory leak in manager_build_parked_call_string().
* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().
ASTERISK-24049 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4315/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430434 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Confbridge dialplan function permission escalation via AMI and inappropriate
class authorization on the ConfbridgeStartRecord action. The CONFBRIDGE dialplan
function when executed from an external protocol (for instance AMI), could
result in a privilege escalation. Also, the AMI action “ConfbridgeStartRecord”
could also be used to execute arbitrary system commands without first checking
for system access.
Asterisk now inhibits the CONFBRIDGE function from being executed from an
external interface if the live_dangerously option is set to no. Also, the
“ConfbridgeStartRecord” AMI action is now only allowed to execute under a
user with system level access.
ASTERISK-24490
Reported by: Gareth Palmer
........
Merged revisions 428332 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428334 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Kick, mute and unmute were a little inconsistent in their handling of channel
targets. This patch cleans that up by insuring they all handle the 'all'
target consistently and adds the 'participants' target which acts on
non-admins. Documentation for kick was also cleaned up as it never
supported partial channel names.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3944/
........
Merged revisions 422090 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, users waiting to enter a ConfBridge were not considered
when muted via the CLI or via AMI. Instead, a confusing message would be
emitted stating that the channel did not exist.
This patch allows a user to be muted when waiting to enter a ConfBridge
conference. This is equivalent to start when muted, only toggled via the CLI
or AMI.
Review: https://reviewboard.asterisk.org/r/3582
#ASTERISK-23824 #close
patches:
rb3582.patch uploaded by tm1000 (License 6524)
........
Merged revisions 415206 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 415207 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415208 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Conference names were not checked for maximum length, allowing unexpected
behaviour. This change adds checking to ensure the maximum length is not
exceeded. The maximum length is also changed from 32 to AST_MAX_EXTENSION.
ASTERISK-23035 #close
Reported by: Iñaki Cívico
Tested by: Iñaki Cívico
Patches:
confbridge-enforce_max-1.8.patch uploaded by coreyfarrell (license 5909)
confbridge-enforce_max-11up.patch uploaded by coreyfarrell (license 5909)
........
Merged revisions 415060 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 415066 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 415078 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixed a ref leak in conf_handle_talker_cb() everytime the conference
bridge was found to report a channel's talker status change. The
resulting leak caused the "CBAnn" channels and the conference bridge to
never be destroyed.
Thanks to Richard Kenner on the asterisk-user's list for locating the
problem.
Reported by: Richard Kenner
........
Merged revisions 413454 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413455 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the ability to kick all attendees from a conference was added, a
rework removed the comment about that feature from the CLI
documentation. This adds that documentation and adds "all" to the
participant tab completion list for the confbridge kick command.
(closes issue ASTERISK-23282)
Reported by: Dorian Logan
........
Merged revisions 412728 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, when the first marked user enters the conference that
contains waitmarked users, a prompt is played indicating that the user
is being placed into the conference. Unfortunately, this prompt is
played to the marked user and not the waitmarked users which is not
very helpful.
This patch changes that behavior to play a prompt stating
"The conference will now begin" to the entire conference after adding
and unmuting the waitmarked users since the design of confbridge is not
conducive to playing a prompt to a subset of users in a conference in
an asynchronous manner.
(closes issue PQ-1396)
Review: https://reviewboard.asterisk.org/r/3155/
Reported by: Steve Pitts
........
Merged revisions 407857 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 407858 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407859 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When waitmarked users join a ConfBridge, the conference state is transitioned
from EMPTY -> INACTIVE. In this state, the users are maintined in a waiting
users list. When a marked user joins, the ConfBridge conference transitions
from INACTIVE -> MULTI_MARKED, and all users are put onto the active list of
users. This process works correctly.
When the marked user leaves, if they are the last marked user, the MULTI_MARKED
state does the following:
(1) It plays back a message to the bridge stating that the leader has left the
conference. This requires an unlocking of the bridge.
(2) It moves waitmarked users back to the waiting list
(3) It transitions to the appropriate state: in this case, INACTIVE
However, because it plays the prompt back to the bridge before moving the users
and before finishing the state transition, this creates a race condition: with
the bridge unlocked, waitmarked users who leave the conference (or are kicked
from it) can cause a state transition of the bridge to another state before
the conference is transitioned to the INACTIVE state. This causes the state
machine to get a bit wonky, often leading to a crash when the MULTI_MARKED state
attempts to conclude its processing.
This patch fixes this problem:
(1) It prevents kicked users from being kicked again. That's just a nicety.
(2) More importantly, it fixes the race condition by only playing the prompt
once the state has transitioned correctly to INACTIVE. If waitmarked users
sneak out during the prompt being played, no harm no foul.
Review: https://reviewboard.asterisk.org/r/3108/
Note that the patch committed here is essentially the same as uploaded by
Simon Moxon on ASTERISK-22740, with the addition of the double kick prevention.
(closes issue AST-1258)
Reported by: Steve Pitts
(closes issue ASTERISK-22740)
Reported by: Simon Moxon
patches:
ASTERISK-22740.diff uploaded by Simon Moxon (license 6546)
........
Merged revisions 405215 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 405216 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
