These memory leaks were found and fixed by John Hardin. I'm just
committing them for him.

ASTERISK-24736 #close
Reported by Mark Michelson

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

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


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

When swapping a Local channel in place of one already
in a bridge (to complete a bridge attended transfer),
the channel that was swapped out can actually be hung
up before the stasis bridge push callback executes on
the independant transfer thread.  This results in the
stasis app loop dropping out and removing the control
that has the the app name which the local replacement
channel needs so it can re-enter stasis.

To avoid this race condition a new push_peek callback
has been added, and called from the ast_bridge_impart
thread before it launches the independant thread that
will complete the transfer.  Now the stasis push_peek
callback can copy the stasis app name before the swap
channel can hang up.

ASTERISK-24649
Review: https://reviewboard.asterisk.org/r/4382/
........

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


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

Due to an inversion error, setting 100rel=no would not actually
change the current value of the setting (which defaulted to "yes").
With this fix, the inversion is corrected.
........

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


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

RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific
scenarios when we are required to use SIPS URIs in Contact
headers. Asterisk's non-compliance with this could actually
cause calls to get dropped when communicating with clients
that are strict about checking the Contact header.

Both of the SIP stacks in Asterisk suffered from this issue.
This changeset corrects the behavior in res_pjsip/chan_pjsip.c

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

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


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

RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific
scenarios when we are required to use SIPS URIs in Contact
headers. Asterisk's non-compliance with this could actually
cause calls to get dropped when communicating with clients
that are strict about checking the Contact header.

Both of the SIP stacks in Asterisk suffered from this issue.
This changeset corrects the behavior in chan_sip.

ASTERISK-24646 #close
Reported by Stephan Eisvogel

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

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

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


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

Reduce log clutter by changing the "Watcher for hint %s (removed|deactivated)"
message from WARNING to VERBOSE/2.

Tested-by: George Joseph

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

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


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

A recent security fix for OpenSSL broke DTLS negotiation for many
applications. This was caused by read ahead not being enabled when it
should be. While a commit has gone into OpenSSL to force read ahead
on for DTLS it may take some time for a release to be made and the
change to be present in distributions (if at all). As enabling read
ahead is a simple one line change this commit does that and fixes
the issue.

ASTERISK-24711 #close
Reported by: Jared Biel
........

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

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


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

SIP requests that offered codecs incompatible with configured values
could result in the allocation of RTP and RTCP ports that would not get
reclaimed later.

ASTERISK-24666 #close
Reported by Y Ateya

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

AST-2015-001
........

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

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


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

........
  r431297 | mmichelson | 2015-01-28 11:05:26 -0600 (Wed, 28 Jan 2015) | 17 lines
  
  Mitigate possible HTTP injection attacks using CURL() function in Asterisk.
  
  CVE-2014-8150 disclosed a vulnerability in libcURL where HTTP request injection
  can be performed given properly-crafted URLs.
  
  Since Asterisk makes use of libcURL, and it is possible that users of Asterisk may
  get cURL URLs from user input or remote sources, we have made a patch to Asterisk
  to prevent such HTTP injection attacks from originating from Asterisk.
  
  ASTERISK-24676 #close
  Reported by Matt Jordan
  
  Review: https://reviewboard.asterisk.org/r/4364
  
  AST-2015-002
........
  r431298 | mmichelson | 2015-01-28 11:12:49 -0600 (Wed, 28 Jan 2015) | 3 lines
  
  Fix compilation error from previous patch.
........

Merged revisions 431297-431298 from http://svn.asterisk.org/svn/asterisk/branches/11
........

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

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


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

In r419044, we changed how formats were handled, but the return value
of the format_parse_sdp_fmtp functions in res_format_attr_opus and
res_format_attr_silk were not updated, causing calls to fail.  Ran
into this when getting codec_opus working with Asterisk 13.

