Add comments about the BUILD_NATIVE change

This is a significant change and mention of it should have gone into
UPGRADE.txt and CHANGES.
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370082 f38db490-d61c-443f-a65b-d21fe96a405b
Code cleanup and bugfix in chan_sip outboundproxy parsing.

The bug was clearing the global outboundproxy when a peer-specific
outboundproxy was bad. The cleanup reduces duplicate code.

Review: https://reviewboard.asterisk.org/r/2034/
Reviewed by: Mark Michelson
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370132 f38db490-d61c-443f-a65b-d21fe96a405b
Ensure that all ast_datastore_info structures are 'const'.

While addressing a bug, I came across a instance of 'struct ast_datastore_info'
that was not declared 'const'. Since the API already expects them to be
'const', this patch changes the declarations of all existing instances
that were not already declared that way.
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370184 f38db490-d61c-443f-a65b-d21fe96a405b
Resolve severe memory leak in CEL logging modules.

A customer reported a significant memory leak using Asterisk 1.8. They
have tracked it down to ast_cel_fabricate_channel_from_event() in
main/cel.c, which is called by both in-tree CEL logging modules
(cel_custom.c and cel_sqlite3_custom.c) for each and every CEL event
that they log.

The cause was an incorrect assumption about how data attached to an
ast_channel would be handled when the channel is destroyed; the data
is now stored in a datastore attached to the channel, which is
destroyed along with the channel at the proper time.

(closes issue AST-916)
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2053/
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370206 f38db490-d61c-443f-a65b-d21fe96a405b
Handle extremely out of order RFC 2833 DTMF

The current implementation of RFC 2833 DTMF handling in res_rtp_asterisk will,
if a packet arrives out of order, drop the packet.  This is to prevent
duplicate ton generation in the Asterisk core.  Since the RTP layer does not
buffer data itself, this is the only option the RTP layer currently has for
handling packets that arrive out of order.

For the most part, this doesn't matter.  For a particular digit, so long as a
BEGIN packet arrives before the first END packet, the digit will be produced.
If subsequent BEGIN packets arrive interleaved with the ENDs, they will be
dropped; likewise, if the BEGIN or END packets themselves are out of order,
those packets are dropped but sufficient information is conveyed to the
Asterisk core to produce the appropriate digit.

For certain sequences of DTMF packets - most notably when, for a particular
digit, an END packet arrives before any BEGIN packet for that digit - this
is a real problem.  When an END arrives before any BEGINs, the END packet is
dropped - but at the same time, it causes subsequent BEGIN packets for that
digit to be ignored.  When the next in order END packet arrives, it too is
dropped - Asterisk believes that there was no initial BEGIN.

The solution this patch provides is to trust the END packet to convey the
information needed for the Asterisk core to produce the DTMF digit.  If we
receive an END packet, and it:
  * Has a timestamp greater then the last timestamp received from an END
    packet
  * Does not have the same sequence number as the last received sequence
    number (and is thus not an END packet retransmission)
Then we send the END frame up to the Asterisk core.  It contains enough
DTMF information for Asterisk to produce the digit.

On the other hand, if we receive a BEGIN or continuation packet that occurs
with a timestamp equal to or less then the last END timestamp, then we've
received something out of order - but we already have received enough
information to produce the digit.  These packets are dropped.

Much thanks goes to Olle Johansson (oej) for providing the idea for this
solution.

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

(closes issue ASTERISK-18404)
Reported by: Stephane Chazelas
Tested by: Matt Jordan
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370271 f38db490-d61c-443f-a65b-d21fe96a405b
Fix compilation error when MALLOC_DEBUG is enabled

To fix a memory leak in CEL, a channel datastore was introduced whose
destruction function pointer was pointed to the ast_free macro.  Without
MALLOC_DEBUG enabled this compiles as fine, as ast_free is defined as free.
With MALLOC_DEBUG enabled, however, ast_free takes on a definition from a
different place then utils.h, and became undefined.  This patch resolves this
by using a reference to ast_free_ptr.  When MALLOC_DEBUG is enabled, this
calls ast_free; when MALLOC_DEBUG is not enabled, this is defined to be
ast_free, which is defined to be free.

(issue AST-916)
Reported by: Thomas Arimont
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370274 f38db490-d61c-443f-a65b-d21fe96a405b
Fix compiler warnings.

