Joshua Colp [Tue, 12 Jan 2016 19:25:39 +0000 (13:25 -0600)]
Merge topic 'update_taskprocessor_commands' into 13
* changes:
Sorcery: Create human friendly serializer names.
Stasis: Create human friendly taskprocessor/serializer names.
taskprocessor.c: New API for human friendly taskprocessor names.
taskprocessor.c: Sort CLI "core show taskprocessors" output.
Mark Michelson [Tue, 12 Jan 2016 16:36:15 +0000 (10:36 -0600)]
res_sorcery_realtime: Remove leading ^ requirement.
res_sorcery_realtime's search-by-regex callback performed a check to
ensure that the passed-in regex began with a caret (^). If it did not,
then no results would be returned.
This callback only started to become used when "like" support was added
to PJSIP CLI commands. The CLI command for listing objects would pass an
empty regex ("") to the sorcery backend if no "like" statement was
present. For most sorcery backends, this resulted in returning all
objects. However, for realtime, this resulted in returning no objects.
This commit seeks to fix the regression by removing the requirement from
res_sorcery_realtime for the passed-in-regex to begin with a caret.
On a system with multiple ip addresses in the same subnet, if a
transport is bound to a specific ip address and endpoint/media_address
is set, the SIP/SDP will have the correct address in all fields but
the rtp stream MAY still originate from one of the other ip addresses,
most probably the "primary" ip address. This happens because
res_pjsip_sdp_rtp/create_rtp always calls ast_instance_new with
the "all" ip address (0.0.0.0 or ::).
The new option causes res_pjsip_sdp_rtp/create_rtp to call
ast_rtp_instance_new with the endpoint's media_address (if specified)
instead of the "all" address. This causes the packets to originate from
the specified address.
ASTERISK-25632
ASTERISK-25637 Reported-by: Olivier Krief Reported-by: Dan Journo
Change-Id: I3dfaa079e54ba7fb7c4fd1f5f7bd9509bbf8bd88
Kevin Harwell [Fri, 8 Jan 2016 21:22:05 +0000 (15:22 -0600)]
pbx: Deadlock between contexts container and context_merge locks
Recent changes (ASTERISK-25394 commit 2bd27d12223fe33b58c453965ed5c6ed3af7c4f5)
introduced the possibility of a deadlock. Due to the mentioned modifications
ast_change_hints now needs to keep both merge/delete and state callbacks from
occurring while it executes. Unfortunately, sometimes ast_change_hints can be
called with the contexts container locked. When this happens it's possible for
another thread to grab the context_merge_lock before the thread calling into
ast_change_hints does and then try to obtain the contexts container lock. This
of course causes a deadlock between the two threads. The thread calling into
ast_change_hints waits for the other thread to release context_merge_lock and
the other thread is waiting on that one to release the contexts container lock.
Unfortunately, there is not a great way to fix this problem. When hints change,
the subsequent state callbacks cannot run at the same time as a merge/delete,
nor when the usual state callbacks do. This patch alleviates the problem by
having those particular callbacks (the ones run after a hint change) occur in a
serialized task. By moving the context_merge_lock to a task it can now safely be
attempted or held without a deadlock occurring.
ASTERISK-25640 #close
Reported by: Krzysztof Trempala
This patch causes another problem and should not have been needed.
Before this patch, persistent_endpoint_contact_deleted_observer WAS
deleting the contact_status when ast_sip_location_delete_contact was
called. By deleting it yourself in ast_sip_location_delete_contact
it was gone before the observer could run and the observer therefore
was throwing an error and not sending stasis/AMI/statsd messages.
So, I don't think this was the cause of your original issue. I also
had verified the contact AMI and statsd lifecycle and it was working.
I'll double check now though.
ASTERISK-25675 Reported-by: Daniel Journo
Change-Id: Ib586a6b7f90acb641b0c410f659743ab90e84f1a
Richard Mudgett [Thu, 7 Jan 2016 01:00:27 +0000 (19:00 -0600)]
ccss.c: Replace space in taskprocessor name.
The CLI "core ping taskprocessor" command does not work very
well with taskprocessor names that have spaces in them. You
have to put quotes around the name so using tab completion
becomes awkward.
include/asterisk/time.h: Renamed global declaration:tv
Renamed global declaration:tv to dummy_tv_var_for_types,
which would oltherwise cause 'shadow' warnings when 'tv'
was declared as a local variable elsewhere.
Added comment to note that dummy_tv_var_for_types is never
really exported and only used as a place holder.
Mark Michelson [Thu, 7 Jan 2016 21:37:36 +0000 (15:37 -0600)]
PJSIP: Prevent deadlock due to dialog/transaction lock inversion.
A deadlock was observed where the monitor thread was stuck, therefore
resulting in no incoming SIP traffic being processed.
The problem occurred when two 200 OK responses arrived in response to a
terminating NOTIFY request sent from Asterisk. The first 200 OK was
dispatched to a threadpool worker, who locked the corresponding
transaction. The second 200 OK arrived, resulting in the monitor thread
locking the dialog. At this point, the two threads are at odds, because
the monitor thread attempts to lock the transaction, and the threadpool
thread loops attempting to try to lock the dialog.
In this case, the fix is to not have the monitor thread attempt to hold
both the dialog and transaction locks at the same time. Instead, we
release the dialog lock before attempting to lock the transaction.
There have also been some debug messages added to the process in an
attempt to make it more clear what is going on in the process.
Aaron An [Mon, 4 Jan 2016 10:26:55 +0000 (18:26 +0800)]
cel/cel_radius: Fix wrong pointer.
The macro ADD_VENDOR_CODE defined in the cel_radius.c should use the parameter
y not the address of y.
I capture the radius UDP packet via tcpdump, and the AV pairs are not correct,
then i review the source code and compare it with cdr/cdr_radius.c. Fix it and
it works.
ASTERISK-25647 #close
Reported by: Aaron An
Tested by: Aaron An
George Joseph [Tue, 5 Jan 2016 20:52:16 +0000 (13:52 -0700)]
asterisk.h: Add ASTERISK_REGISTER_FILE macro
The 11/13 branches and master use 2 different file version macros. 11/13
uses ASTERISK_FILE_VERSION but master uses ASTERISK_REGISTER_FILE. This
means a new file added to 11/13 can't just be cherry-picked to master
because the macro has to be changed.
To make cherry-picking possible, ASTERISK_REGISTER_FILE was added
to asterisk.h as a simple alias for ASTERISK_FILE_VERSION(__FILE__, NULL)
The "$Revision$" tag doesn't do anything since Asterisk moved to git so
just passing NULL as the verison works fine. asterisk.h was also
annotated to deprecate ASTERISK_FILE_VERSION and suggest using
ASTERISK_REGISTER_FILE for all new files.
Finally, 2 recent file additions, pbx_builtins.c and pbx_functions.c,
were modified to use the new macro to make sure it actually worked.
'core show file version' showed the correct output.
George Joseph [Tue, 5 Jan 2016 17:06:32 +0000 (10:06 -0700)]
stasis_cache_pattern: Backport to 13
Somehow stasis_cache_pattern got out of sync between 13 and master
and it was causing duplicate channel message issues in 13 when
related to a specific endpoint. I.E. from statsd,
'endpoints.PJSIP.1174.channels 0|g' was being emitted twice.
Backporting stasis_cache_pattern from master to 13 solved
the issue and running the unit and testsuite tests confirmed
that no new ones were created.
Martin Tomec [Tue, 29 Dec 2015 10:31:19 +0000 (11:31 +0100)]
app_queue: Add member flag "in_call" to prevent reading wrong lastcall time
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.
George Joseph [Wed, 30 Dec 2015 16:49:03 +0000 (09:49 -0700)]
voicemail: Move app_voicemail / res_mwi_external conflict to runtime
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.
Richard Mudgett [Fri, 4 Dec 2015 23:22:29 +0000 (17:22 -0600)]
app_dial: Immediately exit dial if the caller is already hung up.
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
Matt Jordan [Sat, 2 Jan 2016 16:26:04 +0000 (10:26 -0600)]
main/cdr: Allow setting properties on a finalized CDR if it is the last one
Prior to this patch, we explicitly disallowed setting any properties on a
finalized CDR. This seemed like a good idea at the time; in practice, it was
more restrictive.
There are weird and strange scenarios where setting a property on a finalized
CDR is definitely wrong. For example, we may Fork a CDR, finalizing the
previous one, then change a property. In said case, the old CDR is supposed
to now be 'immutable' (so to speak), and should not be updated. From the
perspective of the code, a forked CDR that is finalized is just finalized.
Hence why we decided these should not be updated.
In practice, it is much more common to want to set a property on a CDR in
the h extension or in a hangup handler. Disallowing a common scenario to make
an esoteric behaviour work isn't good. This patch fixes this by allowing
callers to set a property IF we are the last CDR in the chain. This preserves
the finalized CDR if it was forked, while allowing the more common case to
function.
Matt Jordan [Sat, 2 Jan 2016 16:23:39 +0000 (10:23 -0600)]
main/cdr: Set the end time on a CDR if endbeforehexten is Yes
Prior to this patch, the CDR engine attempted to set the end time on a CDR
that was executing hangup logic and with endbeforehexten set to Yes by
calling a function that inspects the properties on the Party A snapshot to
determine if we are ready to set the end time. That always failed. This is
because a Party A snapshot is not updated for CDRs that are executing hangup
logic with endbeforehexten=Yes.
Instead of calling a function that looks at the Party A snapshot, we just
simply set the end time on the CDR. This is safe to call multiple times, and is
safe to call at this point as we know that (a) we are executing hangup logic,
and (b) we are supposed to set the end time at this point.
George Joseph [Tue, 29 Dec 2015 01:18:01 +0000 (18:18 -0700)]
main/pbx: Move pbx_builtin dialplan applications to pbx_builtins.c
We joked about splitting pbx.c into multiple files but this first step was
fairly easy. All of the pbx_builtin dialplan applications have been moved
into pbx_builtins.c and a new pbx_private.h file was added. load_pbx_builtins()
is called by asterisk.c just after load_pbx().
A few functions were renamed and are cross-exposed between the 2 source files.
The cache_clear test was written to expect duplicate Stasis messages
sent from the technology endpoint to the all caching topic. This patch
fixes the test to no longer expect these duplicate messages.
Joshua Colp [Mon, 28 Dec 2015 20:02:19 +0000 (16:02 -0400)]
test_time: Provide a timeout when waiting.
The test_timezone_watch unit test is written to expect a
condition to be signaled when the inotify daemon thread runs.
There exists a small window where the test_timezone_watch
thread can signal the inotify daemon thread while it is not
reading on the underlying file descriptor. If this occurs
the test_timezone_watch thread will wait indefinitely for a
signal that will never arrive.
This change adds a timeout to the condition so it will return
regardless after a period of time.
George Joseph [Wed, 27 May 2015 18:22:39 +0000 (12:22 -0600)]
endpoint/stasis: Eliminate duplicate events on endpoint status change
When an endpoint is created, its messages are forwarded to both the tech
endpoint topic and the all endpoints topic. This is done so that various
parties interested in endpoint messages can subscribe to just the tech
endpoint and receive all messages associated with that particular technology,
as opposed to subscribing to the all endpoints topic. Unfortunately, when the
tech endpoint is created, it also forwards all of its messages to the all
topic. This results in duplicate messages whenever an endpoint publishes its
messages.
This patch resolves the duplicate message issue by creating a new function
for Stasis caching topics, stasis_cp_sink_create. In most respects, this acts
as a normal caching topic, save that it no longer forwards messages it receives
to the all endpoints topic. This allows it to act as an aggregation "sink",
while preserving the necessary caching behaviour.
ASTERISK-25137 #close Reported-by: Vitezslav Novy
ASTERISK-25116 #close Reported-by: George Joseph <george.joseph@fairview5.com> Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: Ie47784adfb973ab0063e59fc18f390d7dd26d17b
Dade Brandon [Fri, 25 Dec 2015 04:19:59 +0000 (20:19 -0800)]
res_http_websocket.c: prevent avoidable disconnections caused by write errors
Updated ast_websocket_write to encode the entire frame in to one
write operation, to ensure that we don't end up with a situation
where the websocket header has been sent, while the body can not
be written.
Previous to August's patch in commit b9bd3c14, certain network
conditions could cause the header to be written, and then the
sub-sequent body to fail - which would cause the next successful
write to contain a new header, and a new body (resulting in
the peer receiving two headers - the second of which would be
read as part of the body for the first header).
This was patched to have both write operations individually fail
by closing the websocket.
In a case available to the submitter of this patch, the same
body which would consistently fail to write, would succeed
if written at the same time as the header.
This update merges the two operations in to one, adds debug messages
indicating the reason for a websocket connection being closed during
a write operation, and clarifies some variable names for code legibility.
Matt Jordan [Sun, 13 Dec 2015 19:09:42 +0000 (13:09 -0600)]
res_pjsip_history: Add a module that provides PJSIP history for debugging
This patch adds a new module, res_pjsip_history, that provides a slightly
better way of debugging SIP message traffic on a busy Asterisk system. The
existing mechanisms all rely on passively dumping a SIP message to the CLI.
While this is perfectly fine for logging purposes and well controlled
environments, on many installations, the amount of SIP messages Asterisk
receives will quickly swamp the CLI. This makes it difficult to view/capture
those messages that you want to diagnose in real time.
This patch provides another way of handling this. When enabled, the module
will store SIP message traffic in memory. This traffic can then be queried
at leisure.
In order to make the querying useful, a CLI command has been implemented,
'pjsip show history', that supports a basic expression syntax similar to
SQL or other query languages. A small number of useful fields have been
added in this initial patch; additional fields can easily be added in
later improvements. Those fields are:
- number: The entry index in the history
- timestamp: The time the message was recieved
- addr: The source/destination address of the message
- sip.msg.request.method: The request method
- sip.msg.call-id: The Call-ID header
Note - this is a resurrection of the module initially proposed on Review Board
here: https://reviewboard.asterisk.org/r/4053/
Dade Brandon [Fri, 25 Dec 2015 15:56:44 +0000 (07:56 -0800)]
chan_sip.c: fix websocket_write_timeout default value
websocket_write_timeout was not being set to its default value
during sip config reload, which meant that prior to this commit,
1) the default value of 100 was not used, unless an invalid value
(or 1) was specified in sip.conf for websocket_write_timeout, and
2) if the websocket_write_timeout directive was removed from sip.conf
without a full restart of asterisk, then the previous value would
continue to be used indefinitely.
This essentially lead to a 0ms write timeout (the first write attempt
in ast_careful_fwrite must have succeeded) in websocket write requests
from chan_sip, unless websocket_write_timeout was explicitely set in sip.conf.
Changes to websocket_write_timeout still only apply to new websocket
sessions, after the sip reload -- timeouts on existing sessions are
not adjusted during sip reload.
Matt Jordan [Thu, 24 Dec 2015 18:19:51 +0000 (12:19 -0600)]
res/res_pjsip_location: Delete contact_status object when contact is deleted
In 450579e908, a change was made that removed the deletion of the
'contact_status' object when a 'contact' object is deleted in sorcery.
This unfortunately means that the 'contact_status' object persists, even when
something has explicitly removed a contact. The result is that the state of
the contact will not be regenerated if that contact is re-created, and the
stale state will be reported/used for that contact. It also results in
no ContactStatusChanged events being generated for either ARI or AMI.
This patch restores the deletion logic that was removed. Doing so now
results in the expected events being generated again.
Dade Brandon [Mon, 21 Dec 2015 03:33:02 +0000 (19:33 -0800)]
app_amd: Correct documentation to reflect functionality
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.
Dade Brandon [Fri, 18 Dec 2015 01:05:00 +0000 (17:05 -0800)]
res_rtp_asterisk: Resolve further timing issues with DTLS negotiation
Resolves an edge case dtls negotiation delay for certain networks which
somehow manage to drop the rtcp side's packet when these are both sent
ast_rtp_remote_address_set, causing it to have to time-out and restart
the handshake.
Move dtls pending bio flush in to it's own function, and call it from
ast_rtp_on_ice_complete, when we're rtp->ice, rather than when
ast_rtp_remote_address_set.
Keep the existing flush from the recent change to res_rtp_remote_address_set
if ice is not being used.
Carlos Oliva [Fri, 18 Dec 2015 15:54:41 +0000 (16:54 +0100)]
app_queue: update RT members when the 1st call joins a queue with no agents
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
Joshua Colp [Sat, 5 Dec 2015 16:01:55 +0000 (12:01 -0400)]
res_sorcery_memory_cache: Add support for a full backend cache.
This change introduces the configuration option 'full_backend_cache'
which changes the cache to be a full mirror of the backend instead
of a per-object cache. This allows all sorcery retrieval operations
to be carried out against it and is useful for object types which
are used in a "retrieve all" or "retrieve some" pattern.
Joshua Colp [Thu, 17 Dec 2015 16:25:47 +0000 (12:25 -0400)]
rtp_engine: Ignore empty filenames in DTLS configuration.
When applying an empty DTLS configuration the filenames in the
configuration will be empty. This is actually valid to do and
each filename should simply be ignored.
Joshua Colp [Mon, 14 Dec 2015 18:04:15 +0000 (14:04 -0400)]
json: Audit ast_json_* usage for thread safety.
The JSON library Asterisk uses, jansson, is not thread
safe for us in a few ways. To help with this wrappers for JSON
object reference count increasing and decreasing were added
which use a global lock to ensure they don't clobber over
each other. This does not extend to reference count manipulation
within the jansson library itself. This means you can't safely
use the object borrowing specifier (O) in ast_json_pack and
you can't share JSON instances between objects.
This change removes uses of the O specifier and replaces them
with the o specifier and an explicit ast_json_ref. Some cases
of instance sharing have also been removed.
Mark Michelson [Wed, 16 Dec 2015 17:28:14 +0000 (11:28 -0600)]
Alembic: Increase column size of PJSIP AOR "contact".
When running the PJSIP AMI "show_endpoint" test with automatic
conversion to realtime, the test would fail. This was because the AOR
"contact" column was sized at 40, and the configured contact was larger
than that.
This commit increases the size of the contact column to 255 characters.
server-pandora [Mon, 14 Dec 2015 19:53:20 +0000 (11:53 -0800)]
res_rtp_asterisk.c: Fix DTLS negotiation delays.
- Trigger pending DTLS packets to send out, once the RTP instance's remote
address is set.
- Avoids locking the DTLS structure unnecessarily by only doing this if
DTLS is passive.
- Add DTLS locks around the structurally sensitive calls in the SSL
portion of __rtp_recvfrom, since dtls_srtp_check_pending does not lock
inside of itself, and we're dealing with the SSL BIO in at least two
threads.
WebRTC channels may receive a DTLS handshake before
ast_rtp_remote_address_set is called, which causes there to be a pending
response to send out. Previous to 1ad827, this was handled by calling
dtls_srtp_check_pending on receipt of any RTP packet - a STUN or RTP
packet could trigger the pending handshake response. Since that was
rightfully removed, whenever the DTLS handshake is received before the
remote address is set, we would have to wait until another SSL packet
arrives.
As of Chrome M47's optimizations to their handshake process, WebRTC
conversations between Chrome M47+ and Asterisk, where Asterisk is passive,
experience a 1 second delay without this patch, because the SSL handshake
is received before ICE negotation stores the remote_address, and the next
SSL packet isn't received until after a 1 second timeout in Chrome, which
causes a new handshake request.
projects / thirdparty / asterisk.git / log