Once the return value was corrected, we were crashing in opus_getjoint
because of NULL format attributes.  I've fixed this as well in this
patch.

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

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


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

Performing a CLI "module reload" command when there are new pjsip.conf
registration objects defined frequently failed to load them correctly.

What happens is a race condition between res_pjsip pushing its reload into
an asynchronous task processor task and the thread that does the rest of
the reloads when it gets to reloading the res_pjsip_outbound_registration
module.  A similar race condition happens between a reload and the CLI/AMI
show registrations commands.  The reload updates the current_states
container and the CLI/AMI commands call get_registrations() which builds a
new current_states container.

* Made res_pjsip.c reload_module() use ast_sip_push_task_synchronous()
instead of ast_sip_push_task() to eliminate two threads processing config
reloads at the same time.

* Made get_registrations() not replace the global current_states container
so the CLI/AMI show registrations command cannot interfere with reloading.
You could never add/remove objects in the container without the
possibility of the container being replaced out from under you by
get_registrations().

* Added a registration loaded sorcery instance observer to purge any dead
registration objects since get_registrations() cannot do this job anymore.
The struct ast_sorcery_instance_observer callbacks must be used because
the callback happens inline with the load process.  The struct
ast_sorcery_observer callbacks are pushed to a different thread.

* Added some global current_states NULL pointer checks in case the
container disappears because of unload_module().

* Made sorcery's struct ast_sorcery_instance_observer.object_type_loaded
callbacks guaranteed to be called before any struct
ast_sorcery_observer.loaded callbacks will be called.

* Moved the check for non-reloadable objects to before the sorcery
instance loading callbacks happen to short circuit unnecessary work.
Previously with non-reloadable objects, the sorcery instance
loading/loaded callbacks would always happen, the individual wizard
loading/loaded would be prevented, and the non-reloadable type logging
message would be logged for each associated wizard.

ASTERISK-24729 #close
Review: https://reviewboard.asterisk.org/r/4381/
........

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


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

While running through some scenarios using chan_sip and tcp a problem would
occur that resulted in a flood of bad file descriptor messages on the cli:

tcptls.c:712 ast_tcptls_server_root: Accept failed: Bad file descriptor

The message is received because the underlying socket has been closed, so is
valid. This is probably happening because unloading of chan_sip is not atomic.
That however is outside the scope of this patch. This patch simply stops the
logging of multiple occurrences of that message.

ASTERISK-24728 #close
Reported by: Thomas Thompson
Review: https://reviewboard.asterisk.org/r/4380/
........

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

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


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

Prior to this patch, ModuleLoad would respond with an error indicating that
the requested module wasn't found in spite of finding and reloading the
module.

Review: https://reviewboard.asterisk.org/r/4373/
ASTERISK-24721 #close
........

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


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

When refreshing (with a small expiration) a registration that was sent to
chan_sip the nonce would be considered stale and reject the registration.
What was happening was that the initial registration's "dialog" still existed
in the dialogs container and upon refresh the dialog match algorithm would
choose that as the "dialog" instead of the newly created one. This occurred
because the algorithm did not check to see if the from tag matched if
authentication info was available after the 401. So, it ended up assuming
the original "dialog" was a match and stopped the search. The old "dialog"
of course had an old nonce, thus the stale nonce message.

This fix attempts to leave the original functionality alone except in the case
of a REGISTER. If a REGISTER is received if searches for an existing "dialog"
matching only on the callid. If the expires value is low enough it will reuse
dialog that is there, otherwise it will create a new one.

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

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

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


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

Due to the original patch causing memory corruptions it was removed until the
problem could be resolved. This patch is the original patch plus some added
locking around stasis router subcription that was needed to avoid the memory
corruption.

Description of the original problem and patch (still applicable):

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/4363/
patches:
  pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
........

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


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

Starting and stopping conference recording more than once causes the
recording channels to be leaked.  For v13 the channels also show up in the
CLI "core show channels" output.

