When a config file is read, an unescaped semicolon signals comments which are
stripped from the value before it's stored. Escaped semicolons are then
unescaped and become part of the value. Both of these behaviors are normal
and expected. When the config is serialized either by 'dialplan save' or
AMI/UpdateConfig however, the now unescaped semicolons are written as-is.
If you actually reload the file just saved, the unescaped semicolons are
now treated as start of comments.
Since true comments are stripped on read, any semicolons in
ast_variable.value must have been escaped originally. This patch
re-escapes semicolons in ast_variable.values before they're written to
file either by 'dialplan save' or config/ast_config_text_file_save which
is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting
issues nearby in pbx_config.c
Tested-by: George Joseph
ASTERISK-20127 #close
Review: https://reviewboard.asterisk.org/r/4132/
........
Merged revisions 427275 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427276 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When merging from 12 to 13 there were conflicts,
I mistakenly had the loop run ast_closestream(others[0])
when it should be ast_closestream(others[x]).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427181 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel is imparted to a bridge, the invocation of the function may
provide an ast_bridge_features struct. Upon passing this to ast_bridge_impart,
the caller must assume that ownership has passed to the function, as in all
paths the function destroys the struct prior to returning (as its purpose is
to configure the behavior of the channel while in the bridge). On one off
nominal path - where the channel already has a PBX thread - the struct was not
being destroyed.
This patch fixes that glitch.
ASTERISK-24437 #close
Reported by: Scott Griepentrog
........
Merged revisions 426431 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426432 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix the AMI Status action read and write translation path strings from
growing for each channel in the status event list by reseting the ast
string given to ast_translate_path_to_str() to fill in the given
translation path.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@426079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two aspects to the vulnerability:
(1) res_jabber/res_xmpp use SSLv3 only. This patch updates the module to use
TLSv1+. At this time, it does not refactor res_jabber/res_xmpp to use the
TCP/TLS core, which should be done as an improvement at a latter date.
(2) The TCP/TLS core, when tlsclientmethod/sslclientmethod is left unspecified,
will default to the OpenSSL SSLv23_method. This method allows for all
encryption methods, including SSLv2/SSLv3. A MITM can exploit this by
forcing a fallback to SSLv3, which leaves the server vulnerable to POODLE.
This patch adds WARNINGS if a user uses SSLv2/SSLv3 in their configuration,
and explicitly disables SSLv2/SSLv3 if using SSLv23_method.
For TLS clients, Asterisk will default to TLSv1+ and WARN if SSLv2 or SSLv3 is
explicitly chosen. For TLS servers, Asterisk will no longer support SSLv2 or
SSLv3.
Much thanks to abelbeck for reporting the vulnerability and providing a patch
for the res_jabber/res_xmpp modules.
Review: https://reviewboard.asterisk.org/r/4096/
ASTERISK-24425 #close
Reported by: abelbeck
Tested by: abelbeck, opsmonitor, gtjoseph
patches:
asterisk-1.8-jabber-tls.patch uploaded by abelbeck (License 5903)
asterisk-11-jabber-xmpp-tls.patch uploaded by abelbeck (License 5903)
AST-2014-011-1.8.diff uploaded by mjordan (License 6283)
AST-2014-011-11.diff uploaded by mjordan (License 6283)
........
Merged revisions 425987 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When refactoring CDRs to use the configuration framework, a 'whoops' was
introduced where the CDR batch size was used when rescheduling a batch,
as opposed to the time duration. This patch corrects that obvious mistake.
ASTERISK-24426 #close
Reported by: Shane Blaser
........
Merged revisions 425735 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425736 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With MALLOC_DEBUG the /main/config config_basic_ops test was causing a
SEGV while doing an ast_category_delete in an ast_category_browse loop.
Apparently this never worked but was also never tested. I removed the
test, added 2 notes to config.h indicating that it's not supported and
added a few lines of code to ast_category_delete to prevent the SEGV
should someone attempt it in the future.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4078/
........
Merged revisions 425525 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tasks that were marked for pending deletion in the scheduler would be moved to
the cache for later reuse, but after being recycled the deleted mark wouldn't
be removed resulting in fresh tasks being deleted without reason... and
immediately moved back into the cache where they could be reused again. This
could cause horrendous things to happen in just about anything that used a
scheduler.
ASTERISK-24321 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4071/
........
Merged revisions 425503 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Masquerades into and out of channels that are involved in a dial operation
don't create the expected dial end event. The missing dial end event goes
against the model for things like CDRs and generating Dial end manager
actions and such.
There are four cases:
1) A channel masquerades into the caller channel. The case happens when
performing a blonde transfer using the channel driver's protocol.
2) A channel masquerades into a callee channel. The case happens when
performing a directed call pickup.
3) The caller channel masquerades out of dial. The case happens when
using the Bridge application on the caller channel.
4) A callee channel masquerades out of dial. The case happens when using
the Bridge application on a peer channel.
As it turned out, all four cases need to be handled instead of just the
first one.
ASTERISK-24237
Reported by: Richard Mudgett
ASTERISK-24394 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4066/
........
Merged revisions 425430 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425455 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
When a smart bridge operation occurs and a bridge transitions from one
technology to another the old technology is provided the channels formerly
in it and told that they are leaving. Unfortunately the bridge provided
along with them is incomplete. The bridge, despite there being channels in it,
contains none. This forces technology implementations to have additional
logic when channels are leaving or to store their own duplicated
state.
This change makes the bridge more complete so it contains the expected
channels. Now that the bridge is complete special logic within
bridge_native_rtp is no longer needed and has been removed.
Review: https://reviewboard.asterisk.org/r/4057/
........
Merged revisions 425242 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@425243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch makes res_phoneprov more modular so other modules (like pjsip)
can provide configuration information instead of res_phoneprov relying solely
on users.conf and sip.conf. To accomplish this a new ast_phoneprov public API
is now exposed which allows config providers to register themselves, set
defaults (server profile, etc) and add user extensions.
* ast_phoneprov_provider_register registers the provider and provides callbacks
for loading default settings and loading users.
* ast_phoneprov_provider_unregister clears the defaults and users.
* ast_phoneprov_add_extension should be called once for each user/extension
by the provider's load_users callback to add them.
* ast_phoneprov_delete_extension deletes one extension.
* ast_phoneprov_delete_extensions deletes all extensions for the provider.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/3970/
........
Merged revisions 424963 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk 13+, any given message type is not guaranteed to exist even
if Asterisk comes up correctly since creation of the message type could
be declined. The indexer should not prevent Asterisk from starting
under these conditions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424833 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When message type creation is declined via stasis.conf, certain
operations log errors assuming that the declined type is being used
before initialization or after destruction. These error messages get
quite spammy for oft used message types and should not be logged in the
first place since the message type is validly NULL.
Reported by: Matt DiMeo
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Formats within a capabilities structure are addressed starting at 0, not 1.
Assuming 1 causes it to exceed an array.
ASTERISK-24389 #close
Reported by: Kevin Harwell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424752 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If SendMessage encounters an error (such as incorrect input provided to the
action), it will currently return -1. Actions should only return -1 if the
connection to the AMI client should be closed. In this case, SendMessage
causing the client to disconnect is inappropriate.
This patch causes the action to return 0, which simply causes the action to
fail.
Review: https://reviewboard.asterisk.org/r/4024
ASTERISK-24354 #close
Reported by: Peter Katzmann
patches:
sendMessage.patch uploaded by Peter Katzmann (License 5968)
........
Merged revisions 424690 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 424691 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Using the Bridge application to bridge a channel that is executing an
applicaiton such as Wait results in a lingering Surrogate channel in the
CLI "core show channels" output even though it has already hungup.
* Fix bridge_exec() to not hold onto the current_dest_chan ref once it has
been put into the bridge.
* Eliminated bridge_exec()'s use of RAII_VAR().
ASTERISK-24224 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4041/
........
Merged revisions 424668 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424669 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
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424472 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects some issues introduced in the responses to the
CoreShowChannels AMI command as well as adding documentation for the
responses. The command in Asterisk 12 was missing the following fields:
Duration, Application, ApplicationData, and BridgedChannel and
BridgedUniqueID (replaced with BridgeId).
ASTERISK-24262 #close
Reported by: Mitch Claborn
Review: https://reviewboard.asterisk.org/r/4040/
........
Merged revisions 424423 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@424424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r423414 (13) / r423415 (trunk), an API call that determines if a format
capability structure is empty was added. This returns true if the format
capability structure is completely empty or "none". A check for this was added
in channel.c's set_format call. Unfortunately, when this check was true, it
returned from the function while still holding the channel lock. This caused
the CDR unit tests - which have a tendency to create channels with no formats -
to deadlock. Whoops.
This patch unlocks the channel on the off-nominal path.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423641 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change gives framehooks a reverse-direction masquerade callback in
addition to chan_fixup_cb similar to the callback added to datastores
to handle the same situation. The new callback provides the same
parameters as the fixup callback, but is called on the new channel's
framehooks before moving framehooks from the old channel to the new
channel. This gives the framehooks an oppurtunity to decide whether
they should remain on the new channel or be removed.
This new callback is used to prevent the PJSIP T.38 framehook from
remaining on a masqueraded channel if the new channel is not also a
PJSIP channel. This was causing a crash when a local channel was
masqueraded into a PJSIP channel and the framehook was executed on the
local channel since the channel's tech private data was not structured
as expected.
Review: https://reviewboard.asterisk.org/r/4001/
........
Merged revisions 423503 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function acts like strsep with three exceptions...
* The separator is a single character instead of a string.
* Separators inside quotes are treated literally instead of like separators.
* You can elect to have leading and trailing whitespace and quotes
stripped from the result and have '\' sequences unescaped.
Like strsep, ast_strsep maintains no internal state and you can call it
recursively using different separators on the same storage.
Also like strsep, for consistent results, consecutive separators are not
collapsed so you may get an empty string as a valid result.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3989/
........
Merged revisions 423476 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423478 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Make astob2 REF_DEBUG output an invalid object line when an invalid ao2
object ref/unref is attempted. This is similar to the
constructor/destructor lines.
* Fixed refcounter.py to handle skewed objects that have
constructor/destructor states.
* Made refcounter.py highlight the invalid ao2 object refs by putting them
in their own section of the processed output file.
* Made refcounter.py highlight unreffing an object by more than one that
results in a negative ref count and the object being destroyed. The
abnormally destroyed object is reported in the invalid and finalized
object sections of the output.
Review: https://reviewboard.asterisk.org/r/3971/
........
Merged revisions 423349 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 423400 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423416 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Empty here means that there are no formats in the format_cap structure
or the only format in it is the "none" format.
I've added calls to check the emptiness of a format_cap in a few places
in order to short-circuit operations that would otherwise be pointless
as well as to prevent some assertions from being triggered in cases
where channels with no formats are used.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@423414 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
ast_play_and_record_full() has a parameter called "acceptdtmf" that is a
string of acceptable DTMF digits that may be pressed by a caller to end
and accept the recording.
ARI uses this function in order to perform recording, and it provides
options for what is passed as acceptdtmf to ast_play_and_record_full().
By default, ARI passes an empty string, with the intention that no DTMF
can be used to end the recording.
The problem is that ast_play_and_record_full() attempts to be "helpful"
by setting "#" as the acceptdtmf if an empty string or NULL pointer
has been passed in. With ARI, this results in unexpected behavior
occurring if you have attempted to intercept "#" yourself in order
to perform some other manipulation of the live recording.
This change removes the "helpful" behavior by no longer accepting
"#" as a default acceptdtmf if none is specified by the caller of
ast_play_and_record_full(). This makes the ARI scenario work as
expected.
The other callers of ast_play_and_record_full() are app_voicemail
and app_minivm, and in both cases, they pass an explicit "#" to
ast_play_and_record_full() as acceptdtmf, so they are unaffected
by this change.
........
Merged revisions 422964 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422965 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a CDR is forked, a new CDR is created and appended to the CDR chain for
the Party A. The forked CDR starts life off as a clone of the last
non-finalized for the particular Party A. In the past, merely copying over
the snapshots for Party A/Party B would be sufficient. However, as the CDRs
now contain cached information from Party A - specifically application/data,
context, and extension - we need to copy that over during a fork as well.
Huzzah for unit tests catching this when the context/extension were derived
from a cached value on the CDR instead of on Party A.
........
Merged revisions 422769 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
