This patch adds AMI event documentation for the Cdr and CEL AMI events.

Note that while these events do share fields with each other and with other
channel related events, they do not contain all of the fields in a standard
channel snapshot, nor is the description of the fields identical. As such,
the patch opts for documentation for each field, for each event.

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

ASTERISK-24671 #close
Reported by: Dan Jenkins
........

Merged revisions 430862 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The Dial application has some interesting options with the mid-call Macro (M)
and GoSub (U) options. If the MACRO_RESULT/GOSUB_RESULT returns specific
values, the Dial application will take some action upon the channels involved
in the dial operation (such as hanging up a particular party, etc.) The Dial
application ensures that a Stasis message is published in the event that
MACRO_RESULT/GOSUB_RESULT returns a value that kills the dial operation, so
that there is a corresponding DialEnd event published in AMI/ARI for the
DialBegin event that preceeded it.

A bug exists where that same DialEnd event will be published on Stasis even if
the value returned in MACRO_RESULT/GOSUB_RESULT is not one that the Dial
application cares about. This causes two DialEnd events to be published - one
with the MACRO_RESULT/GOSUB_RESULT and another with "ANSWERED" - which is all
sorts of wrong.

This patch fixes the bug by ensuring that we only publish a DialEnd message to
Stasis if the Dial application's mid-call Macro/GoSub returns something that
Dial cares about.

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

ASTERISK-24682 #close
Reported by: Matt Jordan
........

Merged revisions 430842 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When the RTCP reports are created, the NTP timestamps are stored as strings,
as JSON does not have an integer type long enough to store the value. However,
on 32-bit systems, a signed long may overflow for some portion of the
timestamp.

This patch corrects the overflow by formatting the timestamps as unsigned
longs.
........

Merged revisions 430840 from http://svn.asterisk.org/svn/asterisk/branches/13


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

ARI: Fixed crash that occurred when updating a bridge when the optional query parameter 'name' was not supplied.

Prior to this changeset, posting to the: /ari/bridges/{bridgeId} endpoint without specifying a value for the [name] query parameter, would crash Asterisk if the bridge you are attempting to create (or update) had the same ID as an existing bridge. The internal mechanism of the POST operation interpreted a null value for name, thus resulting in an error condition that crashed Asterisk.

ASTERISK-24560 #close
Reported By: Kinsey Moore

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

Merged revisions 430818 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Calling ast_channel_bridge_peer() cannot be done while holding any channel
locks.  The reported issue hit the deadlock in chan_iax2, but an audit of
the ast_channel_bridge_peer() calls found three more locations where the
same deadlock can occur.

* Made CHANNEL(peer), res_fax, and the SNMP agent not call
ast_channel_bridge_peer() with any channel locked.  For CHANNEL(peer) I
had to rework the logic to not hold the channel lock.

* Made chan_iax2 no longer call ast_channel_bridge_peer().  It was done
for legacy reasons that no longer apply.

* Removed the iax.conf forcejitterbuffer option.  It is now always enabled
when the jitterbuffer option is enabled.  If you put a jitter buffer on a
channel it will be on the channel.

ASTERISK-24600 #close
Reported by: Jeff Collell

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

Merged revisions 430817 from http://svn.asterisk.org/svn/asterisk/branches/13


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

On Debian based systems, the install_prereq tool uses a search command on
Debian that results in selecting both 64-bit and 32-bit packages. Besides the
waste of disk space, this can actually cause aptitude use 100% of memory on a
VM with 1GB of RAM as it tried to work out all of the 32-bit package
dependencies.

This patch filters out the 32-bit packages on a 64-bit machine, and leaves
32-bit machines alone.

ASTERISK-24048 #close
Reported by: Ben Klang
Tested by: Ben Klang, Matt Jordan
patches:
  install_prereq_64-bit_compat.patch uploaded by Ben Klang (License 5876)
........

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

