Added a new 'set_var' option for ast_sip_endpoint(s).  For each variable
specified that variable gets set upon creation of a pjsip channel involving
the endpoint.

(closes issue ASTERISK-22868)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/3095/
........

Merged revisions 404663 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404664 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Channel creation in Asterisk is broken up into two steps: requesting and calling.
In some cases a channel may be requested but never called. This happens in the
ChanIsAvail dialplan application for determining if something is reachable or
not. The PJSIP channel driver did not take this situation into account and
attempted to end a session that was never called out on.

The code now checks the session state to determine if the session has been
called out on and if not terminates it instead of ending it.

(closes issue ASTERISK-23074)
Reported by: Kilburn
........

Merged revisions 404652 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404653 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Hostnames specified in the 'match' field will be resolved and all addresses
returned. Each address will be added to the endpoint identifier for the
matching process.

Reported by: Rob Thomas
........

Merged revisions 404613 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404620 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When applying configuration for outbound registrations the 'server_uri' and
'client_uri' fields were not validated. The code will now confirm that they
exist and that they contain parseable SIP URIs.

Reported by: Andrew Nagy
........

Merged revisions 404592 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404593 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When destroying a subscription we remove the serializer from its dialog
and decrease its reference count. Depending on which thread dropped the
subscription reference count to 0 it was possible for this to occur in
a thread where it is not possible.

(closes issue ASTERISK-22952)
Reported by: Matt Jordan
........

Merged revisions 404553 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404554 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When wanting to pass *free as a function pointer, ast_free_ptr has to be used
instead of ast_free. This allows it to be compiled with MALLOC_DEBUG enabled.
........

Merged revisions 404531 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404532 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When we added support for specifying channel variables for an
origination, we didn't consider how that would interact with another
feature, namely specifying request parameters in a JSON request body.

The method of specifying channel variables (as a flat JSON object passed
in the JSON body) interferes with parsing parameters out of the request
body.

Unfortunately, fixing this would be a backward incompatible change. In
the interest of keeping the API sane and keeping our release schedule,
we're dropping the feature for specifying channel variables in the
origination request.

We will bring the feature back soon, as a backward compatible addition
to the API.

(closes issue ASTERISK-23051)
Review: https://reviewboard.asterisk.org/r/3088
........

Merged revisions 404509 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404512 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Implements the following cli commands:
pjsip list aors
pjsip list auths
pjsip list channels
pjsip list contacts
pjsip list endpoints
pjsip show aor(s)
pjsip show auth(s)
pjsip show channels
pjsip show endpoint(s)

Also...
Minor modifications made to the AMI command implementations to facilitate
reuse.

New function ast_variable_list_sort added to config.c and config.h to implement
variable list sorting.

(issue ASTERISK-22610)
patches:
  pjsip_cli_v2.patch uploaded by george.joseph (License 6322)
........

Merged revisions 404480 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404507 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When transferring to a dialplan extension that will not place any outbound
calls, the only control frames that the PJSIP REFER framehook will receive
are inconsequential (such as unhold or srcchange). As such, we shouldn't
allow for the reception of those types of frames prevent us from signaling
to the transferring party that the transfer has completed successfully once
voice frames are read.

Thanks to Jonathan Rose for pointing this out.
........

Merged revisions 404439 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404452 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The documentation for ARI already specifies that the device state resource when
used for subscribing for events is "deviceState", not "device_state". The code,
however, used "device_state"; although this was inconsistent as well in doxygen
comments in resource_applications.

Because the actual resource being subscribed to is /deviceStates/{device}/, it
makes sense for the resource type specifier to be deviceState.

Note that the key value in the events is still "device_state".
........

Merged revisions 404437 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404438 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Fixed several places where ao2_iterator_destroy() was not called.

* Fixed several iterator loop object variable reference problems.

* Fixed res_parking AMI actions returning non-zero.  Only the AMI logoff
action can return non-zero.

Review: https://reviewboard.asterisk.org/r/3087/
........

Merged revisions 404434 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404436 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Under normal conditions it is unlikely we will ever receive a response for a transaction
or dialog we don't know about but if any are received ignore them.
........

Merged revisions 404371 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404372 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The process for resending an INVITE with authentication involves restarting the UAC
session. We were incorrectly passing in that a new offer is being sent, causing the
SDP negotiation to get into a (technically speaking) funky state.
........

Merged revisions 404369 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404370 65c4cc65-6c06-0410-ace0-fbb531ad65f3

For the explanation, here is a copy-paste of the review board explanation:

