Parkinglots are defined in res_features.conf now, but this patch fixes
features_config so that features don't fail to load when parkinglots
are present in features.conf

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

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


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

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

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


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

ast_xmldoc_printable returns an allocated block that must be freed by the
caller.  Fixed manager.c and res_agi.c to stop leaking these results.

(closes issue ASTERISK-22395)
Reported by: Corey Farrell
Patches:
     manager-leaks-12.patch uploaded by coreyfarrell (license 5909)
     res_agi-xmldoc-leaks.patch uploaded by coreyfarrell (license 5909)
........

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

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

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


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

Revert the -r392190 change.  The original test was correct.  The CDR code
was actually returning an unititialized buffer.
........

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


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

You cannot put the "Testing <blah> pass/fail" on a single line before
actually performing the test.  Now any additional failure information is
logged before the test pass/fail announcement.

* Added an additional CDR(answer,u) test.
........

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

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

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


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

(closes issue ASTERISK-22368)
Reported by: Corey Farrell
Patches:
     issueA22368_mixmonitor_free_filename.patch uploaded by wdoekes (license 5674)
........

Merged revisions 398004 from http://svn.asterisk.org/svn/asterisk/branches/10
........

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

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


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

........

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

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


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

With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].

This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.

For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.

Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)

The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.

Other changes made as a part of this patch:
 * The stubs for http_websocket that wrap system calls set errno to
   ENOSYS.

 * res_http_websocket now properly increments module use count.

 * In loader.c, the while() wrappers around dlclose() were removed. The
   while(!dlclose()) is actually an anti-pattern, which can lead to
   infinite loops if the module you're attempting to unload exports a
   symbol that was directly linked to.

 * The special handling of nonoptreq on systems without weak symbol
   support was removed, since we no longer rely on weak symbols for
   optional_api.

 [1]: https://wiki.asterisk.org/wiki/x/wACUAQ

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

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


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

his patch implements the ARI API's for stored recordings. While the
original task only specified deleting a recording, it was simple
enough to implement the GET for all recordings, and for an individual
recording.

The recording playback operation was modified to use the same code for
accessing the recording as the REST API, so that they will behave
consistently.

There were several problems with the api-docs that were also fixed,
bringing the ARI spec in line with the implementation. There were some
'wishful thinking' fields on the stored recording model (duration and
timestamp) that were removed, because I ended up not implementing a
metadata file to go along with the recording to store such information.

The GET /recordings/live operation was removed, since it's not really
that useful to get a list of all recordings that are currently going
on in the system. (At least, if we did that, we'd probably want to
also list all of the current playbacks. Which seems weird.)

(closes issue ASTERISK-21582)
Review: https://reviewboard.asterisk.org/r/2693/
........

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


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

........
  r397975 | rmudgett | 2013-08-29 20:00:00 -0500 (Thu, 29 Aug 2013) | 1 line
  
  pbx.c: Make ast_str_substitute_variables_full() not mask variables.
........
  r397976 | rmudgett | 2013-08-29 20:00:41 -0500 (Thu, 29 Aug 2013) | 1 line
  
  Revert last commit.
........

Merged revisions 397975-397976 from http://svn.asterisk.org/svn/asterisk/branches/12


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

........

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


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

PJSIP's PIDF API does not replace angle brackets with
their appropriate counterparts for XML. So we have to
do it ourself. In this particular case, the problem had
to do with attempting to place an unsanitized SIP URI
into an XML node. Now we don't get a 488 from recipients
of our PIDF NOTIFYs.
........

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


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

The previous method did not allocate enough space to create
the entire string, but adjusted the string's slen value to
be larger than the actual allocation. This resulted in garbled
text in NOTIFY requests from Asterisk.

This method allocates the proper amount of space first and then
writes the content into the buffer.
........

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


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

Refactored cases where a combination of ast_verbose/options_verbose were
present.  Also in general tried to eliminate, in as many places as possible,
where the options_verbose global variable was being used.  Refactored the way
local and remote consoles handle verbose message logging in an attempt to
solve the various discrepancies that sometimes would show between the two.

(closes issue AST-1193)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/2798/
........

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

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


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

