r375757 attempted to resolve a race condition between multiple submissions of
CDRs while in batch mode from attempting to destroy the scheduled batch
submission by extending the batch CDR lock. Unfortunately, this causes a
deadlock between the pending CDR lock and the batch CDR lock. This patch
resolves the intent of r375757 by simply providing a new lock that protects
the scheduling of the batches. The original batch CDR lock is kept to protect
manipulation of the batch CDR settings, but has been placed such that it
is not held when the pending lock is held.

Thanks to Chase Venters for providing lock analysis on the issue.

(issue ASTERISK-21162)
Reported by: Chase Venters
........

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

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


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

This code caused a compiler warning when --enable-dev-mode was not used.
The warning was that this variable was set but not used.  That was indeed
the case as the only place this is used is as an argument to SKINNY_DEBUG
which is compiled out when not in dev mode.


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

When an SLA trunk is ringing (inbound call on the trunk) Asterisk will
make outbound calls to the stations that have that trunk.  If more than
one station answers the call at the same time, all channels other than
the first one to answer are left in a bad state.  The channel gets
leaked, is not connected to anything, and there's no way to get rid of
it.

We now properly clean up these losing channels by hanging up on them.
Since they lost the race, as we process their answer, there is no
ringing trunk for them to answer.
........

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

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


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

The CALLEDTON channel variable is set for incoming ISDN calls to the lower
7 bits of the Q.931 type-of-number/numbering-plan octet.  The
CALLERID(dnid-num-plan) should have the same value.

(closes issue ASTERISK-21248)
Reported by: rmudgett
........

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

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


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

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

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

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

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

HangupRequest and SoftHangupRequest are now ast_channel_blob Stasis
messages, with the cause code as an optional field in the blob.

NewCallerid now simply watches for changes in the callerid information
in channel snapshots, and creates the AMI event appropriately.

Since the original NewCallerid event honored the channelvars setting
in manager.conf, the channel variables configured there had to become
a part of the channel snapshot. These are now a part of every snapshot
based event, making the configuration description "every time a
channel-oriented event is emitted" less of a lie.

There a a few other changes wrapped up in here as well.

 * When ast_channel_topic() is given NULL for a channel, it returns
   the ast_channel_topic_all() topic instead of NULL. This can clean
   up a lot of NULL checking we're doing currently.
 * The fields Cause and Cause-txt were removed from the base channel
   information and put only on the Hangup events, since those fields
   are meaningless outside of a Hangup event.
 * Removed the pipe-delimiter processing of the channelvars field,
   since that's been deprecated forever.

(closes issue ASTERISK-21096)
Review: https://reviewboard.asterisk.org/r/2405/


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

........

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

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


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

Core modules don't honor <depend> flags in MODULEINFO, which broke jansson
if specified --with-jansson to configure.


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

A regression was accidentally introduced when allowing an optional ID to be used
when calling StopMixMonitor.  When we are unable to stop MixMonitor on a
channel, -1 is being returned which triggers the hangup of the channel.

This patch restores the prior behavior by returning 0 whether we were successful
or not.  It also allows the call from the manager to use the return code when
the action fails.

(closes issue ASTERISK-21294)
Reported by: daroz
Tested by: daroz
Patches:
  asterisk-21294-stop_mixmonitor_hangingup.diff Michael L. Young (license 5026)

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

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


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

When I moved res_json.c to json.c, I left the MODULE_INFO stuff in there,
which was interesting if you ran module show. I also forgot to call what
was in module_load() from asterisk main().


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383611 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

Unsubscribe from MWI stasis event on channel reload.

(closes issue ASTERISK-21216)
Reported by: wedhorn 
Tested by: snuffy, myself
Patches: 
    skinny-mwiind02.diff uploaded by snuffy (license 5024)


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

Thanks, rmudgett!


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

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

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

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

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


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

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

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


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

Because of the way that topics were handled when publishing, it was
possible to dispatch a message to a subscription after that
subscription had been unsubscribed such that the dispatched message
arrived at the callback after the callback had received its final
message. In callbacks that cleaned up user data, this would often cause
a segfault. This has been resolved by locking the topic during the
entirety of dispatch. To prevent long publishing and topic locking
times, forwarding subscriptions have been made to be standard
subscriptions instead of mailboxless subscriptions which were
dispatched at publishing time.


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

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

When using scoped locks, the unref of an AO2 object should happen after
the unlock occurs which requires usage of scoped refs.


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