gcc (GCC) 4.2.4 has problems casting away constness.
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370277 f38db490-d61c-443f-a65b-d21fe96a405b
Free any datastores attached to dummy channels.

Revision 370205 added the use of a datastore attached to a dummy channel to
resolve a memory leak, but ast_dummy_channel_destructor() in this branch did
not free datastores, resulting in a continued (but slightly smaller) memory
leak. This patch backports the change to free said datastores from the Asterisk
trunk.

(related to issue AST-916)
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370361 f38db490-d61c-443f-a65b-d21fe96a405b
Improve documentation for the SHELL() dialplan function.
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370384 f38db490-d61c-443f-a65b-d21fe96a405b
Rewrite a comment that didn't adequately explain the code it was documenting.
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370430 f38db490-d61c-443f-a65b-d21fe96a405b
chan_oss: fix "sample rate" error message

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370432 f38db490-d61c-443f-a65b-d21fe96a405b
res_agi: Add message indicating need for \n character in verbose message

The while loop responsible for reading AGI messages from a fastAGI service
can end up looping indefinitely when an AGI script fails to indicate the end
of a message with a \n character. This patch adds an indication that we are
expecting a \n character to end the message to make it more clear to users
that this is necessary if they are receiving this warning over and over.

(issue ASTERISK-20061)
Reported by: Eike Kuiper
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370495 f38db490-d61c-443f-a65b-d21fe96a405b
app_meetme: Change app_meetme support level to extended from deprecated

(closes issue ASTERISK-20134)
Reported by: Leif Madsen


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370547 f38db490-d61c-443f-a65b-d21fe96a405b
Release B channel allocation on error path in chan_misdn.
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370564 f38db490-d61c-443f-a65b-d21fe96a405b
Help mitigate potential reinvite glare scenarios.

When Asterisk servers are set up back-to-back, and
direct media is to be used betweeen endpoints, it is
fairly common for the two Asterisk servers to send
direct media reinvites to each other simultaneously.
This results in 491s and ACKs being exchanged between
the servers. While the media eventually gets set up
properly, the problem is that there can be a noticeable
delay for the streams to stabilize.

This patch adds a new directmedia option called "outgoing".
With this set, an immediate direct media reinvite will only
be sent if the call direction is outgoing. For incoming
dialogs, an immediate direct media reinvite will not be sent,
but further "reactionary" direct media reinvites may be sent.

For those who are having some deja vu, that's because this
patch was originally committed to trunk since there is a
new configuration option added. After seeing a bug report
about audio being slow to set up on SIP calls, it became
apparent that this patch would be the best solution for
resolving the issue. The patch is unintrusive and will
have no effect unless the option is explicitly enabled.

(closes issue AST-896)
reported by Thomas Arimont

(closes issue ASTERISK-19857)
reported by Matt Jordan
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370619 f38db490-d61c-443f-a65b-d21fe96a405b
Clean up and ensure proper usage of alloca()

This replaces all calls to alloca() with ast_alloca() which calls gcc's
__builtin_alloca() to avoid BSD semantics and removes all NULL checks
on memory allocated via ast_alloca() and ast_strdupa().

(closes issue ASTERISK-20125)
Review: https://reviewboard.asterisk.org/r/2032/
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370643 f38db490-d61c-443f-a65b-d21fe96a405b
Schedule pokes of registered SIP peers within a given timespan after SIP reload

With a large number of SIP peers registered, performing a SIP reload causes a
flood of SIP OPTIONS request packets.  These are immediately sent out, and, as
responses come back, can cause peers to be flagged as 'lagged' due to handling
of the many response messages.

This fix prevents this "packet storm" and schedules the pokes for a random
time.  That time varies between 1 ms and the peer's qualify time, or, if
the qualify time is unknown, the global qualifyfreq setting.

The committed patch has some very small modifications to the patch schmidts
wrote for the review.

(closes issue ASTERISK-19154)
Reported by: Nicolo Mazzon
patches:
  issue19154.patch license #6034 uploaded by schmidts

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

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370672 f38db490-d61c-443f-a65b-d21fe96a405b
Revert alloca changes for utils

These changes were a tad overzealous in the utils directory.
Unfortunately, these don't compile with a "make".
........

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


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/10@370698 f38db490-d61c-443f-a65b-d21fe96a405b