Initially, it was discovered that performing an attended transfer of a
multiparty bridge with a PJSIP channel would cause a deadlock. A PBX thread
started a masquerade and reached the point where it was calling the fixup()
callback on the "original" channel. For chan_pjsip, this involves pushing a
synchronous task to the session's serializer. The problem was that a task ahead
of the fixup task was also attempting to perform a channel masquerade. However,
since masquerades are designed in a way to only allow for one to occur at a
time, the task ahead of the fixup could not continue until the masquerade
already in progress had completed. And of course, the masquerade in progress
could not complete until the task ahead of the fixup task had completed.
Deadlock.

The initial fix was to change the fixup task to be asynchronous. While this
prevented the deadlock from occurring, it had the frightful side effect of
potentially allowing for tasks in the session's serializer to operate on a
zombie channel.

Taking a step back from this particular deadlock, it became clear that the
problem was not really this one particular issue but that masquerades
themselves needed to be addressed. A PJSIP attended transfer operation calls
ast_channel_move(), which attempts to both set up and execute a masquerade. The
problem was that after it had set up the masquerade, the PBX thread had swooped
in and tried to actually perform the masquerade. Looking at changes that had
been made to Asterisk 12, it became clear that there never is any time now that
anyone ever wants to set up a masquerade and allow for the channel thread to
actually perform the masquerade. Everyone always is calling ast_channel_move(),
performs the masquerade itself before returning.

In this patch, I have removed all blocks of code from channel.c that will
attempt to perform a masquerade if ast_channel_masq() returns true. Now, there
is no distinction between setting up a masquerade and performing the
masquerade. It is one operation. The only remaining checks for
ast_channel_masq() and ast_channel_masqr() are in ast_hangup() since we do not
want to interrupt a masquerade by hanging up the channel. Instead, now
ast_hangup() will wait for a masquerade to complete before moving forward with
its operation.

The ast_channel_move() function has been modified to basically in-line the
logic that used to be in ast_channel_masquerade(). ast_channel_masquerade() has
been killed off for real. ast_channel_move() now has a lock associated with it
that is used to prevent any simultaneous moves from occurring at once. This
means there is no need to make sure that ast_channel_masq() or
ast_channel_masqr() are already set on a channel when ast_channel_move() is
called. It also means the channel container lock is not pulling double duty by
both keeping the container locked and preventing multiple masquerades from
occurring simultaneously.

The ast_do_masquerade() function has been renamed to do_channel_masquerade()
and is now internal to channel.c. The function now takes explicit arguments of
which channels are involved in the masquerade instead of a single channel.
While it probably is possible to do some further refactoring of this method, I
feel that I would be treading dangerously. Instead, all I did was change some
comments that no longer are true after this changeset.

The other more minor change introduced in this patch is to res_pjsip.c to make
ast_sip_push_task_synchronous() run the task in-place if we are already a SIP
servant thread. This is related to this patch because even when we isolate the
channel masquerade to only running in the SIP servant thread, we would still
deadlock when the fixup() callback is reached since we would essentially be
waiting forever for ourselves to finish before actually running the fixup. This
makes it so the fixup is run without having to push a task into a serializer at
all.

(closes issue ASTERISK-22936)
Reported by Jonathan Rose

Review: https://reviewboard.asterisk.org/r/3069
........

Merged revisions 404356 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404368 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In fax_detect_framehook() a null pointer reference can occur where a
voice frame is processed but no dsp is attached to the fax detection
structure.  The code block that rejects frames that detection cannot
be processed on is checking for dsp but falls through when it should
instead return, as this change implements.

(closes issue ASTERISK-22942)
Reported by: adomjan
Review: https://reviewboard.asterisk.org/r/3076/
........

Merged revisions 404351 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 404352 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404353 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change is in preparation for external MWI support.

Removed code from the system for normal mailbox handling that appends
@default to the mailbox identifier if it does not have a context.  The
only exception is the legacy hasvoicemail users.conf option.  The legacy
option will only work for app_voicemail mailboxes.  The system cannot make
any assumptions about the format of the mailbox identifer used by
app_voicemail.

chan_sip and chan_dahdi/sig_pri had the most changes because they both
tried to interpret the mailbox identifier.  chan_sip just stored and
compared the two components.  chan_dahdi actually used the box
information.

The ISDN MWI support configuration options had to be reworked because
chan_dahdi was parsing the box@context format to get the box number.  As a
result the mwi_vm_boxes chan_dahdi.conf option was added and is documented
in the chan_dahdi.conf.sample file.

Review: https://reviewboard.asterisk.org/r/3072/
........

Merged revisions 404348 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404350 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Original commit message by mmichelson (asterisk 12 r403311):

"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."

The above was initially committed and then reverted at r403398.  The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed.  Fixed by unreffing the channels.

Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel.  Fixed by
unlocking "other->chan"