........
  r383341 | dlee | 2013-03-19 10:57:29 -0500 (Tue, 19 Mar 2013) | 5 lines
  
  Removed codecs/g722/*.i on make clean
  ........
  
  Merged revisions 383340 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
  r383342 | dlee | 2013-03-19 10:58:33 -0500 (Tue, 19 Mar 2013) | 1 line
  
  Remove codecs/speex/*.i on make clean
........

Merged revisions 383341-383342 from http://svn.asterisk.org/svn/asterisk/branches/11


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

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

Remove MWI's dependency on the event system by moving it to
Stasis-core. This also introduces forwarding topic pools in Stasis-core
which aggregate many dynamically allocated topics into a single primary
topic.

Review: https://reviewboard.asterisk.org/r/2368/
(closes issue ASTERISK-21097)
Patch-by: Kinsey Moore


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

This change allows you to use XMPP buddy state in places where device state
can be used be used, such as dialplan hints. If at least one resource is
available the buddy is considered available. Now your phone can reflect
their IM status too!


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

........

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


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

Often times, when subscribing to a topic, one wants to handle
different message types differently. While one could cascade if/else
statements through the subscription handler, it is much cleaner to
specify a different callback for each message type. The
stasis_message_router is here to help!

A stasis_message_router is constructed for a particular stasis_topic,
which is subscribes to. Call stasis_message_router_unsubscribe() to
cancel that subscription.

Once constructed, routes can be added using
stasis_message_router_add() (or stasis_message_router_set_default()
for any messages not handled by other routes). There may be only one
route per stasis_message_type. The route's callback is invoked just as
if it were a callback for a subscription; but it only gets called for
messages of the specified type.

(issue ASTERISK-20887)
Review: https://reviewboard.asterisk.org/r/2390/


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

(issue ASTERISK-20887)



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

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

Unsubscribing things in Asterisk seems to very commonly follow with
NULLing out the variable that was unsubscribed. This change makes that
a bit simpler.


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

AMI, HTTP, and chan_sip all support TLS in some way, but none of them
support all the options that Asterisk's TLS core is capable of
interpreting. This prevents consumers of the TLS/SSL layer from setting
TLS/SSL options that they do not support.

This also gets tlsverifyclient closer to a working state by requesting
the client certificate when tlsverifyclient is set. Currently, there is
no consumer of main/tcptls.c in Asterisk that supports this feature and
so it can not be properly tested.

Review: https://reviewboard.asterisk.org/r/2370/
Reported-by: John Bigelow
Patch-by: Kinsey Moore
(closes issue AST-1093)
........

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

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


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

When a session timer expires during a dialog that has re-negotiated to T.38
and Asterisk is the refresher, Asterisk will send a re-INVITE with an SDP
containing audio media only. This causes some hilarity with the poor fax
session under weigh.

This patch corrects that by sending T.38 parameters if we are in the middle of
a T.38 session.

(closes issue ASTERISK-21232)
Reported by: Nitesh Bansal
patches:
  dont-send-audio-reinvite-for-sess-timer-in-t38-call.patch uploaded by nbansal (License 6418)
........

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

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


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

In certain situations, call files are not processed when using KQueue with
pbx_spool. Asterisk was sending an invalid timeout value when the spool
directory is empty, causing the call to kevent to error immediately. This
can create a tight loop, increasing the CPU load on the system.

(closes issue ASTERISK-21176)
Reported by: Carlton O'Riley
patches:
  kqueue_osx.patch uploaded by coriley (License 6473)
........

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

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


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

........

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

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


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

Not informing the RTP engine of the instance data creates shrapnel.

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

Push some cleanups upstream before testing another ticket.

(issue ASTERISK-20259)


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

When retrieving the parking lots from a MySQL database table, the current order
is "filename, cat_metric desc, var_metric asc, category".  If there are multiple
parking lots with the same cat_metric but different categories, everything is
being sorted on cat_metric first resulting in errors when loading the parking
lots.

This patch fixes the problem by sorting on the category field first, then the
cat_metric field.

(closes issue ASTERISK-21035)
Reported by: Alex Epshteyn
Patches:
  asterisk-21035-orderby.diff Michael L. Young (license 5026)
........

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

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


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

This commit updates some fields in the contributed realtime schema files to
handle IPv6 addresses.

(closes issue ASTERISK-21173)
Reported by: Torrey Searle
Patches:
  realtime_sql.patch Torrey Searle (license 5334)
  asterisk-21173-update-ip-fields.diff Michael L. Young (license 5026)
........

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

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


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

(closes issue ASTERISK-21156)
Reported by: amsoft2001
........

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


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