Merged revisions 430799 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When using ODBC or IMAP storage, temporary files created on the file system
must be disposed of using the DISPOSE macro. The DELETE macro will map to a
deletion function for the backend storage, but does not clean up any local
files created as a result of the operation.

When using voicemail with the operator and review options enabled, pressing
0 to enter the menu, followed by 1 to save the message, followed by any
other DTMF press to delete the message, will result in the temporary file
lingering on the file system.

This patch properly calls DISPOSE after the DELETE. This causes the local
file to be disposed of.

ASTERISK-24288 #close
Reported by: LEI FU
patches:
  voicemail_odbc_review_fix.diff uploaded by LEI FU (License 6640)
........

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

Merged revisions 430796 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When a hint gets created, any subsequent device or presence
state changes result in extension status events getting sent
out to interested parties. However, at the time of hint creation,
no such event gets sent out, so watchers of extension state are
potentially left in the dark until the first state change after
hint creation.

Patch contributed by John Hardin (License #6512)
........

Merged revisions 430776 from http://svn.asterisk.org/svn/asterisk/branches/13


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

res_pjsip / res_pjsip_multihomed: Use the correct transport and addressing information on UAS sessions.

The first thing this patch fixes is UAS dialogs. Previously if a transport was
configured on an endpoint and an inbound session was created there was no guarantee
that requests sent on the dialog would use the correct transport and address
information. This has now been fixed so an explicitly configured transport
is taken into account.

The second thing this patch fixes is res_pjsip_multihomed. The res_pjsip_multihomed
module attempts to determine what transport a message should go out on and what
addressing information should go into the message itself. In a scenario where
multiple transports exist bound to the same IP address but a different port the
code would incorrectly alter the transport and change the message to the wrong
transport. This change makes the res_pjsip_multihomed module smarter so it will
only change the transport and address information in the message when it is
possible and makes sense.

ASTERISK-24615 #close
Reported by: David Justl

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

Merged revisions 430755 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Due to the original patch causing memory corruptions the patch is
being removed until the problem can be resolved.
........

Merged revisions 430734 from http://svn.asterisk.org/svn/asterisk/branches/13


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

........

Merged revisions 430716 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Different clients react differently to being told that a blind transfer
has failed. Some will simply send a BYE and be done with it. Others will
attempt to reinvite themselves back onto the call.

In the latter case, we were creating a new channel and then leaving it to
sit forever doing nothing. With this code change, that new channel will
not be created and the dialog with the transferring channel will be cleaned
up properly.

ASTERISK-24624 #close
Reported by Zane Conkle

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

Merged revisions 430714 from http://svn.asterisk.org/svn/asterisk/branches/13


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

This allows for a path to be specified that has a collection of CA
certificates in it.

ASTERISK-24575 #close
Reported by cloos
Patches:
	pj-ca-path-trunk.diff uploaded by cloos (License #5956)

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

Merged revisions 430709 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When FAX was developed, apparently the faxregistry.container used to be a
linked list that was converted to an ao2 container.  Some of the
replacement ao2 container operations still had explicit lock/unlocks
around them.

Three off nominal code paths in res_fax.c and res_fax_spandsp.c unlock the
channel even though the routine did not lock the channel and other code
paths in the routine do not unlock the channel.

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

Merged revisions 430687 from http://svn.asterisk.org/svn/asterisk/branches/13


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

........

Merged revisions 430685 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Due to the split of outbound registration state from configuration it is possible during
a reload for a "pjsip show registrations" CLI command to be executed which gets an older
snapshot of the configuration. This configuration may include outbound registrations which
have been removed due to a reload operation occurring at the same time. The code for
printing the outbound registration did not take this into account but now it does.

AST-1506 #close

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

Merged revisions 430664 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The Asterisk 13 configure.ac checks for HAS_WORKING_SEMAPHORE but does not have
an option for cross-compiling so it fails with an exit. Since we're cross-
compiling, we can't exactly go looking for the header. The semaphore.h header
is relatively common:
* It's part of the POSIX standard
* It's part of GNU C Library
As such, we assume that it will be present when cross-compiling.

As such, this patch defaults "HAS_WORKING_SEMAPHORE" to "1" if cross-compiling
is detected.

If you're cross-compiling to a platform that doesn't support this, then make
sure you re-define this to 0.

ASTERISK-24663 #close
Reported by: abelbeck
patches:
  asterisk-13-anonymous-semaphores.patch uploaded by abelbeck (License 5903)
........

Merged revisions 430646 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.

This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.

This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.

The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.

Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.

ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4311/
patches:
  pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
........

Merged revisions 430628 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The code was missing the case for explicitly destroying an outbound publication
when Asterisk had never actually published anything. The result was that Asterisk
would hang for a while on a graceful shutdown.

With this change, the case is taken into account, and on a graceful shutdown, these
publications are destroyed without the need to actually send a PUBLISH request.

ASTERISK-24655 #close
Reported by Kevin Harwell

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

Merged revisions 430608 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The mkpkgconfig script incorrectly concatenates Cflags options together. As an
example, the following:
Cflags: -I/usr/include/libxml2 -g3

Is instead generated as:
Cflags: -I/usr/include/libxml2-g3

This patch corrects the generation of Cflags in mkpkgconfig such that the
Cflags options are output correctly.

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

ASTERISK-23991 #close
Reported by: Diederik de Groot
patches:
  fix_mkpkgconfig.diff uploaded by Diederik de Groot (License 6600)
........

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

Merged revisions 430590 from http://svn.asterisk.org/svn/asterisk/branches/13


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

v11: If a channel redirect to a macro exten of a macro that is active
happens, the redirect location doesn't get executed.  Instead the original
macro location is restored and gets reexecuted.

v13: An additional effect happens if a parked call times out to an
extension in the macro that parked the call then the macro is reexecuted
instead of the expected park return location.

* Made not restore the macro calling location on an
AST_SOFTHANGUP_ASYNCGOTO.

* Increased the locked channel range when setting up the macro execution
environment to cover things that should be done while the channel is
locked.

* Removed unnecessary NULL tests before calling ast_free() in
_macro_exec().

ASTERISK-23850 #close
Reported by: Andrew Nagy

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

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

Merged revisions 430565 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The 'pjsip_get_dest_info' function is used to determine if the signaling transport
of the dialog is secure or not. This function was added in PJSIP 2.3 and does not
exist in earlier versions.

This configure check allows Asterisk to build and run with older versions at the
loss of the 'secure' argument for the PJSIP CHANNEL dialplan function. Usage of
this argument will require upgrading to PJSIP 2.3.

ASTERISK-24665 #close
Reported by: Mark Michelson

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

Merged revisions 430546 from http://svn.asterisk.org/svn/asterisk/branches/13


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

* Reverted the change to astman_send_listack() to not use the listflag
parameter and always set the value to "Start" so the start capitalization
is consistent.  Unfortunately changing the case of a returned value is not
a backward compatible change so for now FAXSessions is going to have to
remain inconsistent with all of the other AMI list actions.

* Reverted the minor protocol error fix in action_getconfig() when no
requested categories are found.  Each line needs to be formatted as
"Header: text".

Caught by the testsuite.

ASTERISK-24049
........

Merged revisions 430528 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The sample config was missing the configuration options for DTMF attended
transfer completion scenarios. The configuration options 'atxferabort',
'atxfercomplete', 'atxferthreeway', and 'atxferswap' are now documented in the
appropriate configuration file.

ASTERISK-24678 #close
Reported by: Niklas Larsson
patches:
  features.conf.sample.diff uploaded by Niklas Larsson (License 5068)
........

Merged revisions 430526 from http://svn.asterisk.org/svn/asterisk/branches/13


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

ASTERISK-24049


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

The security event log uses a dynamic log level (SECURITY) that is registered
with the Asterisk logging core. Unfortunately, the syslog would ignore log
statements that had a dynamic log level associated with them. Because the
syslog cannot handle ad hoc dynamic log levels, this patch treats any dynamic
log entries sent to the syslog as logs with a level of NOTICE.

ASTERISK-20744 #close
Reported by: Michael Keuter
Tested by: Michael L. Young, Jacek Konieczny
patches:
  asterisk-20744-syslog-dynamic-logging_trunk.diff uploaded by Michael L. Young (license 5026)
........

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

Merged revisions 430507 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When the channel datastore associated with the usage of CURLOPT on a specific
channel is freed, the underlying structure holding the list of options is not
disposed of. This patch properly frees the structure in the datastore .destroy
callback.

ASTERISK-24672 #close
Reported by: Kristian Hogh
patches:
  func_curl-memory-leak.diff uploaded by Kristian Hogh (License 6639)
........

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

Merged revisions 430488 from http://svn.asterisk.org/svn/asterisk/branches/13


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

General improvements to SIP to PJSIP conversion utility:

1) track default section of input file to allow parsing
   an include file that doesn't specify a [section]

2) informatively handle case of assignment without [section]