(closes issue ASTERISK-22709)
Reported by: John Bigelow
........

Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change makes ast_channel_alloc return allocated channels
locked. By doing so no other thread can acquire, lock, and manipulate
the channel before it is completely set up.

(closes issue AST-1256)

Review: https://reviewboard.asterisk.org/r/3067/
........

Merged revisions 404204 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404210 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change adds a missing channel lock when adding a datastore
to a channel.
........

Merged revisions 404135 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 404136 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 404137 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404138 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Bridges have two new optional properties, a creator and a name.
Certain consumers of bridges will automatically provide bridges that
they create with these properties. Examples include app_bridgewait,
res_parking, app_confbridge, and app_agent_pool. In addition, a name
may now be provided as an argument to the POST function for creating
new bridges via ARI.

(closes issue AFS-47)
Review: https://reviewboard.asterisk.org/r/3070/
........

Merged revisions 404042 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404043 65c4cc65-6c06-0410-ace0-fbb531ad65f3

If object creation fails an error message will now be output with the id, type,
and configuration file.
........

Merged revisions 404029 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404030 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When creating channels via ARI, the current code fails to provide any default
format capabilities. For non-virtual channels this isn't really a problem -
the channels typically receive their capabilities as a result of the
underlying channel driver configuration. For virtual channels (such as Local
channels), the lack of any format capabilities causes the Asterisk core to
make some 'odd' choices with respect to the translation paths. The issue
reporter had some paths that had 3 hops on each channel leg, causing multiple
transcodings and some really crappy audio/performance.

By specifying a baseline of SLIN, we prevent that from occurring. Note that
this is what AMI does when it performs an Originate, as does res_clioriginate.

Review: https://reviewboard.asterisk.org/r/3068/

(issue ASTERISK-22962)
Reported by: Matt DiMeo
........

Merged revisions 403993 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403994 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Objects which are involved in SIP request creation and sending
now allow an outbound proxy to be specified. For cases where
an endpoint is used the outbound proxy specified there will
be applied.

(closes issue ASTERISK-22673)
Reported by: Antti Yrjola

Review: https://reviewboard.asterisk.org/r/3022/
........

Merged revisions 403811 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403812 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This change adds an event for when an originated call is redirected to
another target. This event contains the original channel and the newly
created channel. If a stasis subscription exists on the original originated
channel for a stasis application then a new subscription will also be
created on the stasis application to the redirected channel. This allows
the application to follow the call path completely.

(closes issue ASTERISK-22719)
Reported by: Joshua Colp

Review: https://reviewboard.asterisk.org/r/3054/
........

Merged revisions 403808 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403810 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........

Merged revisions 403796 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403797 65c4cc65-6c06-0410-ace0-fbb531ad65f3

There were still a few cases in which ATTENDEDTRANSFER and BLINDTRANSFER
wouldn't be set on channels involved with blind and attended transfers.
This would happen with features that were initialized by channel driver
specific mechanisms in multiparty calls. This patch resolves those cases
while attempted to keep the behavior for setting those variables as
consistent as possible.

(closes issue AFS-24)
Review: https://reviewboard.asterisk.org/r/3040/
........

Merged revisions 403781 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403783 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Added the ability to specify channel variables when creating/originating a
channel in ARI.  The variables are sent in the body of the request and should
be formatted as a single level JSON object.  No nested objects allowed.
For example: {"variable1": "foo", "variable2": "bar"}.

(closes issue ASTERISK-22872)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3052/
........

Merged revisions 403752 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403757 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Added the ability to have rules that are checked when adding and/or removing
channels to/from a bridge.  In this case, if a channel is currently recording
and someone attempts to add it to a bridge an "is recording" rule is checked,
fails, and a 409 conflict is returned.

Also command functions now return an integer value that can be descriptive of
what kind of problems, if any, occurred before or during execution.

(closes issue ASTERISK-22624)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2947/
........

Merged revisions 403749 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403750 65c4cc65-6c06-0410-ace0-fbb531ad65f3

In some cases messages need to be sent to a direct URI (sip:<ip address>). This
patch adds in that support by using a default outbound endpoint.  When sending
messages, if no endpoint can be found then the default one is used.

To facilitate this a new default_outbound_endpoint option was added to the
globals section for pjsip.conf.

Review: https://reviewboard.asterisk.org/r/2944/
........

Merged revisions 403680 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403687 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch adds CHANNEL read support for chan_pjsip. This allows the dialplan
to use the CHANNEL function on a chan_pjsip channel to obtain run-time
information about the channel from the PJSIP channel driver and the PJSIP
stack. This includes:
 * RTP information, including source/destination media addresses, whether or
   not the media is secure, held, and other properties.
 * RTCP information. This includes sets of parseable information, as well as
   individual statistic attriutes.
 * PJSIP information. This includes URIs, local/remote signalling addresses,
   whether or not the signalling is secure, and other properties.
 * The endpoint name. This can be used in conjunction with the PJSIP_ENDPOINT
   function to obtain more detailed endpoint information.

