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
Queue member will get stuck in pending_members if queue calls a device
that is different from the one observed for state changes.
This patch removes members from pending_members as a result of channel stasis
events such as blind or attended transfers and hangup.
ASTERISK-26862 #close
Change-Id: I8bf6df487b9bb35726c08049ff25cdad5e357727
The queue_stasis_data structure contains various mutable fields that require
appropriate locking. Specifically, the 'dying,' 'member_uniqueid,' and
'caller_uniqueid' fields need to be locked when read from or written to.
Change-Id: I246b7dbff8447acc957a1299f6ad0ebd0fd39088
Dereferencing struct ast_autochan.chan without first calling
ast_autochan_channel_lock() is unsafe because the pointer could change at
any time due to a masquerade. Unfortunately, ast_autochan_channel_lock()
itself uses struct ast_autochan.chan unsafely and can result in a deadlock
if the original channel happens to get destroyed after a masquerade in
addition to the pointer getting changed.
The problem is more likely to happen with v11 and earlier because
masquerades are used to optimize out local channels on those versions.
However, it could still happen on newer versions if the channel is
executing a dialplan application when the channel is transferred or
redirected. In this situation a masquerade still must be used.
* Added a lock to struct ast_autochan to safely be able to use
ast_autochan.chan while trying to get the channel lock in
ast_autochan_channel_lock(). The locking order is the channel lock then
the autochan lock. Locking in the other direction requires deadlock
avoidance.
* Fix unsafe ast_autochan.chan usages in app_mixmonitor.c.
* Fix unsafe ast_autochan.chan usages in app_chanspy.c.
* app_chanspy.c: Removed unused autochan parameter from next_channel().
ASTERISK-26867
Change-Id: Id29dd22bc0f369b44e23ca423d2f3657187cc592
A caller can leave the Queue() application after being bridged with a
member in a few ways:
* Caller or member hangup
* Caller is transferred somewhere else (blind or atx)
* Caller is externally redirected elsewhere
The first 2 scenarios are currently handled by subscribing to stasis
messages, but the 3rd is not explicitly covered. If a caller is
redirected away from the Queue() application, the member who was last
bridged with that caller will remain in an "In use" state until the
caller hangs up.
This patch adds handling of the caller leaving the queue via
redirection. We monitor the caller-member bridge, and if the caller is
the one that leaves, we treat it the same as we would a caller hangup.
ASTERISK-26400 #close
Reported by: Etienne Lessard
Change-Id: Iba160907770de5a6c9efeffc9df5a13e9ea75334
* apps/app_voicemail.c fromstring field added to mailbox which will
override the global fromstring if set.
ASTERISK-24562 #close
Change-Id: I5e90e3a1ec2b2d5340b49a0db825e4bbb158b2fe
ast_load_realtime_multientry() returns an ast_config structure whose
ast_categorys are keyed with the empty strings. Several modules were
giving semantic meaning to the category names causing problems at
runtime.
* app_directory: Treated the category name as the mailbox name, and
would fail to direct calls to the appropriate extension after an
entry was chosen.
* app_queue: Queues, queue members, and queue rules were all affected
and needed to be updated.
* pbx_realtime: Pattern matching would never succeed because the
extension entered by the user was always compared to the empty
string.
Change-Id: Ie7e44986344b0b76ea8f6ddb5879f5040c6ca8a7
vm_authenticate doesn't always set the passed ast_vm_user argument, so
we initialize to 0 before passing it in.
ASTERISK-25893 #close
Reported by: Filip Jenicek
Change-Id: Ia3cc0128f93d352ed9add8d5c2f0f7232c2cbe4a
Original patch by John Covert, slight modifications by me.
ASTERISK-17428 #close
Reported by: John Covert
Patches:
app_voicemail.c.patch (license #5512) patch uploaded by
John Covert
Change-Id: Ic3361b0782e5a5397a19ab18eb8550923a9bd6a6
When attempting to use VoiceMailPlayMsg with a realtime data backend
the message is located, but never retrieved. This patch adds the
required RETRIEVE and DISPOSE calls that will fetch the message from
the database (and IMAP storage as well for that matter).
Also, removed extraneous make_file call.
ASTERISK-26723 #close
Change-Id: I1e122dd53c0f3d7faa10f3c2b7e7e76a47d51b8c
When using Record() with the silence detection feature, the stream is
written out to the given file. However, if only 'silence' is detected,
this file is then truncated to the first second of the recording.
This patch adds the 'u' option to Record() to override that behavior.
ASTERISK-18286 #close
Reported by: var
Patches:
app_record-1.8.7.1.diff (license #6184) patch uploaded by var
Change-Id: Ia1cd163483235efe2db05e52f39054288553b957
* app_minivm: Use built-in completion facilities to complete optional
arguments.
* app_voicemail: Use built-in completion facilities to complete
optional arguments.
* app_confbridge: Add missing colons after 'Usage' text.
* chan_alsa: Use built-in completion facilities to complete optional
arguments.
* chan_sip: Use built-in completion facilities to complete optional
arguments. Add completions for 'load' for 'sip show user', 'sip show
peer', and 'sip qualify peer.'
* chan_skinny: Correct and extend completions for 'skinny reset' and
'skinny show line.'
* func_odbc: Correct completions for 'odbc read' and 'odbc write'
* main/asterisk: Correct and extend completions for 'core show file
version.'
* main/astmm: Use built-in completion facilities to complete arguments
for 'memory' commands.
* main/bridge: Correct completions for 'bridge kick.'
* main/ccss: Use built-in completion facilities to complete arguments
for 'cc cancel' command.
* main/cli: Add 'all' completion for 'channel request hangup.' Correct
completions for 'core set debug channel.' Correct completions for 'core
show calls.'
* main/pbx_app: Remove redundant completions for 'core show
applications.'
* main/pbx_hangup_handler: Remove unused completions for 'core show
hanguphandlers all.'
* res_sorcery_memory_cache: Add completion for 'reload' argument of
'sorcery memory cache stale' and properly implement.
Change-Id: Iee58c7392f6fec34ad9d596109117af87697bbca
In Asterisk 11, if the 'Originate' AMI command failed to connect the provided
Channel while in extension mode, a 'failed' extension would be looked up and
run. This was, I believe, unintentionally removed in 51b6c49. This patch
restores that behavior.
This also adds an enum for the various 'synchronous' modes in an attempt to
make them meaningful.
ASTERISK-26115 #close
Reported by: Nasir Iqbal
Change-Id: I8afbd06725e99610e02adb529137d4800c05345d
We shouldn't unlock the channel after starting a snapshot staging because
another thread may interfere and do its own snapshot staging.
* app_dial.c:dial_exec_full() made hold the channel lock while setting up
the outgoing channel staging. Made hold the channel lock after the called
party answers while updating the caller channel staging.
* chan_sip.c:sip_new() completed the channel staging on off-nominal exit.
Also we need to use ast_hangup() instead of ast_channel_unref() at that
location.
* channel.c:__ast_channel_alloc_ap() added a comment about not needing to
complete the channel snapshot staging on off-nominal exit paths.
* rtp_engine.c:ast_rtp_instance_set_stats_vars() made hold the channel
locks while staging the channels for the stats channel variables.
Change-Id: Iefb6336893163f6447bad65568722ad5d5d8212a
With 500+ queues and a reload every minute, a random queue disappears
upon reload. The cause is mususe of the 'dead' flag. Namely, all queues
were marked dead up front, and then "resurrected" by dropping this flag
for those found in the configuration. But a queue marked dead can be
removed also when control leaves the app entry point on a PBX thread.
With this change, the queue is marked only not found, and at the end of
reload only the queues that are still not found are actually marked as
dead, so the dead flag is never reset, and set only on positively dead
queues.
ASTERISK-26755
Change-Id: I3a4537aec9eb8d8aeeaa0193407e3523feb004bf
Some (voicemail-related) tests API symlinks beep.gsm and other files
from ast_config_AST_VAR_DIR. It should use ast_config_AST_DATA_DIR.
ASTERISK-26740 #close
Change-Id: Id49c56fb9e16df64b1a2b829693ca7601252df89
In some cases member is added to pending_members, and the channel
is hung up before any extension state change. So the member would
stay in pending_members forever. So when we call do_hang, we
should also remove member from pending.
ASTERISK-26621 #close
Change-Id: Iae476b5c06481db18ebe0fa594b3e80fdc9a7d54
In 9785e8d0, app_echo was updated to relay video source updates to the
channel for the purposes of displaying video in WebRTC tests.
Unfortunately, this can cause a Kafkaesque nightmare if two or more
Local channels are in a bridge together where their ends are in
app_echo. When this situation occurs, a video update sent into app_echo
will cause the video update to be relayed to the other Local channels,
causing another round of video updates, etc. In not much time at all,
the channel length queues will be overwhelmed, channel alert pipes will
fail, and all hell will break loose as Asterisk merrily continues to
throw more video update requests onto the channels.
This patch updates app_echo to *only* relay a single video update. Once
a video update has been made, all further video updates are dropped.
This meets the intended purpose of the original patch: if we get a video
update and we're in app_echo, go ahead and ask the sender to update
themselves. However, once we've got that video stream sync'd up, don't
keep spamming the world.
Change-Id: I9210780b08d4c17ddb38599d1c64453adfc34f74
Given the scenario where multiple channels are dialed using Dial()
but the caller is picked up using PickupChan() all outgoing channels
except the channel specified to PickupChan() would be marked
as ringing until the call had been hung up.
When using the PickupChan application the channel executing the
application is swapped into place of another channel. As part
of this process the channel is answered. The Dial application
has explicit logic which checks if the channel is answered,
cancels all other outgoing channels, and bridges. This logic is
different than the normal logic that is executed when an outgoing
channel is answered. This different logic failed to publish dial
events stating that the other outgoing channels had been canceled.
As a result references to the outgoing channels were held onto by
the dial masquerade process until the call had been ended and
the channels had gone away. This would result in the channels
appearing in the "core show channels" list despite not being present
anymore and would also result in incorrect device state.
This change makes it so that this logic also publishes
dial events stating that the other outgoing channels have been
canceled.
ASTERISK-26549
Change-Id: Iea7168e6e82f7d4609ec0366153804e4f55ea64f
When executing the MailboxExists dialplan application and
MAILBOX_EXISTS dialplan function the passed in temporary voice
mailbox was not cleared, causing it to try to free garbage.
ASTERISK-26503 #close
Change-Id: Ie21ccfa1b80b9c59318e596f6b8e17da2b5a7cb3
When using Asterisk Realtime Architecture, empty fields are skipped and the
default values are used. If the "context" parameter in queue was set and then
cleared from the database, the old value remains in memory and it continues
to be used. This change initialize the "context" parameter with an empty value,
allowing clearing the parameter.
ASTERISK-26462 #close
Change-Id: I64be73d5044ce38dd02408bd0e53de965ef65905
Added needed UTF-8 checks before constructing json objects in various
files for strings obtained outside the system. In this case string values
from a channel driver's peer and not from the user setting channel
variables.
* aoc.c: Fixed type mismatch in s_to_json() for time and granularity json
object construction.
ASTERISK-26466
Reported by: Richard Mudgett
Change-Id: Iac2d867fa598daba5c5dbc619b5464625a7f2096
The pause reason is not always cleared when it should be cleared.
* Made set_queue_member_pause() always clear pause reason if not pausing
with a reason string.
Change-Id: I993dad19626ec017478a230e980989438b778c53
The "Q" option will set the cause on the unanswered channels when
another channel answers. It overrides the default of
ANSWERED_ELSEWHERE.
NOTE: chan_sip does not support setting the cause on a CANCEL to
anything other than ANSWERED_ELSEWHERE.
ASTERISK-26446 #close
Change-Id: I71742e0919aaa16784c30a2b2e73fbeed7672e47
The output of CLI "queue show" and AMI Queues action is truncated and
"failed to extend from 240 to 327" messages are generated if the queue
member and interface names are lengthy.
* Increase the string buffer size from 240 to 512 in order to accommodate
for more information fields added to the output since v1.8.
ASTERISK-26360 #close
Reported by: Richard Mudgett
Change-Id: Id99c03cf5362453b80491a4b3b0434cb67aa966d
Some configuration directives were not initialized on reload, and hence
were not reset to default if they were removed from followme.conf.
ASTERISK-26288 #close
Change-Id: Ief829e16374ad1e0ecfd63e6ee4923b5a1d1c150
In any scenario in which the callee is not connected to the caller, the
current code in app_dial will crash due to raising a Dial End Stasis
Message after the callee channel has been hung up. This patch corrects
the error by simply moving the explicit hangup of the callee (peer)
channel until after the dial end message.
ASTERISK-25691 #close
Change-Id: I816a414014424d0d8c80e2a3cbef13ef8c63798d
If the callee selects option '5' using the Dial application's privacy
(P) option, the DIALSTATUS is erroneously set to ANSWER. This option
reflects the callee sending the caller to VoiceMail one time; the call
is definitely *not* ANSWERed in such a scenario. With this patch, the
DIALSTATUS is instead set to NOANSWER, which is the same DIALSTATUS that
is set when the 'send to VoiceMail every time' option is set.
ASTERISK-25691
Change-Id: Iaf0c9f0fa00545e7366443875e2bb7d9a89a1358
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
Previously, the buffer used for MP3 streamed from HTTP servers had a size of
1 MB. For 8 kHz mono audio at 16 bit resolution, such a buffer covers about 1
minute. Only when the buffer is full does audio start to play.
For MP3 files streamed from a server, that is usually not a big deal as long as
the connection to the server is fast enough to supply that much data within a
second or two. For MP3 live streams however, it takes 1 minute to download 1
minute of audio, so without this change, app_mp3 wasn't really usable for MP3
live streams.
This commit changes the buffer size so that it covers 6 seconds of an MP3 file
streamed from a server and 0.5 seconds of an MP3 live stream. The latter is
identified by the use of a .m3u file extension.
app_mp3 so far only supported 8 kHz audio.
Now it always runs at the sample rate of the channel.
ASTERISK-26085 #close
Change-Id: Id1ee274733cd804a0edecf7450329b72f1235af0
As described in issue ASTERISK-26282 the AEL parser creates macros with
extension '~~s~~'. app_macro searches only for extension 's' so the
created extension cannot be found. with this patch app_macro searches for
both extensions and performs the right extension.
ASTERISK-26282 #close
Change-Id: I939aa2a694148cc1054dd75ec0c47c47f47c90fb
When dialing channels it is possible that they may not ever
leave the not in use state (Local channels in particular) by
the time we cancel them. If this occurs but we know they were
dialed we explicitly remove them from the pending members
container so that subsequent call attempts occur.
ASTERISK-26299 #close
Change-Id: I6ad0d17c36480c92cebf840626228ce3f7e4bd65
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
* Add some helpful <literal> and other embedded paragraph tags
* Document some of the lesser known channel variables set by Dial
* Add examples for some common Dial uses, along with some more
challenging but useful options
Change-Id: Ib2fb9301e8e044d14fbb2815ec64161f19bbfbc1
When a call forward attempt is made from a Queue member, the current
code will hang up the forwarding channel in an off-nominal condition
prior to raising the Stasis events informing the rest of Asterisk that
the call was forwarded. This will result in a slew of dreaded FRACKs,
most likely leading to a crash.
This patch modifies the code such that we don't hang up the forwarding
channel even in an off-nominal condition until we've safely raised the
Stasis messages.
ASTERISK-25797 #close
Change-Id: Ife5abed351691fd79105321636eaa8ea8dcdba38
On heavy loaded system with IMAP or DB storage,
'app_voicemail' taskprocessor queue could reach 500 scheduled tasks.
It could happen when the IMAP or DB server dies or is unreachable.
It could happen on startup when there are many (thousands)
realtime endpoints configured with unsolicited mwi.
If the taskprocessor queue reaches the high water level
then the alert is triggered and pjsip stops processing new requests
until the queue reaches the low water level to clear the alert.
This patch adds 2 new 'general' configuration options
to tune taskprocessor alert levels:
'tps_queue_high' - Taskprocessor high water alert trigger level.
'tps_queue_low' - Taskprocessor low water clear alert level
ASTERISK-26229 #close
Change-Id: I766294fbffedf64053c0d9ac0bedd3109f043ee8
If AST_TEST_DEFINE is not conditional to TEST_FRAMEWORK it produces dead
code. This places all existing unit tests into a conditional block if
they weren't already.
ASTERISK-26211 #close
Change-Id: I8ef83ee11cbc991b07b7a37ecb41433e8c734686
It is possible for a not in use state change to occur multiple
times causing a queue member to be removed from the pending call
container prematurely.
The first not in use state change will remove the queue member
from the container. At this moment the member may be called and
placed in the pending container. After this another not in use
state change can be received which will remove it from the
container. Despite being called at this point the code will
incorrectly see that there are no pending calls to it.
This change only removes it from the pending container if the
state has actually changed.
ASTERISK-26133 #close
patches:
app_queue.diff submitted by Richard Miller (license 5685)
Change-Id: Ie5a7f17a44f98e9159e9b85009ce3f8393aa78c0
Added a new channel variable FORWARDERNAME which indicates which
channel was responsible for a forwarding requests received on dial attempt.
Fixed a bug in the app_queue: FORWARD_CONTEXT is not used.
ASTERISK-26059 #close
Change-Id: I34e93e8c1b5e17776a77b319703c48c8ca48e7b2
Fixed some bugs:
- create dirpath when save downloading message from IMAP storage.
- create IMAP folder if not exists when saving to IMAP storage
- check if file successfully opened before write to it
- some IMAP checks
- remove non-standard flag 'Unseen'
etc
Change to debug IMAP mm_status log instead of verbose.
Remove unused X-Asterisk-VM-Caller-channel message header
for security reason. The clients should not know name of peer/endpoint.
ASTERISK-26045 #close
Change-Id: I7f83d88b69b36934e2539c114b9fb612deed971b
FollowMe with the option a records the name of the caller and plays it
to the callee. However it has failed to clean up that recorded file
as it tried to delete the file name without the '.sln' extension.
ASTERISK-26008 #close
Change-Id: I79d7b1be7d5cde57bf076d9389e2a8a4422776ec
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
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
Voicemail email addresses can be corrupt or voicemail
emails can end up being sent to the wrong email address if asterisk is
reading voicemail.conf during a reload and processing an email at the
same time. This patch always copies the struct that would otherwise only
be copied once.
ASTERISK-24463 #close
Reported by: John Campbell
Tested by: Etienne Lessard
Tested by: Andrew Nagy
Change-Id: I3a0643813116da84e2617291903d0d489b7425fb
When unloading the app_queue module the members in each queue are
destroyed and as part of this they are removed from the pending
members container. Unfortunately a crash would occur as the container
was destroyed before the members were removed.
This change tweaks ordering so the container destruction occurs
after the members are destroyed.
ASTERISK-16115
Change-Id: I48c728668c55aee3d05b751a5d450fb57e87f44b
It was possible for a queue member that is a member of at least 2 or more
queues to receive mulitiple calls at the same time. This happened because
of a race between when a member was being rung and when the device state
notified the other queue(s) member object of the state change.
This patch makes it so when a queue member is being rung it gets added to
a global pool of queue members. If that same member is tried again, e.g.
from another queue, and it is found to already exist in the pending member
container then it will not ring that member.
ASTERISK-16115 #close
Change-Id: I546dd474776d158c2b6be44205353dee5bac7e48
You cannot reference the passed in features struct after calling
ast_bridge_impart(). Even if the call fails.
Change-Id: I902b88ba0d5d39520e670fb635078a367268ea21
This module is used as part of testsuite tests to confirm
stuff works. I'm accordingly marking it as core as it is
required by those tests.
Change-Id: I558e7af7679b22b8ed641d7dd37ee4ca35b11e88
The test_voicemail_notify_endl test checks the end-of-line
characters of an email message to confirm that they are consistent.
The test wrongfully assumed that reading from the email message
into a buffer will always result in more than 1 character being
read. This is incorrect. If only 1 character was read the test
would go outside of the buffer and access other memory causing
a crash.
The test now checks to ensure that 2 or more characters are read
in ensuring the test stays within the buffer.
ASTERISK-25874 #close
Change-Id: Ic2c89cea6e90f2c0bc2d8138306ebbffd4f8b710
If try to move message to Cust1 (number 5)
the function 'save_to_folder' tries to create Greeting folder instead of Cust1.
This patch fixed it by setting GREETINGS_FOLDER = -1
ASTERISK-24927 #close
Change-Id: I03d1a761894bcc2d130ec9b003bbcddc28e25c51
Sometimes uw-imap function 'mail_fetchbody' returns huge len
which then pass to uw-imap function 'rfc822_base64'.
uw-imap tries to allocate huge memory and abort() on fail.
This patch check the len.
If the len more than max size (128 Mbytes) log error.
This patch also set variables len, newlen to avoid uninizialezed len.
This patch also check pointer returned by rfc822_base64.
ASTERISK-25899 #close
Change-Id: I4a0e7d655f11abef6a5224e2169df6d5c1f1caca
When using app_echo via WebRTC with VP8 video the video would appear
only after a few minutes, because there would be nothing to request
a full reference frame.
This fixes the problem in both ways:
- echos any VIDUPDATE frames received on the channel
- sends one such frame when first video frame is to be forwarded
This makes the echo work with Firefox and Chrome WebRTC implementation.
ASTERISK-25867 #close
Change-Id: I73bda87bf7532ee8bfb28d917045a21034908c1e
The configuration unsigned integer option handler sets flags for the
parser as if the option should be a signed integer (PARSE_INT32),
leading to errors on "out of range" values. Fix flags (PARSE_UINT32).
A fix to res_pjsip is also present which stops invalid flags from
being passed when registering sorcery object fields for qualify
status.
ASTERISK-25612 #close
Change-Id: I96b539336275e0e72a8e8033487d2c3344debd3e
This prevents pbx_core from hanging up the channel if the app isn't
registered.
ASTERISK-25846 #close
Change-Id: I63216a61f30706d5362bc0906b50b6f0544aebce
Channel masquerading had a conflict with autochannel locking.
When locking autochannel->channel, the channel is fetched from the
autochannel and then locked. During the fetch, the autochannel -- which
has no locks itself -- can be modified by someone who owns the channel
lock. That means that the value of autochan->channel cannot be trusted
until you hold the lock.
In practice, this caused problems with Local channels getting
masqueraded away while the ChanSpy attempted to get info from that
channel. The old channel which was about to get removed got locked, but
the new (replaced) channel got unlocked (no-op). Because the replaced
channel was now locked (and would never get unlocked), it couldn't get
removed from the channel list in a timely manner, and would now cause
deadlocks when iterating over the channel list.
This change checks the autochannel after locking the channel for changes
to the autochannel. If the channel had been changed, the lock is
reobtained on the new channel.
In theory it seems possible that after this fix, the lock attempt on the
old (wrong) channel can be on an already destroyed lock, maybe causing
a crash. But that hasn't been observed in the wild and is harder induce
than the current deadlock.
Thanks go to Filip Frank for suggesting a fix similar to this and
especially to IRC user hexanol for pointing out why this deadlock was
possible and testing this fix. And to Richard for catching my rookie
while loop mistake ;)
ASTERISK-25321 #close
Change-Id: I293ae0014e531cd0e675c3f02d1d118a98683def
Fix calculate of average time for talktime is wrong when is completed the
first call beacuse the time for talked would be that call.
ASTERISK-25800 #close
Change-Id: I94f79028935913cd9174b090b52bb300b91b9492
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
* changes:
app_confbridge: Add ability to get the muted conference state.
app_confbridge.c: Update CONFBRIDGE and CONFBRIDGE_INFO documentation.
app_confbridge: Make non-admin users join a muted conference muted.
* 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
Member lastcall time is updated later than member status. There was chance to
check wrapuptime for available member with wrong (old) lastcall time.
New boolean flag "in_call" is set to true right before connecting call, and
reset to false after update of lastcall time. Members with "in_call" set to true
are treat as unavailable.
ASTERISK-19820 #close
Change-Id: I1923230cf9859ee51563a8ed420a0628b4d2e500
In app_queue added value Paused Reason on QueueMemberStatus when a member
on queue is paused and the reason was set.
ASTERISK-25480 #close
Reporte by: Rodrigo Ramírez Norambuena
Change-Id: Ia5db503482f50764c15e2020196c785f59d4a68e
The menuselect conflict between app_voicemail and res_mwi_external
makes it hard to package 1 version of Asterisk. There no actual
build dependencies between the 2 so moving this check to runtime
seems like a better solution.
The ast_vm_register and ast_vm_greeter_register functions in app.c
were modified to return AST_MODULE_LOAD_DECLINE instead of -1 if there
is already a voicemail module registered. The modules' load_module
functions were then modified to return DECLINE instead of -1 to the
loader. Since -1 is interpreted by the loader as AST_MODULE_LOAD_FAILURE,
the modules were incorrectly causing Asterisk to stop so this needed
to be cleaned up anyway.
Now you can build both and use modules.conf to decide which voicemail
implementation to load.
The default menuselect options still build app_voicemail and not
res_mwi_external but if both ARE built, res_mwi_external will load
first and become the voicemail provider unless modules.conf rules
prevent it. This is noted in CHANGES.
Change-Id: I7d98d4e8a3b87b8df9e51c2608f0da6ddfb89247
If a caller hangs up before dial is executed within an AGI then the AGI
has likely eaten all queued frames before executing the dial in DeadAGI
mode. With the caller hung up and no pending frames from the caller's
read queue, dial would not know that the call has hung up until a called
channel answers. It is rather annoying to whoever just answered the
non-existent call.
Dial should not continue execution in DeadAGI mode, hangup handlers, or
the h exten.
* Added a check early in dial to abort dialing if the caller has hungup.
ASTERISK-25307 #close
Reported by: David Cunningham
Change-Id: Icd1bc0764726ef8c809f76743ca008d0f102f418
Update documentation to reflect that maximum_number_of_words
has functionality inconsistent with the variable name (and inconsistent
with prior documentation.)
Update documentation for silence_threshold, which previously implied
that it was measuring time, rather than noise averages in the sample.
Update the comments in amd.conf.sample.
ASTERISK-25639 #close
Change-Id: I4b1451e5dc9cb3cb06d59b6ab872f5275ba79093
If a call enters on a queue and the members on that queue are updated in
realtime (ex: using mysql inserting a new agent) the queue members are
never refreshed and the call will stay in the queue until other event occurs.
This happens only if this is the first call of the queue and there is no
agents servicing.
This patch prevent this issue, ensuring realtime members are updated if
there is one call in the queue and no available agents
ASTERISK-25442 #close
Change-Id: If1e036d013a5c1d8b0bf60d71d48fe98694a8682
The default value was never set for audio_buffers, causing bad
audio quality. This ensures the default is always set.
ASTERISK-25569 #close
Change-Id: I2d2ee3e644120b0f9f6ea6ab9286d7d590942a44
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
* When a call is answered and the outgoing channel name has changed then
force a connected line update because the channel is no longer the same.
The channel was masqueraded into by another channel. This is usually
because of a call pickup.
Note: Forwarded calls are handled in a controlled manner so the original
channel name is replaced with the forwarded channel.
ASTERISK-25423 #close
Reported by: John Hardin
Change-Id: Ie275ea9e99c092ad369db23e0feb08c44498c172
While the 'A' option is playing the announcement file allow the caller and
peer to exchange COLP update frames.
ASTERISK-25423
Reported by: John Hardin
Change-Id: Iac6cf89b56d26452c6bb88e9363622bbf23895f9
* When a call is answered and the outgoing channel name has changed then
force a connected line update because the channel is no longer the same.
The channel was masqueraded into by another channel. This is usually
because of a call pickup.
Note: Forwarded calls are handled in a controlled manner so the original
channel name is replaced with the forwarded channel.
ASTERISK-25423
Reported by: John Hardin
Change-Id: I2e01f7a698fbbc8c26344a59c2be40c6cd98b00c
Page uses the async method of dialing with the dial API. When a call gets
forwarded there is no calling channel available. If the predial handler
was set then the calling channel could not be put into auto-service
for the forwarded call because it doesn't exist. A crash is the result.
* Moved the callee predial parameter string processing to before the
string is passed to the dial API rather than having the dial API do it.
There are a few benefits do doing this. The first is the predial
parameter string processing doesn't need to be done for each channel
called by the dial API. The second is in async mode and the forwarded
channel is to have the predial handler executed on it then the
non-existent calling channel does not need to be present to process the
predial parameter string.
* Don't start auto-service on a non-existent calling channel to execute
the predial handler when the dial API is in async mode and forwarding a
call.
ASTERISK-25384 #close
Reported by: Chet Stevens
Change-Id: If53892b286d29f6cf955e2545b03dcffa2610981
The RECORDED_FILE variable is empty unless a '%d' is specified in the filename.
This patch makes it so the variable is always set to the filename.
ASTERISK-25410 #close
Change-Id: I4ec826d8eb582ae2ad184e717be8668b74d37653
When a queued caller transfers an agent to another extension sometimes the
raised AgentComplete event has a reason of "caller" and sometimes "transfer".
Since a transfer has taken place this should always be transfer. This occurs
because sometimes the stasis hangup event arrives before the transfer event
thus writing a different reason out.
With this patch, when a hangup event is received during a transfer it will
check to see if the channel that is hanging up is part of a transfer. If so
it will return and let the subsequently received transfer event handler take
care of the cleanup.
ASTERISK-25399 #close
Change-Id: Ic63c49bd9a5ed463ea7a032fd2ea3d63bc81a50d
During some transfer scenarios involving queues Asterisk would sometimes
crash when trying to obtain a channel snapshot (could happen on caller or
member channels). This occurred because the underlying channel had already
disappeared when trying to obtain the latest snapshot.
This patch adds a reference to both the member and caller channels that
extends to the lifetime of the queue'd call, thus making sure the channels
will always exist when retrieving the latest snapshots.
ASTERISK-25185 #close
Reported by: Etienne Lessard
Change-Id: Ic397fa68fb4ff35fbc378e745da9246a7b552128
* Extract set_queue_member_pause() from set_member_paused() for simpler
and more consistent code.
* Extract set_queue_member_ringinuse() from
set_member_ringinuse_help_members() for simpler code.
Change-Id: Iecc1f4119c63347341d7ea6b65f5fc4963706306
Setting the 'paused' and 'ringinuse' options on a queue member using the
dialplan function QUEUE_MEMBER did not behave the same way as the
equivalent dialplan applications or AMI actions.
* Made queue_function_mem_write() call the set_member_paused() and
set_member_value() for the 'paused' and 'ringinuse' options respectively.
A beneficial side effect is that the queue name is now optional and sets
the value in all queues the interface is a member.
* Update QUEUE_MEMBER XML documentation.
* Fix error checking in QUEUE_MEMBER() write.
ASTERISK-25215 #close
Reported by: Lorne Gaetz
Change-Id: I3a016be8dc94d63a9cc155295ff9c9afa5f707cb
Last time I checked, it's "Sangoma", not "Samgoma". Thanks to Brian
(GameGamer43) for pointing that out.
Change-Id: I43d7b196f6d7a2b2517b84915e3a8dfbc2894106
This patch updates a variety of Makefiles in Asterisk's build system to
remove .gcda and .gcno files when 'make clean' is executed. These files
are generated when '--enable-coverage' is passed to the Asterisk
configure script.
Change-Id: Ib70b41eea2ee2908885bff02e80faf9f40c84602
Currently when requesting a channel the native formats of the
calling channel are provided to the core for usage when dialing
the outbound channel. This occurs without holding the channel lock
or keeping a reference to the formats. This is problematic as
the channel driver may end up changing the formats during this time.
In the case of chan_sip this happens when an SDP negotiation
completes.
This change makes it so app_dial keeps a reference to the native
formats of the calling channel which guarantees that they will
remain valid for the period of time needed.
ASTERISK-25172 #close
Change-Id: I2f0a67bd0d5d14c3bdbaae552b4b1613a283f0db
The voicemail.conf mailbox key/value pair is defined as:
<mailbox>=[<password>[,<full-name>[,<email>[,<pager>[,<options>]]]]]
Where all fields in the value including the field values are optional.
Since the parsing code for the mailbox key/value pair is sloppy, this
patch tightens the parsing for the directory information.
* Renamed the 'pos' and 'bufptr' variables to 'name' and 'options'
respectively in search_directory_sub(). Those names make more sense.
* Made sure that search_directory_sub() is dealing with the voicemail.conf
mailbox options field if it even exists when looking for the 'hidefromdir'
and 'alias' options.
* Fix crash if a voicemail.conf mailbox is just
<mailbox>=<password>,<name> when the 'a' option is used. If there were no
fields after the name then the 'options' pointer was not checked for NULL.
* Fix users.conf alias processing if the 'a' option is used. The wrong
variable was used.
ASTERISK-25087 #close
Reported by: Chet Stevens
Change-Id: I86052ea77307beddddba5279824d39dc0d593374
Although ast_context_find, ast_context_find_or_create and
ast_context_destroy perform locking of the contexts table,
any context pointer can become invalid at any time that the
contexts table is unlocked. This change adds locking around
all complete operations involving these functions.
Places where ast_context_find was followed by ast_context_destroy
have been replaced with calls ast_context_destroy_by_name.
ASTERISK-25094 #close
Reported by: Corey Farrell
Change-Id: I1866b6787730c9c4f3f836b6133ffe9c820734fa
If a channel hangs up while an audio file is playing, there's
no need to clutter up the logs with a warning so suppress it
if ast_check_hangup returns true.
Also, change warning to debug/2 in file.c if writing a frame
fails. Same reasoning.
Change-Id: I2e66191af3c5b6e951c98e8f1c3fe3cf2cf7ed89
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
When completing voicemail playback of a message in the 'INBOX', the
message gets moved to the 'Old' messages folder. Without this patch, if
the 'Old' folder is already at its set limit, then the 'INBOX' message will
simply be deleted. With this patch, the flag to delete the message will be
removed if the save_to_folder function indicates that the message could
not be moved due to a full folder.
ASTERISK-25082 #close
Reported by: Jonathan Rose
Review: https://gerrit.asterisk.org/#/c/448/
Change-Id: I2be440a09f42e2d06d50975c40d1ad7f836ecb3f
This patch fixes EXITWITHTIMEOUT queue_log entry to always come with 3
parameters: position, original position and waiting time.
ASTERISK-25038 #close
Reported by: Etienne Lessard
Change-Id: I0c62045922e26bee2125e93aee1dee17eee79618
Confbridge dynamic profiles did not have a default profile unless you
explicitly used Set(CONFBRIDGE(bridge,template)=default_bridge). If a
template was not set prior to the bridge being created then some
options were left with no default values set. This patch makes it so
the default templates are set to the default bridge and user profiles.
ASTERISK-24749 #close
Reported by: philippebolduc
Change-Id: I1bd6e94b38701ac2112d842db68de63d46f60e0a
A potential problem that can arise is the following:
* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.
If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.
Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.
The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:
* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.
This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:
* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.
The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.
Address review feedback on gerrit.
* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c
ASTERISK-24958 #close
Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23
Although it only occurred once, a crash occurred when a queue attempted to
evaluate a queue penalty rule that appeared to have already been destroyed.
In many locations in app_queue, a test is done to see if qe->pr is NULL;
however, when we dispose of a queue's penalty rules, we don't set the pointer
to NULL after free'ing it. This patch does that to prevent any dangling
pointers from lingering on the queue object.
Review: https://reviewboard.asterisk.org/r/4522
ASTERISK-23319 #close
Reported by: Vadim
patches:
rb4552.patch submitted by Stefan Engström (License 6691)
........
Merged revisions 434448 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes several warnings pointed out by the clang compiler.
* chan_pjsip: Removed check for data->text, as it will always be non-NULL.
* app_minivm: Fixed evaluation of etemplate->locale, which will always
evaluate to 'true'. This patch changes the evaluation to use
ast_strlen_zero.
* app_queue:
- Fixed evaluation of qe->parent->monfmt, which always evaluates to
true. Instead, we just check to see if the dereferenced pointer
evaluates to true.
- Fixed evaluation of mem->state_interface, wrapping it with a call to
ast_strlen_zero.
* res_smdi: Wrapped search_msg->mesg_desk_term with calls to ast_strlen_zero.
Review: https://reviewboard.asterisk.org/r/4541
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4541.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434285 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an error occurs while writing to a web socket, the web socket is
disconnected and the event is logged. A side-effect of this, however, is that
any application on the other side waiting for a response from Stasis is left
hanging indefinitely (as there is no mechanism presently available for
notifying interested parties about web socket error states in Stasis).
To remedy this scenario, this patch introduces a new channel variable:
STASISSTATUS.
The possible values for STASISSTATUS are:
SUCCESS - The channel has exited Stasis without any failures
FAILED - Something caused Stasis to croak. Some (not all) possible
reasons for this:
- The app registry is not instantiated;
- The app requested is not registered;
- The app requested is not active;
- Stasis couldn't send a start message
ASTERISK-24802
Reported By: Kevin Harwell
Review: https://reviewboard.asterisk.org/r/4519/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433839 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
Valgrind found some memory leaks associated with ast_sockaddr_resolve().
Most of the leaks had already been fixed by earlier memory leak hunt
patches. This patch performs an audit of ast_sockaddr_resolve() and found
one more.
* Fix ast_sockaddr_resolve() memory leak in
apps/app_externalivr.c:app_exec().
* Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs
parameter for safety so the pointer will never be uninitialized on return.
The same goes for res/res_pjsip_acl.c:extract_contact_addr().
* Made functions that call ast_sockaddr_resolve() with RAII_VAR()
controlling the addrs variable use ast_free instead of ast_free_ptr to
provide better MALLOC_DEBUG information.
Review: https://reviewboard.asterisk.org/r/4509/
........
Merged revisions 433056 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch corrects the documentation for the AMD application. Specifically:
* It documents the maximum_word_length option, which limits the maximum allowed
length of a single utterance.
* It clarifies the AMDCAUSE values MAXWORDS and MAXWORDLENGTH. MAXWORDLENGTH
was documented as MAXWORDS, while MAXWORDS was undocumented.
Thanks to the issue reporter, Frank DiGennaro, for pointing out the issues.
ASTERISK-19470 #close
Reported by: Frank DiGennaro
........
Merged revisions 432918 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432920 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an IMAP backend is in use and greetings are set to be used, but aren't
present for a user in their IMAP folder, Asterisk will crash. This occurs
due to the mailstream being set to the 'greetings' folder and being left
in that particular state, regardless of the success/failure of the attempt
to access the folder the mailstream points to. Later access of the mailstream
assumes that it points to the 'INBOX' (or some other folder), resulting in
either a crash (if the greetings folder didn't exist and the mailstream is
invalid) or an inability to read messages from the 'INBOX' folder.
This patch restores the mailstream to its correct state after accessing the
greetings. This fixes the crash, and sets the mailstream to the state that
VoiceMailMain expects.
Note that while ASTERISK-23390 also contained a patch for this issue, the
patch on ASTERISK-24786 is the one being merged here.
Review: https://reviewboard.asterisk.org/r/4459/
ASTERISK-23390 #close
Reported by: Ben Smithurst
ASTERISK-24786 #close
Reported by: Graham Barnett
Tested by: Graham Barnett
patches:
app_voicemail.c.patch.SIGSEGV3rev2 uploaded by Graham Barnett (License 6685)
........
Merged revisions 432695 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using IMAP voicemail with FreePBX, you will often get ERROR messages
complaining about not being able to find a mailbox. This is due to how FreePBX
handles voicemail mailboxes. Unfortunately, app_voicemail has to consider this
a configuration error, as in any other system it would be indicative of
someone misconfiguring their system.
Regardless, a misconfiguration is a WARNING, and not an ERROR. This patch
demotes the message so that system administrators can hopefully reduce some
of the noise in their log files.
Note that in the original patch this was made into a NOTICE, but that's a
too forgiving.
ASTERISK-24790 #close
Reported by: Graham Barnett
patches:
app_voicemail.c.patch_noise uploaded by Graham Barnett (License 6685)
........
Merged revisions 432098 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432099 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When interfacing with Microsoft Exchange, custom headers will be returned as
all lower case. Currently, the IMAP header code will fail to parse the returned
custom headers, as it will be performing a case sensitive comparison. This can
cause playback of messages to fail, as needed information - such as origtime -
will not be present.
This patch updates app_voicemail's header parsing code to perform a case
insensitive lookup for the requested custom headers. Since the headers are
specific to Asterisk, e.g., 'x-asterisk-vm-orig-time', and headers should be
unique in an IMAP message, this should cause no issues with other systems.
ASTERISK-24787 #close
Reported by: Graham Barnett
patches:
app_voicemail.c.patch_MSExchange uploaded by Graham Barnett (License 6685)
........
Merged revisions 432012 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Test Event for MIXMONITOR_END - which signals that a MixMonitor has
completed - technically fired before the filestream was closed. If a test
used this to trigger a condition to verify that the file was written, it
could result in a race condition where the file size would not be what the
test expected.
Luckily, no tests were using this (although they should have been). Since the
test event needed to be moved after the point where the MixMonitor autochan has
been destroyed, the test event no longer emits the channel name. Luckily,
nothing needs it.
........
Merged revisions 431788 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431789 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
When the app_agent_pool module initially loads there is a race condition
between the thread loading agents.conf and the device state internal
processing thread. If the device state internal processing thread handles
the agent creation state updates before the thread that loaded agents.conf
registers the device state provider callback then the cached agent state
is "Invalid". When a consumer module like app_queue asks for the agent state
it gets the cached "Invalid" state instead of the real state from the provider.
* Moved loading the agents.conf configuration to the last thing setup by
app_agent_pool in load_module(). Now the device state provider callback
is registered before the config is loaded so the agent creation state
updates are guaranteed to get the initial device state.
* Removed some now redundant config cleanup on error in load_config().
* Added lock protection when accessing the device state in
agent_pvt_devstate_get() and eliminated the RAII_VAR() usage.
ASTERISK-24737 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4390/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431492 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
When issuing a 'confbridge list XXXX' CLI command, the resulting output no
longer displays the menu associated with a ConfBridge participant.
The issue was caused by ASTERISK-22760. When that patch was done, it removed
the copying of the menu name associated with the user from the actual user
profile.
This patch fixes the issue by copying the menu name over to the user profile
when the menu hooks are applied to the user. Since that function now does a
little bit more than just apply the hooks, the name of the function has been
changed to cover the copying of the menu name over as well.
In addition, there is a disparity between the menu name length as it is stored
on the conf_menu structure and the confbridge_user structure; this patch makes
the lengths match so that a strcpy can be used.
Review: https://reviewboard.asterisk.org/r/4372/
ASTERISK-24723 #close
Reported by: Steve Pitts
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431134 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel names should be different from other channels in the system while
the channel exists.
* Use a sequence number for CBRec channels instead of a random number
because the same random number could be picked again for the next CBRec
channel.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The MixMonitor m() option allows a recording to be pushed to a specific
voicemail mailbox. If the message is delivered to the mailbox's INBOX, however,
no MWI notification is currently raised.
This patch corrects the issue by properly calling notify_new_state from the
msg_create_from_file function. This will cause MWI to be triggered if the
message was placed in the mailbox's INBOX.
ASTERISK-24709 #close
Reported by: Gareth Palmer
patches:
app_voicemail-430919.patch uploaded by Gareth Palmer (License 5169)
........
Merged revisions 430920 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430921 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Dial application has some interesting options with the mid-call Macro (M)
and GoSub (U) options. If the MACRO_RESULT/GOSUB_RESULT returns specific
values, the Dial application will take some action upon the channels involved
in the dial operation (such as hanging up a particular party, etc.) The Dial
application ensures that a Stasis message is published in the event that
MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial operation, so
that there is a corresponding DialEnd event published in AMI/ARI for the
DialBegin event that preceeded it.
A bug exists where that same DialEnd event will be published on Stasis even if
the value returned in MACRO_RESULT/GOSUB_RESULT is not one that the Dial
application cares about. This causes two DialEnd events to be published - one
with the MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is all
sorts of wrong.
This patch fixes the bug by ensuring that we only publish a DialEnd message to
Stasis if the Dial application's mid-call Macro/GoSub returns something that
Dial cares about.
Review: https://reviewboard.asterisk.org/r/4336
ASTERISK-24682 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using ODBC or IMAP storage, temporary files created on the file system
must be disposed of using the DISPOSE macro. The DELETE macro will map to a
deletion function for the backend storage, but does not clean up any local
files created as a result of the operation.
When using voicemail with the operator and review options enabled, pressing
0 to enter the menu, followed by 1 to save the message, followed by any
other DTMF press to delete the message, will result in the temporary file
lingering on the file system.
This patch properly calls DISPOSE after the DELETE. This causes the local
file to be disposed of.
ASTERISK-24288 #close
Reported by: LEI FU
patches:
voicemail_odbc_review_fix.diff uploaded by LEI FU (License 6640)
........
Merged revisions 430795 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
v11: If a channel redirect to a macro exten of a macro that is active
happens, the redirect location doesn't get executed. Instead the original
macro location is restored and gets reexecuted.
v13: An additional effect happens if a parked call times out to an
extension in the macro that parked the call then the macro is reexecuted
instead of the expected park return location.
* Made not restore the macro calling location on an
AST_SOFTHANGUP_ASYNCGOTO.
* Increased the locked channel range when setting up the macro execution
environment to cover things that should be done while the channel is
locked.
* Removed unnecessary NULL tests before calling ast_free() in
_macro_exec().
ASTERISK-23850 #close
Reported by: Andrew Nagy
Review: https://reviewboard.asterisk.org/r/4292/
........
Merged revisions 430564 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430565 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
In r413586 (1.8) various casts were added to silence gcc 4.10 warnings.
Those fixes included things like:
-out += sprintf(out, "%%%02X", (unsigned char) *ptr);
+out += sprintf(out, "%%%02X", (unsigned) *ptr);
That works for low ascii characters, but for the high range that yields
e.g. FFFFFFC3 when C3 is expected.
This changeset:
- fixes those casts to use the 'hh' unsigned char modifier instead
- consistently uses %02x instead of %2.2x (or other non-standard usage)
- adds a few 'h' modifiers in various places
- fixes a 'replcaes' typo
- dev/urandon typo (in 13+ patch)
Review: https://reviewboard.asterisk.org/r/4263/
ASTERISK-24619 #close
Reported by: Stefan27 (on IRC)
........
Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The UW IMAP library is instrinsically not thread-safe, and relies upon higher
level applications to guarantee thread safety. For the most part, this is
provided by the vms object, which provides locking for individual streams.
Unfortunately, this is not sufficient for calls to mail_open which create the
IMAP stream. mail_open can, on some systems, call into a UW IMAP specific
function for determining the address of a system based on a hostname,
ip_nametoaddr.
In the ip6_unix implementation of this function, static variables are used
to hold parsing buffers. This can cause a crash if multiple threads attempt
to convert a hostname to an address at the same time. Locking on a single
mail stream is not sufficient to prevent simultaneous access to these static
variables.
In the IMAP library, this function can be called from the mail_open and
imap_status functions. As the imap_status function is not used by
app_voicemail, locking on access to mail_open is sufficient to prevent
any mangling of the buffers.
Review: https://reviewboard.asterisk.org/r/4188/
ASTERISK-24516 #close
Reported by: David Duncan Ross Palmer
Tested by: David Duncan Ross Palmer
patches:
ASTERISK-24516.diff uploaded by David Duncan Ross Palmer (License 6660)
........
Merged revisions 428863 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428864 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428865 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428687 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
When r428077 was made for ASTERISK-24522, it failed to take into account users
who are neither wait_marked nor end_marked. These users are *also* supposed to
hear the 'leader has left the conference' message. Granted, this behaviour is
a bit odd; however, that is how it used to work... and behaviour changes are
not good.
This patch ensures that if there are any 'normal' users present when the last
marked user leaves the conference, the message will still be played to them.
Note that this regression was caught by the Asterisk Test Suite's
confbridge_nominal test, which has a quirky combination of users.
........
Merged revisions 428113 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428114 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Consider the following:
- A marked user in a conference
- One or more end_marked only users in the conference
When the marked users leaves, we will be in the conf_state_multi_marked state.
This currently will traverse the users, kicking out any who have the end_marked
flags. When they are kicked, a full ast_bridge_remove is immediately called on
the channels. At this time, we also unilaterally set the need_prompt flag.
When the need_prompt flag is set, we then playback a sound to the bridge
informing everyone that the leader has left; however, no one is left in the
bridge. This causes some odd behaviour for the end_marked users - they are
stuck waiting for the bridge to be unlocked. This results in them waiting for
5 or 6 seconds of dead air before hearing that they've been kicked.
Unfortunately, we do have to keep the bridge locked while we're playing back
the 'leader-has-left' prompt. If there are any wait_marked users in the
conference, this behaviour can't be easily changed - but we do make the case
of the end_marked users better with this patch.
Review: https://reviewboard.asterisk.org/r/4184/
ASTERISK-24522 #close
Reported by: Matt Jordan
........
Merged revisions 428077 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 428078 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?
The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."
The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.
Review: https://reviewboard.asterisk.org/r/4135
........
Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An issue existed in r420577, which added multiple recipients to voicemail
emails. The patch, when looking at the intended recipients, looked ahead for
the '|' character inside a while loop which already had pulled out the
appropriate field parsing on the '|' character. This would cause it to skip
the recipients.
This patch fixes it such that it relies completely on the while loop to parse
through the e-mail fields.
Note that the original author of the patch looked at this fix and approved it.
ASTERISK-24250 #close
Reported by: abelbeck
patches:
voicemail-420577-to-comma-fix.diff uploaded by abelbeck (License 5903)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427585 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Made agent able to interrupt the alerting beep playback with DTMF. Any
digit can interrupt if the call does not need to be acknowledged. Only
the first digit of the acknowledgement can interrupt if the call needs to
be acknowledged. The agent interrupting the alerting playback builds on
the ASTERISK-24447 patch because it knows what digit interrupted the
playback and needs to be able to pass that digit to the DTMF hook digit
collection code.
ASTERISK-24257 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4123/
........
Merged revisions 427508 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch provides the capability to manipulate templates and categories
with non-unique names via AMI.
Summary of changes:
GetConfig and GetConfigJSON: Added "Filter" parameter: A comma separated list
of name_regex=value_regex expressions which will cause only categories whose
variables match all expressions to be considered. The special variable name
TEMPLATES can be used to control whether templates are included. Passing
'include' as the value will include templates along with normal categories.
Passing 'restrict' as the value will restrict the operation to ONLY templates.
Not specifying a TEMPLATES expression results in the current default behavior
which is to not include templates.
UpdateConfig: NewCat now includes options for allowing duplicate category
names, indicating if the category should be created as a template, and
specifying templates the category should inherit from. The rest of the
actions now accept a filter string as defined above. If there are non-unique
category names, you can now update specific ones based on variable values.
To facilitate the new capabilities in manager, corresponding changes had to be
made to config, most notably the addition of filter criteria to many of the
APIs. In some cases it was easy to change the references to use the new
prototype but others would have required touching too many files for this
patch so a wrapper with the original prototype was created. Macros couldn't
be used in this case because it would break binary compatibility with modules
such as res_digium_phone that are linked to real symbols.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4033/
........
Merged revisions 425383 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adding a mixmonitor to a channel causes the bridge to change technologies
from native to simple_bridge so the call can be recorded. However, when
the mixmonitor is stopped the bridge does not switch back to the native
technology.
* Added unbridge requests to reevaluate the bridge when a channel
audiohook is removed.
* Moved the unbridge request into ast_audiohook_attach() ensure that the
bridge reevaluates whenever an audiohook is attached. This simplified the
mixmonitor and chan_spy start code as well.
* Added defensive code to stop_mixmonitor_full() in case additional
arguments are ever added to the StopMixMonitor application.
* Made ast_framehook_detach() not do an unbridge request if the framehook
does not exist.
* Made ast_framehook_list_fixup() do an unbridge request if there are any
framehooks. Also simplified the loop.
ASTERISK-24195 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4046/
........
Merged revisions 424506 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes made during format improvements resulted in the
recording to voicemail option 'm' of the MixMonitor app
writing a zero length duration in the msgXXXX.txt file.
This change introduces a new function ast_ratestream(),
which provides the sample rate of the format associated
with the stream, and updates the app_voicemail function
for ast_app_copy_recording_to_vm to calculate the right
duration.
Review: https://reviewboard.asterisk.org/r/3996/
ASTERISK-24328 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423192 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The context/extension in a CDR is generally considered the destination of a
call. When looking at a 2-party call CDR, users will typically be presented
with the following:
context exten channel dest_channel app data
default 1000 SIP/8675309 SIP/1000 Dial SIP/1000,,20
However, if the Dial actually takes place in a Macro, the current behaviour
in 12 will result in the following CDR:
context exten channel dest_channel app data
macro-dial s SIP/8675309 SIP/1000 Dial SIP/1000,,20
The same is true of a GoSub:
context exten channel dest_channel app data
subs dial_stuff SIP/8675309 SIP/1000 Dial SIP/1000,,20
This generally makes the context/exten fields less than useful.
It isn't hard to preserve these values in the CDR state machine; however, we
need to have something that informs us when a channel is executing a
subroutine. Prior to this patch, there isn't anything that does this.
This patch solves this problem by adding a new channel flag,
AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
Macro or a GoSub. The CDR engine looks for this value when updating a Party A
snapshot; if the flag is present, we don't override the context/exten on the
main CDR object. In a funny quirk, executing a hangup handler must *not* abide
by this logic, as the endbeforehexten logic assumes that the user wants to see
data that occurs in hangup logic, which includes those subroutines. Since
those execute outside of a typical Dial operation (and will typically have
their own dedicated CDR anyway), this is unlikely to cause any heartburn.
Review: https://reviewboard.asterisk.org/r/3962/
ASTERISK-24254 #close
Reported by: tm1000, Tony Lewis
Tested by: Tony Lewis
........
Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422719 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
We need to unlock the audiohook before trying to lock
the channel, since the correct locking order is channel
then audiohook.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421882 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The same function, meetme_stasis_generate_msg, handles creating and publishing
Stasis message both when there are channels in the MeetMe conference and when
there are no channels in the conference. When the performance improvement was
made to use cached snapshots, this created a situation where Asterisk would
crash: obtaining a cached snapshot is not NULL tolerant.
This patch restores the previous implementation, which used a NULL safe set
of routines to produce a blob containing the channel snapshot (if available)
and information about the MeetMe conference.
ASTERISK-24234 #close
Reported by: Shaun Ruffell
Tested by: Shaun Ruffell
........
Merged revisions 421270 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Moving the test event raised when a file is played back (which occurred in
r421059) broke the ever loving snot out of the voicemail tests. This caused
duplicate test events to get raised, as app_voicemail and main/app were raising
events prior to call ast_streamfile. The voicemail tests did not enjoy getting
multiple events.
Since raising the playback event in ast_streamfile is far more useful to the
vast majority of tests, this patch keeps the call there and simply removes the
extraneous calls that duplicated the event.
........
Merged revisions 421125 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 421164 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 421165 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421166 65c4cc65-6c06-0410-ace0-fbb531ad65f3
George Joseph
Sean Bright
zuul
Joshua Colp
Robert Mordec
Richard Mudgett
Daniel Journo
rrittgarn
kkm
Tzafrir Cohen
Martin Tomec
Matt Jordan
Sebastian Gutierrez
Leandro Dardini
Mark Michelson
Michael Kuron
chrisderock
Alexei Gradinari
Corey Farrell
Jaco Kroon
Andrew Nagy
Kevin Harwell
DarkS
ibercom
Jacek Konieczny
Gianluca Merlo
Walter Doekes
Rodrigo Ramírez Norambuena
George Joseph
Martin Tomec
Dade Brandon
Carlos Oliva
Alec Davis
Alexander Traud
Jonathan Rose
Ivan Poddubny
Ashley Sanders
Scott Griepentrog