3) correctly handle getting sections from included files
   - [section]'s are inherited by included file

4) provide null string as default transport bind ip

5) gracefully handle missing portions of registration string

6) denote steps of operation during conversion and confirm
   top level files as a convenience

ASTERISK-24474 #close
Review: https://reviewboard.asterisk.org/r/4280/
Reported by: John Kiniston
........

Merged revisions 430469 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When app_bridge grabs a channel and puts it into
a bridge, the channel should then continue where
it left off in the dialplan after the bridge has
ended.   Although it stores the current dialplan
location as an after bridge goto on the channel,
it was executing the same priority again instead
of going to the next priority.   By swapping the
"specific" version of bridge_set_after_goto with
bridge_set_after_go_on, the next priority in the
dialplan is executed instead.

ASTERISK-24637 #close
Review: https://reviewboard.asterisk.org/r/4322/
Reported by: John Bigelow
........

Merged revisions 430467 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Follow-up issue to -r430435 from reviewboard review.

ASTERISK-24049
Review: https://reviewboard.asterisk.org/r/4315/


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

* Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList

* Incremented the AMI version to 2.7.0.

* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start".  The corresponding complete event always used "Complete".

* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.

* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots().  Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.

* Fixed minor protocol error in action_getconfig() when no requested
categories are found.  Each line needs to be formatted as "Header: text".

