When a text message was received any associated variable was not written to
the ARI TextMessageReceived event. This occurred because Asterisk only wrote
out "send" variables. However, even those "send" variables would fail ARI
validation due to a TextMessageVariable formatting bug.
Since it seems the TextMessageReceived event has never been able to include
actual variables it was decided to remove the TextMessageVariable object type
from ARI, and simply return a JSON object of key/value pairs for variables.
This aligns more with how the ARI sendMessage handles variables, and other
places in ARI.
ASTERISK-28755 #close
Change-Id: Ia6051c01a53b30cf7edef84c27df4ed4479b8b6f
The optional synchronization behavior created in
64906c4c9b is now the default for
MixMonitor.
* Add a new flag 'n' that allows for this behavior to be turned off
* Add a notice when the 'S' option is used indicating that it is no
longer necessary
Change-Id: I158987c475cda4e1ff1256dd0daccdd99df568b4
Although the wiki page for the new CHANGES and UPGRADE scheme
states that the files must have the ".txt" suffix, the READMEs
didn't.
Change-Id: I490306aa2cc24d6f014738e9ebbc78592efe0f05
(cherry picked from commit 7416703f04)
* The MailboxExists dialplan application was deprecated on 2006-09-26
in Asterisk 1.6.0 (commit ec83b11183)
* The MAILBOX_EXISTS dialplan function was deprecated on 2011-12-06 in
Asterisk 11.0.0 (commit fd64bb66f9)
Change-Id: I71cfc9d7b9217a37b802f4cc6ef2d57900b7398f
The QueueMemberPause AMI event includes two fields that return the
reason a member was paused.
* In release branches, deprecate Reason in favor of PausedReason.
* In master, remove the Reason field entirely.
ASTERISK-28349 #close
Reported by: Niksa Baldun
Change-Id: I01da58f2b0ab927baeee754870f62b51b7b3d296
* Made BridgeAdd not hangup the call if there is a problem.
* Reduced message level from warning to verbose for normal exception
cases.
* Added a loop safety check to BridgeAdd.
* Made BridgeAdd set BRIDGERESULT with the status when dialplan is
resumed.
Change-Id: I374d39b8a3edcc794eeb5c6b9f31a01424cdc426
If an AMI user without the "system" authorization calls the
Originate AMI command with the Originate application,
the second Originate could run the "System" command.
Action: Originate
Channel: Local/1111
Application: Originate
Data: Local/2222,app,System,touch /tmp/owned
If the "system" authorization isn't set, we now block the
Originate app as well as the System, Exec, etc. apps.
ASTERISK-28580
Reported by: Eliel Sardañons
Change-Id: Ic4c9dedc34c426f03c8c14fce334a71386d8a5fa
Asterisk headers are no longer installed and uninstalled
automatically when performing a "make install" or a
"make uninstall". To install/uninstall the headers, use
"make install-headers" and "make uninstall-headers".
The headers also continue to be uninstalled when performing a
"make uninstall-all".
Also corrects an issue where /usr/include/asterisk.h was never
being removed at all.
Change-Id: Ia7399f3a0203a4825fc4a9f43b9034dae9a2b643
Changes made to apps/Makefile to optionally build all three app_voicemail
variations at the same time: 1) file (default), 2) odbc, and 3) imap.
This functionality was requested by users. modules.conf.sample warns the
user to make sure only one voicemail is loaded at a time.
Change-Id: Iba3cd8ffb4b7e8b1c64a11dd383e1eafcd3ed0e7
Previously, when a Transfer (REFER) was performed, chan_pjsip would set
the TRANSFERSTATUS to SUCCESS when the REFER was queued up. This did not
reflect a successful/unsuccessful transfer the way chan_sip did.
Added a callback module to process the refer subscription information.
Now depends on res_pjsip_pubsub so call transfer progress can be monitored
and reported
ASTERISK-26968 #close
Reported-by: Dan Cropp
Change-Id: If6c27c757c66f71e8b75e3fe49da53ebe62395dc
This changes the way that we handle adding changes to CHANGES and
UPGRADE.txt. The reason for this is because whenever someone needed to
make a change to one of these files and someone else had already done
so, you would run into merge conflicts. With this new setup, there will
never be merge conflicts since all changes will be documented in the
doc/<file>-staging directory. The release script is now responsible for
merging all of these changes into the appropriate files.
There is a special format that these files have to follow in order to be
parsed. The files do not need to have a meaningful name, but it is
strongly recommended. For example, if you made a change to pjsip, you
may have something like this "res_pjsip_relative_title", where
"relative_title" is something more descriptive than that. Inside each
file, you will need a subject line for your change, followed by a
description. There can be multiple subject lines. The file may look
something like this:
Subject: res_pjsip
Subject: Core
A description that explains the changes made and why. The release
script will handle the bulleting and section separators!
You can still separate with new lines within your
description.
The headers ("Subject" and "Master-Only") are case sensative, but the
value for "Master-Only" ("true" or "True") is not.
For more information, check out the wiki page:
https://wiki.asterisk.org/wiki/display/AST/CHANGES+and+UPGRADE.txt
ASTERISK-28111 #close
Change-Id: I19cf4b569321c88155a65e9b0b80f6d58075dd47
This is the first step in changing the release process so that changes
made to the CHANGES and UPGRADE.txt files do not result in merge
conflicts every time multiple people modify these files. The changes
made will go in these new directories: doc/CHANGES-staging and
doc/UPGRADE-staging. The README.md files explain how things will work,
but here's a little overview. When you make a change that would go in
either CHANGES or UPGRADE.txt, this should instead be documented in a
new file in the doc/CHANGES-staging or doc/UPGRADE-staging directory,
respectively. The format will look like this:
Subject: res_pjsip
A description that explains the changes made and why. The release
script will handle the bulleting and section separators! The
'Subject:' header is case-sensitive.
You can still separate with new lines within your description.
Subject: res_ari
Master-Only: true
You can have more than one subject, and they don't have to be the
same! Also, the 'Master-Only' header should always be true and is
also case-sensitive (but the value is not - you can have 'true' or
'True'). This header will only ever be present in the master branch.
For more information, check out the wiki page:
https://wiki.asterisk.org/wiki/display/AST/CHANGES+and+UPGRADE.txt
This is an initial change for ASTERISK_28111. Functionally, this will
make no difference, but it will prep the directories for when the
changes from CHANGES and UPGRADE.txt are extracted.
Change-Id: I8d852f284f66ac456b26dcb899ee46babf7d15b6
