and GET /playback/{playbackId}.
This allows an external application to initiate playback of a sound on a
channel while the channel is in the Stasis application.
/play commands are issued asynchronously, and return immediately with
the URL of the associated /playback resource. Playback commands queue up,
playing in succession. The /playback resource shows the state of a
playback operation as enqueued, playing or complete. (Although the
operation will only be in the 'complete' state for a very short time,
since it is almost immediately freed up).
(closes issue ASTERISK-21283)
(closes issue ASTERISK-21586)
Review: https://reviewboard.asterisk.org/r/2531/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389587 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The caching topic (which refers to the message type) was created before the
message type. If the initial subscription message gets processed before
the type can be initialized, the assertion about using an uninitialized type
fires.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This may alleviate some of the CDR woes with originated channels, as CDRs
do like to know when a channel was originated. Eventually this will get
converted to be a channel flag, so its location is still good to know
post the great CDR shakeup of 2013.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r388005, macros were introduced to consistently define message
types. This added an assert if a message type was used either before
it was initialized or after it had been cleaned up. It turns out that
this assertion fires during shutdown.
This actually exposed a hidden shutdown ordering problem. Since
unsubscribing is asynchronous, it's possible that the message types
used by the subscription could be freed before the final message of
the subscription was processed.
This patch adds stasis_subscription_join(), which blocks until the
last message has been processed by the subscription. Since joining was
most commonly done right after an unsubscribe, a
stasis_unsubscribe_and_join() convenience function was also added.
Similar functions were also added to the stasis_caching_topic and
stasis_message_router, since they wrap subscriptions and have similar
problems.
Other code in trunk was refactored to join() where appropriate, or at
least verify that the subscription was complete before being
destroyed.
Review: https://reviewboard.asterisk.org/r/2540
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does two things:
* It fixes a bug where the outbound channel's application/data set by the
dialing API/app_dial is not communicated until the channel is hung up.
If that happens, AMI would incorrectly send a NewExten event immediately
after a Hangup. This isn't really AMI's fault, as the dialing APIs never
communicated the 'helpful' app/data on the outbound channel until it was
hungup.
* It makes public sending a stasis message about a change in channel state.
This is useful enough that - for now at least - it should be public. If
operations on a channel go to being more coarse-grained, this function
could be made private again.
Review: https://reviewboard.asterisk.org/r/2548
Note that this problem was found and reported by Matt DiMeo.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If DEBUG_THREADS is enabled __ast_rwlock_destroy causes a segfault while trying
to access a possible NULL t->track object. A NULL check has been added before
trying to access the memory.
(closes issue ASTERISK-21724)
Reported by: Corey Farrell
Fixed by: Corey Farrell
Patches:
ast_rwlock_destroy-segv.patch uploaded by Corey Farrell (license 5909)
........
Merged revisions 388838 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 388839 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388840 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The debug versions of ao2_ref() should only be used if REF_DEBUG is
enabled so nothing is written to /tmp/refs unexpectedly.
(closes issue ASTERISK-21785)
Reported by: abelbeck
Patches:
jira_asterisk_21785_v11.patch (license #5621) patch uploaded by rmudgett
Tested by: abelbeck
........
Merged revisions 388700 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CALL-ID (ie [C-00000074]) is missing when logging to syslog. This was just
an oversight when this feature was added.
* Add CALL-IDs when using syslog
(closes issue ASTERISK-21430)
Reported by: Nikola Ciprich
Tested by: Nikola Ciprich, Michael L. Young
Patches:
asterisk-21430-syslog-callid_trunk.diff by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2526/
........
Merged revisions 388605 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388617 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I've noticed when doing a graceful shutdown that the res_stasis_http.so
module gets unloaded before the modules that use it, which causes some
asserts during their unload.
While r386928 was a quick hack to get it to not assert and die, this
patch increases the use counts on res_stasis.so and res_stasis_http.so
properly. It's a bigger change than I expected, hence the review instead
of just committing it.
Review: https://reviewboard.asterisk.org/r/2489/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds a framework in res_stasis for handling events from
channel topics. JSON event generation and validation code is created
from event documentation in rest-api/api-docs/events.json to assist in
JSON event generation, ensure consistency, and ensure that accurate
documentation is available for ALL events that are received by
res_stasis applications.
The userevent application has been refactored along with the code that
handles userevent channel blob events to pass the headers as key/value
pairs in the JSON blob. As a side-effect, app_userevent now handles
duplicate keys by overwriting the previous value.
Review: https://reviewboard.asterisk.org/r/2428/
(closes issue ASTERISK-21180)
Patch-By: Kinsey Moore <kmoore@digium.com>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388275 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The <arpa/nameser_compat.h> was introduced way back in OS X Panther, which
itself was end-of-lifed back in 2007. We can assume that any OS X machine
we build on will need that header file :-)
Why bother removing it? The flag we're checking (__APPLE_CC__) is actually
Apple's build number. Self-compiled versions of GCC (such as installing the
latest version of GCC from homebrew) sets the value to 0, making it useless
for this sort of compile flaggery.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388045 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we first introduced the channel blob types, the JSON blobs were
self identifying by a required "type" field in the JSON object
itself. This, as it turns out, was a bad idea.
When we introduced the message router, it was useless for routing based
on the JSON type. And messages had two type fields to check: the
stasis_message_type() of the message itself, plus the type field in the
JSON blob (but only if it was a blob message).
This patch corrects that mistake by removing the required type field
from JSON blobs, and introducing first class stasis_message_type objects
for the actual message type.
Since we now will have a proliferation of message types, I introduced a
few macros to help reduce the amount of boilerplate necessary to set
them up.
Review: https://reviewboard.asterisk.org/r/2509
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An endpoint is an external device/system that may offer/accept
channels to/from Asterisk. While this is a very useful concept for end
users, it is surprisingly not a core concept within Asterisk itself.
This patch defines ast_endpoint as a separate object, which channel
drivers may use to expose their concept of an endpoint. As the channel
driver creates channels, it can use ast_endpoint_add_channel() to
associate channels to the endpoint. This updated the endpoint
appropriately, and forwards all of the channel's events to the
endpoint's topic.
In order to avoid excessive locking on the endpoint object itself, the
mutable state is not accessible via getters. Instead, you can create a
snapshot using ast_endpoint_snapshot_create() to get a consistent
snapshot of the internal state.
This patch also includes a set of topics and messages associated with
endpoints, and implementations of the endpoint-related RESTful
API. chan_sip was updated to create endpoints with SIP peers, but the
state of the endpoints is not updated with the state of the peer.
Along for the ride in this patch is a Stasis test API. This is a
stasis_message_sink object, which can be subscribed to a Stasis
topic. It has functions for blocking while waiting for conditions in
the message sink to be fulfilled.
(closes issue ASTERISK-21421)
Review: https://reviewboard.asterisk.org/r/2492/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds the ability for modules to add themselves as observers
to sorcery object types. Observers can be notified when objects are
created, updated, or deleted as well as when the object type is loaded or
reloaded. Observer notifications are done using a thread pool in a serialized
fashion so the caller of the sorcery API calls is minimally impacted.
This also adds the ability to create JSON changesets of a sorcery object.
Tests are also present to confirm all of the above functionality.
Review: https://reviewboard.asterisk.org/r/2477/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387662 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch:
* Cleans up some doxygen
* Prevents leaking the system level Stasis topics and messages
on exit (users of valgrind will be happier)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a reason the heap comparison functions like qsort(), and other
comparison functions specify <0, >0, and =0 for the return values.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387209 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Way back when in the dark days of Asterisk 1.8.9, blind transferring a call
in a context that included the 'h' extension would inadvertently execute the
hangup code logic on the transferred channel. This was a "bad thing". The fix
was to properly check for the softhangup flags on the channel and only execute
the 'h' extension logic (and, in later versions, hangup handler logic) if the
channel was well and truly dead (Jim).
Unfortunately, CDRs are fickle. Setting the softhangup flag when we detected
that the channel was leaving the bridge (but not to die) caused some crucial
snippet of CDR code, lying in ambush in the middle of the bridging code, to
not get executed. This had the effect of blowing away one of the CDRs that is
typically created during a blind transfer.
While we live and die by the adage "don't touch CDRs in release branches", this
was our bad. The attached patch restores the CDR behavior, and still manages to
not run the 'h' extension during a blind transfer (at least not when it's
supposed to).
Thanks to Steve Davies for diagnosing this and providing a fix.
Review: https://reviewboard.asterisk.org/r/2476
(closes issue ASTERISK-21394)
Reported by: Ishfaq Malik
Tested by: Ishfaq Malik, mjordan
patches:
fix_missing_blindXfer_cdr2 uploaded by one47 (License 5012)
........
Merged revisions 387036 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 387038 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387039 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change does the following:
1. Adds the sorcery realtime module
2. Adds unit tests for the sorcery realtime module
3. Changes the realtime core to use an ast_variable list instead of variadic arguments
4. Changes all realtime drivers to accept an ast_variable list
Review: https://reviewboard.asterisk.org/r/2424/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a system allows for its usage, Asterisk will use glob to help parse
Asterisk .conf files. The config file loading routine was leaking the memory
allocated by the glob() routine when the config file was in an unmodified
or invalid state.
This patch properly calls globfree in those off nominal paths.
(closes issue ASTERISK-21412)
Reported by: Corey Farrell
patches:
config_glob_leak.patch uploaded by Corey Farrell (license 5909)
........
Merged revisions 386672 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 386677 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch cleans up two things features:
* It properly unregisters the CLI commands that features registered
* It cancels and performs a pthread_join on the created parking thread. This
not only properly joins a non-detached thread, but also prevents disposing
of the parking lots prior to the parking thread completely exiting.
(closes issue ASTERISK-21407)
Reported by: Corey Farrell
patches:
features_shutdown-r2.patch uploaded by Corey Farrell (License 5909)
........
Merged revisions 386641 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 386642 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386676 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pimp_my_sip branch is being merged at this point because
it offers basic functionality, and from an API standpoint, things
are complete.
SIP work is *not* feature-complete; however, with the completion
of the SUBSCRIBE/NOTIFY API, all APIs (except a PUBLISH API) have
been created, and thus it is possible for developers to attempt
to create new SIP work.
API documentation can be found in the doxygen in the code, but
usability documentation is still lacking.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386540 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The two party bridging loops were changing the bridge peer pointers
without the channel locks held. Thus when ast_channel_massquerade()
tested and used the pointer there is a small window of opportunity for the
pointers to become NULL even though the masquerade code has the channels
locked.
(closes issue ASTERISK-21356)
Reported by: William luke
Patches:
jira_asterisk_21356_v11.patch (license #5621) patch uploaded by rmudgett
Tested by: William luke
........
Merged revisions 386256 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 386286 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386289 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The API itself is documented using Swagger, a lightweight mechanism for
documenting RESTful API's using JSON. This allows us to use swagger-ui
to provide executable documentation for the API, generate client
bindings in different languages, and generate a lot of the boilerplate
code for implementing the RESTful bindings. The API docs live in the
rest-api/ directory.
The RESTful bindings are generated from the Swagger API docs using a set
of Mustache templates. The code generator is written in Python, and
uses Pystache. Pystache has no dependencies, and be installed easily
using pip. Code generation code lives in rest-api-templates/.
The generated code reduces a lot of boilerplate when it comes to
handling HTTP requests. It also helps us have greater consistency in the
REST API.
(closes issue ASTERISK-20891)
Review: https://reviewboard.asterisk.org/r/2376/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386232 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In messages.c, there are several places in the code where we create a
tmp_tech_holder and pass that into an ao2_find call. Unfortunately, we
weren't initializing the rwlock on the tmp_tech_holder, which the hash
function was locking. It's apparently harmless, but still not the best
code.
This patch extracts all that copy/pasted code into two functions,
msg_find_by_tech and msg_find_by_tech_name, which properly initialize
and destroy the rwlock on the tmp_tech_holder.
Review: https://reviewboard.asterisk.org/r/2454/
........
Merged revisions 386006 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