The previous placement would result in the resubscribe() callback called instead of
the subscription_terminated() callback being called when a subscription was ended
via a SUBSCRIBE request. This would result in confusing PJSIP and having it throw
an assertion.
........

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


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

RFC 5407 section 3.1.2 details a scenario where a UAC sends
a CANCEL at the same time that a UAS sends a 200 OK for the
INVITE that the UAC is canceling. When this occurs, it is the
role of the UAC to immediately send a BYE to terminate
the call.

This scenario was reproducible by have a Digium phone with two lines
place a call to a second phone that forwarded the call to the second
line on the original phone. The Digium phone, upon realizing that it
was connecting to itself, would attempt to cancel the call. The timing
of this happened to trigger the aforementioned race condition about
80% of the time. Asterisk was not doing its job of sending a BYE
when receiving a 200 OK on a cancelled INVITE. The result was that
the ast_channel structure was destroyed but the underlying SIP
session, as well as the PJSIP inv_session and dialog, were still
alive. Attempting to perform an action such as a transfer, once in
this state, would result in Asterisk crashing.

The circumstances are now detected properly and the session is ended
as recommended in RFC 5407.

(closes issue AST-1209)
reported by John Bigelow
........

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


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

(closes ASTERISK-22376)
Reported by: John Hardin
Patches:
     memleak.patch uploaded by jhardin (license 6512)
     memleak2.patch uploaded by jhardin (license 6512)
........

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


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

The patch from ASTERISK-21965 was committed perhaps a bit too hastily. Walter
and Tzafrir have pointed out numerous issues with the approach and have
propsed an alternative in r/2757. Since it's not a time critical issue and
is not worth holding up the release of 12 for it, I've gone ahead and reverted
r394939 from 12/trunk and re-opened ASTERISK-21965.
........

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


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

........

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


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

Without this, documentation defined in sub-folders is ignored. Since having
properly generated documentation is especially important in Asterisk 12 -
not having it can cause a module to not load - 'make full' needs to look in
all .c files.
........

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


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

........
  r397921 | mmichelson | 2013-08-29 10:42:10 -0500 (Thu, 29 Aug 2013) | 6 lines
  
  Resolve assumptions that bridge snapshots would be non-NULL for transfer stasis events.
  
  Attempting to transfer an unbridged call would result in crashes in either CEL code or
  in the conversion to AMI messages.
........
  r397922 | mmichelson | 2013-08-29 10:42:29 -0500 (Thu, 29 Aug 2013) | 3 lines
  
  Remove extra debug message.
........

Merged revisions 397921-397922 from http://svn.asterisk.org/svn/asterisk/branches/12


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

In r397874, the scripts were removed... but not replaced. Thanks to
Michael Young for noticing this!
........

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


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

* Made ast_strftime_locale() ensure that the output buffer is initialized.
The std library strftime() returns 0 and does not touch the buffer if it
has an error.  However, the function can also return 0 without an error.

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

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


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

* Fixed return value of ast_cdr_serialize_variables() on error.  It needs
to return 0 indicating no CDR variables found.

* Made ast_cdr_serialize_variables() check the return value of
cdr_object_format_property() and assert if nonzero.  A member of the
cdr_readonly_vars[] was not handled.

* Removed unused elements from cdr_readonly_vars[]: total_duration,
total_billsec, first_start, and first_answer.
........

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


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

........

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


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

........

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


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

........

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


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

........

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


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

........

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


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

A problem encountered during testing was that res_pjsip_refer would
not ever send a NOTIFY with a 200 OK sipfrag. This is because the framehook
that was supposed to send the NOTIFY would never be told that an answer
had occurred. This happened for two reasons:

1) The transferee channel on which the framehook was on was already up.
2) Answers are rarely if ever written to channels. Rather, the ast_answer()
or ast_raw_answer() function is used to answer channels.

Thanks to a suggestion by Matt Jordan, the best way to detect that the call
had been answered was to find out when the transferee channel joined a bridge.
With stasis this is an easy task. So now, in addition to the framehook logic,
there is a stasis subscription used to determine when the transferee has entered
a bridge. Once it has entered, an appropriate NOTIFY is sent.
........

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


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