Review: https://reviewboard.asterisk.org/r/3038/
........

Merged revisions 403618 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403619 65c4cc65-6c06-0410-ace0-fbb531ad65f3

When switching to using a vector for authentication, I initialized
the vector for the artificial endpoint to be of size 1. However, this
does not result in AST_VECTOR_SIZE() returning 1 since there isn't
actually anything in the vector.

Rather than trifle with the vector by putting unnecessary elements in,
I simply changed the callback in res_pjsip_authenticator_digest.c to
explicitly report that the artificial endpoint requires authentication.

Thanks to Joshua Colp for pointing this out.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403605 65c4cc65-6c06-0410-ace0-fbb531ad65f3

res_sorcery_astdb.c: Fix get multiple records by regex.

* Fix sorcery_astdb_retrieve_regex() pattern matching.  Let the regexec()
function match the stored key values instead of having astdb prefilter
them.  Previoiusly you could only use a simple regex pattern when the
pattern began with '^'.
........

Merged revisions 403559 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403560 65c4cc65-6c06-0410-ace0-fbb531ad65f3

* Fix sorcery_astdb_retrieve_regex() pattern matching.  Let the regexec()
function match the stored key values instead of having astdb prefilter
them.  Previoiusly you could only use a simple regex pattern when the
pattern began with '^'.

* Fix off nominal memory leak in sorcery_astdb_retrieve_regex().
........

Merged revisions 403545 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403546 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Due to the way pjproject internally works it was possible for the
NAT module to not be invoked on messages with-in a session dialog.
This means that the various parts of the message would not get rewritten
with the source IP address and port.

This change uses a session supplement to add the NAT module
to the dialog on the first incoming or outgoing INVITE.

(closes issue ASTERISK-22941)
Reported by: Leif Madsen
........

Merged revisions 403510 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403511 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Since Asterisk has a vector API now, places where arrays are manually
resized don't really make sense any more. Since the auth work in PJSIP
was freshly-written, it was easy to reform it to use a vector.

Review: https://reviewboard.asterisk.org/r/3044



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403499 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Prior to this patch, res_fax_spandsp was conservative with how it initialized
the spandsp T.38 context. It would only initialize it if the driver thought
the current state was a T.38 fax. While this works fine in nominal situations,
in certain off nominal situations, res_fax_spandsp can believe that a T.38
fax will not occur when in fact one has started. In particular, this was
discovered when res_fax would fall back to audio after timing out on a T.38
upgrade. The SIP channel driver would continue to retry the re-INVITE and -
if the remote end responded after res_fax timed out with a 200 OK - a T.38
frame would be delivered to the res_fax stack when it no longer expected it.

As it turns out, there does not appear to be any downside to always
initializing the T.38 context, other than the actual memory allocation.
Since that avoids this off nominal situation (and others which are equally
likely hard to predict), this is the safest way to avoid this problem.

Much thanks to Torrey as well for providing a scenario that reproduces this
issue.

(closes issue ASTERISK-21242)
Reported by: Ashley Winters
Tested by: Torrey Searle
patches:
  always-init-t38.patch uploaded by awinters (License 6477)
  A_PARTY.xml uploaded by tsearle (License 5334)
........

Merged revisions 403449 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 403450 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 403458 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403466 65c4cc65-6c06-0410-ace0-fbb531ad65f3

If the CDR unregistration fails due to an inflight CDR, the
res_config_sqlite module needs to bail on unloading itself. Otherwise,
the config could be unloaded (including the CDR table name) while the
CDR engine posts a CDR to the still registered backend, resulting in
a crash.
........

Merged revisions 403435 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403436 65c4cc65-6c06-0410-ace0-fbb531ad65f3

........

Merged revisions 403398 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403404 65c4cc65-6c06-0410-ace0-fbb531ad65f3

The code for getting channel variables from ARI assumed that you needed
to lock the channel in order to properly execute functions and read
channel variables. Apparently, this is not the case, since any dialplan
function that puts the channel into autoservice deadlocks when
attempting to remove the channel from autoservice.
........

Merged revisions 403342 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403403 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Used a static wrapper around the offending function to alleviate the issue.

Reported by: rmudgett
........

Merged revisions 403377 from http://svn.asterisk.org/svn/asterisk/branches/12


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403378 65c4cc65-6c06-0410-ace0-fbb531ad65f3