* Reworked and simplified the recording channel code to use
ast_bridge_impart() instead of managing the recording thread in the
ConfBridge code.  The recording channel's ref handling easily falls into
place and other off nominal code paths get handled better as a result.

ASTERISK-24719 #close
Reported by: John Bigelow

Review: https://reviewboard.asterisk.org/r/4368/
Review: https://reviewboard.asterisk.org/r/4369/
........

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

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


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

This change fixes two issues:

1. During a swap operation bridging added the new channel before having the swap channel
leave. This was not handled in bridge_native_rtp and could result in a channel not getting
reinvited back to Asterisk. After this change the swap channel will leave first and the
new channel will then join.

2. If a re-invite was received after a session had been established any upstream elements
(such as bridge_native_rtp) were not notified that they may want to re-evaluate things.
After this change an UPDATE_RTP_PEER control frame is queued when this situation occurs
and upstream can react.

AST-1524 #close

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

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


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

This patch improves the documentation of ARI on the wiki. Specifically, it
addresses the following:
* Allowed values and allowed ranges weren't documented. This was particularly
  frustrating, as Asterisk would reject query parameters with disallowed values
  - but we didn't tell anyone what the allowed values were.
* The /play/id operation on /channels and /bridges failed to document all of
  the added media resource types.
* Documentation for creating a channel into a Stasis application failed to
  note when it occurred, and that creating a channel into Stasis conflicts with
  creating a channel into the dialplan.
* Some other minor tweaks in the mustache templates, including italicizing the
  parameter type, putting the default value on its own sub-bullet, and some
  other nicities.

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

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


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

When issuing a 'confbridge list XXXX' CLI command, the resulting output no
longer displays the menu associated with a ConfBridge participant.

The issue was caused by ASTERISK-22760. When that patch was done, it removed
the copying of the menu name associated with the user from the actual user
profile.

This patch fixes the issue by copying the menu name over to the user profile
when the menu hooks are applied to the user. Since that function now does a
little bit more than just apply the hooks, the name of the function has been
changed to cover the copying of the menu name over as well.

In addition, there is a disparity between the menu name length as it is stored
on the conf_menu structure and the confbridge_user structure; this patch makes
the lengths match so that a strcpy can be used.

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

ASTERISK-24723 #close
Reported by: Steve Pitts
........

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


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

There is currently a race condition when unloading the res_parking
module. Depending on the will of the universe the subscription
invocation may occur AFTER the module is unloaded. This is because
the module does NOT use stasis_unsubscribe_and_join when terminating
the subscription. It merely uses stasis_unsubscribe.

This change makes it use stasis_unsubscribe_and_join which is documented
for usage in this exact scenario.

AST-1520 #close

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

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


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

This patch addresses compilation errors on OS X. It's been a while, so
there's quite a few things.

 * Fixed __attribute__ decls in route.h to be portable.
 * Fixed htonll and ntohll to work when they are defined as macros.
 * Replaced sem_t usage with our ast_sem wrapper.
 * Added ast_sem_timedwait to our ast_sem wrapper.
 * Fixed some GCC 4.9 warnings using sig*set() functions.
 * Fixed some format strings for portability.
 * Fixed compilation issues with res_timing_kqueue (although tests still fail
   on OS X).
 * Fixed menuconfig /sbin/launchd detection, which disables res_timing_kqueue
   on OS X).

ASTERISK-24539 #close
Reported by: George Joseph

ASTERISK-24544 #close
Reported by: George Joseph

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

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


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

When a crash was fixed due to usage of the REALTIME function in r423003, a
regression was introduced into ast_update2_realtime where the update fields
passed to the function would be skipped and the lookup field processed twice.

The use of this function is a bit interesting: A variable argument list is
used with two sentinel values - the first marks the end of the lookup
fields/values; the second marks the end of the update fields/values.
Unfortunately, ast_update2_realtime parses over the lookup fields twice, as
opposed to parsing over the update fields. This causes the lookups to succeed,
but the updates itself to have no effect.