* Fixed off-nominal memory leak in manager_build_parked_call_string().

* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().

ASTERISK-24049 #close
Reported by: Jonathan Rose

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

Merged revisions 430434 from http://svn.asterisk.org/svn/asterisk/branches/13


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

This change makes the T.38 negotiation timeout configurable via
't38timeout' in res_fax.conf or FAXOPT(t38timeout). It was previously
hard coded to be 5000 milliseconds.

This change also handles T.38 switch failures by aborting the fax since
in the case where this can happen, both sides have agreed to switch to
T.38 and Asterisk is unable to do so.

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

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

Merged revisions 430416 from http://svn.asterisk.org/svn/asterisk/branches/13


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

If you do a 'core (shutdown|restart) graceful' persistent subscriptions won't 
survive.  If you do a 'core (shutdown|restart) now' or asterisk terminates for 
some reason, they do.  Here's why...

When asterisk shuts down gracefully, it sends a 'NOTIFY/terminated' to 
subscribers for each subscription.  This not only tells the subscribers that the 
dialog/state machine is done, it also frees the last reference to the 
subscription tree which causes the persistent subscription to get deleted from 
astdb.  When asterisk restarts, nothing's left.  Just preventing the delete from 
astdb doesn't work because we already told the subscriber to terminate the 
dialog so we can't restart it even if it was still in astdb.  Everything works 
OK if asterisk terminates unexpectedly because we never send the 'terminated' 
message so on restart, the subscription is still in astdb and the subscriber is 
none the wiser.

