When implementing playback for stasis-http, the monolithicedness of
res_stasis really started to get in my way.
This patch breaks the major components of res_stasis.c into individual
files.
* res/stasis/app.c - Stasis application tracking
* res/stasis/control.c - Channel control objects
* res/stasis/command.c - Channel command object
This refactoring also allows res_stasis applications to be loaded as
independent modules, such as the new res_stasis_answer module.
The bulk of this patch is simply moving code from one file to another,
adjusting names and adding accessors as necessary.
Review: https://reviewboard.asterisk.org/r/2530/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This moves the JSON event generators out of the Stasis-HTTP modules and
into standalone JSON-related counterparts so that Stasis-HTTP and
res_stasis can depend on them without creating dependency cycles. This
also provides a future location for Swagger Model validator functions
once the generators for that code are written.
Review: https://reviewboard.asterisk.org/r/2534/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388668 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After the merge of support for the realtime sorcery module, extensions that
contained a pattern were not being found through odbc realtime. It was tracked
down to this one line that was advancing to the next variable list before it
should have been. The removal of this one line fixes this.
Tested this fix on my machine.
Received confirmation that this is the right fix from file on IRC.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388375 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
When we send out a CN packet (for instance, in the case of using rtpkeepalives),
we are not setting the payload code properly. Also, we are setting the marker
bit when we shouldn't be according to RFC 3389, section 4.
AST_RTP_CN is not defined by AST_FORMAT codes. Therefore, we should be using
ast_rtp_codecs_payload_code() rather than ast_rtp_codecs_payload_lookup().
11 and trunk already use the appropriate function.
* In 1.8, use ast_rtp_codecs_payload_code()
* Remove the setting of the marker bit
* Fix the debug message by incrementing the seqno after the debug message is set
in order to display the correct seqno that was sent out
(closes issue ASTERISK-21246)
Reported by: Peter Katzmann
Tested by: Peter Katzmann, Michael L. Young
Patches:
asterisk-21246-rtp-cng-payload-error_1.8_v2.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2500/
........
Merged revisions 388111 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 388112 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388113 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
In certain situations, when the RTP engine goes to send a DTMF end digit
it may be in a situation where the remote address is no longer available,
or the digit that was supposed to be sent is invalid. In such cases, we
need to clear the RTP counters appropriately. Otherwise, when the RTP
source is set again, we'll continue to think that we're in the middle of
sending a DTMF digit, which can confuse the remote party (signficantly).
(closes issue ASTERISK-21522)
Reported by: Corey Farrell
patches:
rtp_dtmf_process_end.patch uploaded by Corey Farrell (License 5909)
........
Merged revisions 387213 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 387216 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387220 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed crash when res_stasis_http is unloaded before the
implementation modules.
* Cleaned up test initialization for test_stasis_http.so.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386928 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
This patch updates the various res_sip modules with their proper menuselect
options and proper dependencies, such that Asterisk still has a snowball's
chance in hell of compiling without pjproject.
Much thanks to snuffy(-home|-work) for making everyone's life
easier with this patch.
Review: https://reviewboard.asterisk.org/r/2472/
(closes issue ASTERISK-21669)
Reported by: snuffy
patches:
xml-depends.diff uploaded by snuffy (license 5024)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to get people familiar with the Stasis message bus, it would
be useful to have something of a tutorial. Since I'm not clever enough
to think of some cool integration we could do with Twitter, I settled
for something that might actually be useful.
This patch adds a res_statsd.so module, which implements a basic
statsd[1] client. Statsd is a very simple statistics gathering server,
which can publish its results to a backend graphing engine, like
Graphite[2]. There are several different Statsd server
implementations[3], so you can pick what works best for your
environment.
The actual example of how to use the Stasis message bus is in
res_chan_stats.so. This module demonstrates how to use subscriptions
and the message router by monitoring messages and posting channels
stats to the statsd server.
A wiki page walking through res_chan_stats.so is forthcoming.
[1]: https://github.com/etsy/statsd/
[2]: http://graphite.readthedocs.org/en/latest/
[3]: http://joemiller.me/2011/09/21/list-of-statsd-server-implementations/
Review: https://reviewboard.asterisk.org/r/2460/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386624 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 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
There were several reports of deadlock when using
res_timing_pthread. Backtraces indicated that one thread was blocked
waiting for the write to the pipe to complete and this thread held
the container lock for the timers. Therefore any thread that wanted
to create a new timer or read an existing timer would block waiting
for either the timer lock or the container lock and deadlock ensued.
This patch changes the way the pipe is used to eliminate this source
of deadlocks:
1) The pipe is placed in non-blocking mode so that it would never
block even if the following changes someone fail...
2) Instead of writing bytes into the pipe for each "tick" that's
fired the pipe now has two states--signaled and unsignaled. If
signaled, the pipe is hot and any pollers of the read side
filedescriptor will be woken up. If unsigned the pipe is idle. This
eliminates even the chance of filling up the pipe and reduces the
potential overhead of calling unnecessary writes.
3) Since we're tracking the signaled / unsignaled state, we can
eliminate the exta poll system call for every firing because we know
that there is data to be read.
(closes issue ASTERISK-21389)
Reported by: Matt Jordan
Tested by: Shaun Ruffell, Matt Jordan, Tony Lewis
patches:
0001-res_timing_pthread-Reduce-probability-of-deadlocking.patch uploaded by sruffell (License 5417)
(closes issue ASTERISK-19754)
Reported by: Nikola Ciprich
(closes issue ASTERISK-20577)
Reported by: Kien Kennedy
(closes issue ASTERISK-17436)
Reported by: Henry Fernandes
(closes issue ASTERISK-17467)
Reported by: isrl
(closes issue ASTERISK-17458)
Reported by: isrl
Review: https://reviewboard.asterisk.org/r/2441/
........
Merged revisions 386109 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 386159 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the concept of ast_websocket_server to
res_http_websocket, allowing WebSocket connections on URL's more more
than /ws.
The existing funcitons for managing the WebSocket subprotocols on /ws
still work, so this patch should be completely backward compatible.
(closes issue ASTERISK-21279)
Review: https://reviewboard.asterisk.org/r/2453/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386020 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_enable_distributed_devstate is no longer applicable to how the
distributed device state system works and is no longer necessary.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the move from Asterisk's event system to Stasis, this makes
distributed device state aggregation always-on, removes unnecessary
task processors where possible, and collapses aggregate and
non-aggregate states into a single cache for ease of retrieval. This
also removes an intermediary step in device state aggregation.
Review: https://reviewboard.asterisk.org/r/2389/
(closes issue ASTERISK-21101)
Patch-by: Kinsey Moore <kmoore@digium.com>
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385860 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After some discussion on asterisk-dev, it was decided that the bulk of
the logic in app_stasis actually belongs in a resource module instead
of the application module.
This patch does that, leaves the app specific stuff in app_stasis, and
fixes up everything else to be consistent with that change.
* Renamed test_app_stasis to test_res_stasis
* Renamed app_stasis.h to stasis_app.h
* This is still stasis application support, even though it's no
longer in an app_ module. The name should never have been tied to
the type of module, anyways.
* Now that json isn't a resource module anymore, moved the
ast_channel_snapshot_to_json function to main/stasis_channels.c,
where it makes more sense.
Review: https://reviewboard.asterisk.org/r/2430/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385742 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch calculates the timestamp for outbound RTP when we don't have timing
information. This uses the same approach in res_rtp_asterisk. Thanks to both
Pietro and Tzafrir for providing patches.
(closes issue ASTERISK-19883)
Reported by: Giacomo Trovato
Tested by: Pietro Bertera, Tzafrir Cohen
patches:
rtp-timestamp-1.8.patch uploaded by tzafrir (License 5035)
rtp-timestamp.patch uploaded by pbertera (License 5943)
........
Merged revisions 385636 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 385637 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When MALLOC_DEBUG is enabled with res_config_ldap, issues (munmap_chunk:
invalid pointer errors) can occur as the memory is being allocated with
Asterisk's wrappers around malloc/calloc/free/strdup, as opposed to the
LDAP library's wrappers.
This patch uses the LDAP library's wrappers where appropriate, so that
compiling with MALLOC_DEBUG doesn't cause more problems than it solves.
Note that the patch listed below was modified slightly for this commit
to account for some additional memory allocation/deallocations.
(closes issue ASTERISK-17386)
Reported by: John Covert
Tested by: Andrew Latham
patches:
issue18789-1.8-r316873.patch uploaded by seanbright (License 5060)
........
Merged revisions 385190 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 385199 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch sets the protocols container provided by res_http_websocket to NULL
when the module gets unloaded and adds the necessary checks when adding/
removing a websocket protocol. This prevents some FRACKing on an invalid
pointer to the disposed container if a module that uses res_http_websocket is
unloaded after it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the API that binds the Stasis dialplan application to external
Stasis applications. It also adds the beginnings of WebSocket
application support.
This module registers a dialplan function named Stasis, which is used
to put a channel into the named Stasis app. As a channel enters and
leaves the Stasis diaplan application, the Stasis app receives a
'stasis-start' and 'stasis-end' events.
Stasis apps register themselves using the stasis_app_register and
stasis_app_unregister functions. Messages are sent to an application
using stasis_app_send.
Finally, Stasis apps control channels through the use of the
stasis_app_control object, and the family of stasis_app_control_*
functions.
Other changes along for the ride are:
* An ast_frame_dtor function that's RAII_VAR safe
* Some common JSON encoders for name/number, timeval, and
context/extension/priority
Review: https://reviewboard.asterisk.org/r/2361/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Updated test_uuid.c to test the new API call.
* Made system use the new API call to eliminate "10's of lines" where
used.
* Fixed untested ast_strdup() return in stasis_subscribe() by eliminating
the need for it. struct stasis_subscription now contains the uniqueid[]
string.
* Fixed some issues in exchangecal_write_event():
Create uid with enough space for a UUID string to avoid a realloc.
Fix off by one error if the calendar event provided a UUID string.
There is no need to check for NULL before calling ast_free().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When res_rtp_asterisk.c was altered to avoid attempting to apply
unprotect algorithms to non-audio RTP packets, the test used was
incorrect. This caused the audio packets to not be decrypted and
resulted in loud white noise on the other endpoint (or both endpoints
depending on the call legs involved). The test now properly checks the
version field in the RTP header to ensure that RTP and RTCP are
decrypted while other types of packets are not.
(closes issue ASTERISK-21323)
Reported by: andrea
Tested by: Kinsey Moore, andrea, John Bigelow
Patches:
whitenoise_fix.diff uploaded by Kinsey Moore
........
Merged revisions 384048 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 384049 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The format attribute resource for H.264 video performs an unsafe read against a
media attribute when parsing the SDP. The value passed in with the format
attribute is not checked for its length when parsed into a fixed length buffer.
This patch resolves the vulnerability by only reading as many characters from
the SDP value as will fit into the buffer.
(closes issue ASTERISK-20901)
Reported by: Ulf Harnhammar
patches:
h264_overflow_security_patch.diff uploaded by jrose (License 6182)
........
Merged revisions 383973 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch started out simply as fixing the bouncing tests introduced
in r382685, but required some other changes to give it a decent
implementation.
To fix the bouncing tests, the UserEvent and Newexten AMI events
needed to be refactored to dispatch via Stasis. Dispatching directly
to AMI resulted in those events sometimes getting ahead of the
associated Newchannel events, which would understandably confuse anyone.
I found that instead of creating a zillion different message types and
structures associated with them, it would be preferable to define a
message type that has a channel snapshot and a blob of structured data
with a small bit of additional information. The JSON object model
provides a very nice way of representing structured data, so I went
with that.
* Move JSON support from res_json.c to main/json.c
* Made libjansson-dev a required dependency
* Added an ast_channel_blob message type, which has a channel
snapshot and JSON blob of data.
* Changed UserEvent and Newexten events so that they are dispatched
via ast_channel_blob messages on the channel's topic.
* Got rid of the ast_channel_varset message; used ast_channel_blob
instead.
* Extracted the manager functions converting Stasis channel events to
AMI events into manager_channel.c.
(issue ASTERISK-21096)
Review: https://reviewboard.asterisk.org/r/2381/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383579 65c4cc65-6c06-0410-ace0-fbb531ad65f3