Note that the most common instance of this problem occurred in app_voicemail
during the updating of a mailbox password.

Thanks to the issue reporter, Paddy Grice, for pointing out the problem.

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

ASTERISK-24231

ASTERISK-24626 #close
Reported by: Paddy Grice
........

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


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

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

Channel names should be different from other channels in the system while
the channel exists.

* Use a sequence number for CBRec channels instead of a random number
because the same random number could be picked again for the next CBRec
channel.
........

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


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

Because there is sometimes no sence to any whitespace.
........

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

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


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

........

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


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

Fixed memory leaks that were found in Asterisk.

ASTERISK-24693 #close
Reported by:  Kevin Harwell
Review: https://reviewboard.asterisk.org/r/4347/
........

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


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

........

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

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


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

All the other configuration options are case insensitive, so this one
should be too.

ASTERISK-24355 #close
Reported by: HZMI8gkCvPpom0tM
patches:
  ast.patch uploaded by HZMI8gkCvPpom0tM (License 6658)
........

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

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


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

When code imparts a channel into a bridge to swap with another channel, a
ref needs to be held on the swap channel to ensure that it cannot
dissapear before finding it in the bridge.

* The ast_bridge_join() swap channel parameter now always steals a ref for
the swap channel.  This is the only change to the bridge framework's
public API semantics.

* bridge_channel_internal_join() now requires the bridge_channel->swap
channel to pass in a ref.

ASTERISK-24649
Reported by: John Bigelow

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

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


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

* Add an allocation failure check and assert in
sip_outbound_registration_response_cb().

* Made sip_outbound_registration_state_destroy() handle partially created
state objects from sip_outbound_registration_state_alloc().

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

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


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

After a bridge transfer completes where a local replacement
channel is used, a stasis transfer message with the details
of the transfer is sent.  This is processed by stasis which
then sets the stasis app name and replaced channel snapshot
on the replacement channel.

However, since a separate thread was already started to run
stasis on the new replacement channel, a race was on to see
if the message processing would be completed before the app
name was needed, otherwise the channel would be hung up.

This change moves the calls used to set the stasis app name
and the replace snapshot to the bridge_stasis_push function
callback from the bridge transfer logic, allowing the steps
to be completed earlier and more deterministically, and the
race elimianted.

NOTE: the swap channel parameter to bridge_stasis_push (and
thus all bridge push callbacks) must always be present when
performing a swap with another channel.

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

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


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

The MixMonitor m() option allows a recording to be pushed to a specific
voicemail mailbox. If the message is delivered to the mailbox's INBOX, however,
no MWI notification is currently raised.

This patch corrects the issue by properly calling notify_new_state from the
msg_create_from_file function. This will cause MWI to be triggered if the
message was placed in the mailbox's INBOX.

ASTERISK-24709 #close
Reported by: Gareth Palmer
patches:
  app_voicemail-430919.patch uploaded by Gareth Palmer (License 5169)
........

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

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


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

Move an unconditional unref of client_state so it doesn't look like it
could be used after the last ref has destroyed it.
........

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


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

When the SIP registrations were migrated to using ao2 in what was then trunk,
the explicit destruction of the registrations on module reload was removed and
not replaced with an ao2 equivalent. Debugging done by Stefan Engström, the
issue reporter, on ASTERISK-24673 confirmed that the reference in the
registry_list container was being leaked.

Since the purpose of cleanup_all_regs is to prep a registration for
destruction, this function now calls an ao2_callback function callback with the
OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the registrations.
This cleans up each registration, and also removes it from the registration
container registry_list.

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

ASTERISK-24640 #close
Reported by: Max Man

ASTERISK-24673 #close
Reported by: Stefan Engström
Tested by: Stefan Engström
........

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


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

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