This patch suppresses the sending of 'NOTIFY/terminated' on shutdown for 
persistent connections.

Tested-by: George Joseph

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

Merged revisions 430397 from http://svn.asterisk.org/svn/asterisk/branches/13


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

Every time a registration started, sip_outbound_registration_response_cb bumps 
the ref count on client_state then pushes a handle_registration_response task.  
handle_registration_response never unreffed it though.  So every time a 
registration goes out, the ref count goes up by one.

This patch adds the unreffs to handle_registration_response.

Tested-by: George Joseph

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

Merged revisions 430395 from http://svn.asterisk.org/svn/asterisk/branches/13


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

There are 2 issues with reloading registrations...

1.  The 'can_reuse_registration' test wasn't considering the intervals or 
expiration in its determination of whether a registration changed or not so if 
you changed any of the intervals or the expiration and reloaded, the object 
would get reloaded but the actual timers wouldn't change.  
can_reuse_registration now does a sorcery diff on the old and new objects 
instead of discretely testing certain fields.  Now if you change expiration for 
instance, and reload, the timer is updated and re-registration will occur on the 
new value.

2.  If you mung up your password on an outbound registration you get a permanent 
failure.  If you fix the password (on the outbound_auth object) and reload, 
nothing tells outbound_registration to try again because the registration itself 
didn't change.  This patch adds an observer on the "auth" object type and if any 
auth changes, existing registration states are searched and those in a 
REJECTED_PERMANENT state are retried.

Tested-by: George Joseph

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

Merged revisions 430373 from http://svn.asterisk.org/svn/asterisk/branches/13


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

When the AMI Redirect action is used with a channel bridged inside
Stasis() and not running a pbx, the channel is hung up instead of
proceeding to the desired location in dialplan. This change allows
such channels to be Redirected properly by detecting the operation
used by Redirect (ASYNCGOTO) and using the code already established
for functionality of the ARI channel continue operation.

ASTERISK-24591 #close
Review: https://reviewboard.asterisk.org/r/4271/
........

Merged revisions 430355 from http://svn.asterisk.org/svn/asterisk/branches/13


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

With this patch, the following two ARI commands

POST /channels
POST /channels/{id}/continue

Accept a new parameter, label, that can be used to continue to or originate
to a priority label in the dialplan.

Because this is adding a new parameter to ARI commands, the API version of
ARI has been bumped from 1.6.0 to 1.7.0.

This patch comes courtesy of Nir Simionovich from Greenfield Tech. Thanks!

ASTERISK-24412 #close
Reported by Nir Simionovich

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

Merged revisions 430337 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The 'new_subscribe: Extension <> does not exist or has no associated hint'
is a config issue and doesn't need to clutter up logs with warnings.
Changed to notice.

Tested-by: George Joseph

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

Merged revisions 430319 from http://svn.asterisk.org/svn/asterisk/branches/13


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

The "MWI Subscription failed" message means the client is trying to subscribe
to a mailbox that doesn't exist.  There's no need to clutter up logs with
warnings for a client misconfiguration so I changed it to a notice.

Tested-by: George Joseph

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

Merged revisions 430317 from http://svn.asterisk.org/svn/asterisk/branches/13


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

I guess nobody uses templates with AST_CONFIG because today if you have a
context that inherits from a template and you call AST_CONFIG on the context,
you'll get the value from the template even if you've overridden it in the
context.  This is because AST_CONFIG only gets the first occurrence which is
always from the template.

This patch adds an optional 'index' parameter to AST_CONFIG which lets you
specify the exact occurrence to retrieve, or '-1' to retrieve the last.
The default behavior is the current behavior.

Tested-by: George Joseph

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

Merged revisions 430315 from http://svn.asterisk.org/svn/asterisk/branches/13


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