This patch replaces contrib/realtime/ with a new setup for managing the
database schema required for database integration with Asterisk.  In
addition to initializing a database with the proper schema, alembic can do a
database migration to assist with upgrading Asterisk in the future.
Hopefully this helps make setting up and operating Asterisk with a database
easier.

With this the schema only needs to be maintained in one place instead of
once per database.  The schemas I have added here have a bit of improvement
over the examples that were there before (some added consistency and added
some missing indexes).  Managing the schema in one place here also applies
to all databases supported by SQLAlchemy.

See contrib/ast-db-manage/README.md for more details.

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

patch by Russell Bryant (license 6300)
........

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


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

This updates the Asterisk 12 CHANGES file with the things that were missed
during the development cycle.

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

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


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

........

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


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

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

........

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


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

Dialog matching is performed in the distributor for the sole
purpose of retrieving an associated serializer so the request
may be serialized.

This patch fixes two problems.

First, incoming CANCEL requests that had no to-tag (which really
should be *all* CANCEL requests) would not match with a dialog.
An earlier bug fix to deal with early CANCEL requests would result
in the CANCEL being replied to with a 481. The fix for this is to
find the matching INVITE transaction and get the dialog from that
transaction.

Second, no SIP responses were matching dialogs. This is because we
were inverting the tags that we were passing into PJSIP's dialog
finding function. This logic has been corrected by setting local
and remote tag variables based on whether the incoming message is
a request or response.
........

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


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

Stasis events (which get distributed over the ARI WebSocket) are created
by subscribing to the channel_all_cached and bridge_all_cached topics,
filtering out events for channels/bridges currently subscribed to.

There are two issues with that. First was a race condition, where
messages in-flight to the master subscribe-to-all-things topic would get
sent out, even though the events happened before the channel was put
into Stasis. Secondly, as the number of channels and bridges grow in the
system, the work spent filtering messages becomes excessive.

Since r395954, individual channels and bridges have caching topics, and
can be subscribed to individually. This patch takes advantage, so that
channels and bridges are subscribed to on demand, instead of filtering
the global topics.

The one case where filtering is still required is handling BridgeMerge
messages, which are published directly to the bridge_all topic.

Other than the change to how subscriptions work, this patch mostly just
moves code around. Most of the work generating JSON objects from
messages was moved to .to_json handlers on the message types. The
callback functions handling app subscriptions were moved from res_stasis
(b/c they were global to the model) to stasis/app.c (b/c they are local
to the app now).

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

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


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

Storing a backtrace for each allocation in anticipation of a memory
management problem is very CPU intensive.

* Added the CLI "memory backtrace {on|off}" command to request that the
backtrace be gathered only on request.  The backtrace is off by default.

(issue ASTERISK-22221)
Reported by: Matt Jordan
........

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


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

If the SIP channel driver processes an invalid SDP that defines media
descriptions before connection information, it may attempt to reference
the socket address information even though that information has not yet
been set. This will cause a crash.

This patch adds checks when handling the various media descriptions that
ensures the media descriptions are handled only if we have connection
information suitable for that media.

Thanks to Walter Doekes, OSSO B.V., for reporting, testing, and providing
the solution to this problem.

(closes issue ASTERISK-22007)
Reported by: wdoekes
Tested by: wdoekes
patches:
  issueA22007_sdp_without_c_death.patch uploaded by wdoekes (License 5674)
........

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

Merged revisions 397757 from http://svn.asterisk.org/svn/asterisk/branches/10
........

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

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


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

A remote exploitable crash vulnerability exists in the SIP channel driver if an
ACK with SDP is received after the channel has been terminated. The handling
code incorrectly assumed that the channel would always be present.

This patch adds a check such that the SDP will only be parsed and applied if
Asterisk has a channel present that is associated with the dialog.

Note that the patch being applied was modified only slightly from the patch
provided by Walter Doekes of OSSO B.V.

(closes issue ASTERISK-21064)
Reported by: Colin Cuthbertson
Tested by: wdoekes, Colin Cutherbertson
patches:
  issueA21064_fix.patch uploaded by wdoekes (License 5674)
........

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

Merged revisions 397711 from http://svn.asterisk.org/svn/asterisk/branches/10
........

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

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


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