Matthew Jordan: User Summary

More tweaking in lock.

Fix channel opaquification slip-up in r365477

Those channels are opaque now...

Support VoiceMail d() option when extension does not exist in channel's context

The VoiceMail d([c]) option is documented to accept digits for a new extension
in context <c>, if played during the greeting.  This option works fine if the
extension being redirected to has an extension with the same initial digit in
the channel's current context.  If that digit did not happen to exist in some
extension, a dialplan match would fail and the user would not be redirected.

This patch fixes it such that if the <c> option is used, the extensions are
matched in that context as opposed to the caller's original context.

(closes issue ASTERISK-18243)
Reported by: mjordan
Tested by: mjordan

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

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

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

Support VoiceMail d() option when extension does not exist in channel's context

The VoiceMail d([c]) option is documented to accept digits for a new extension
in context <c>, if played during the greeting.  This option works fine if the
extension being redirected to has an extension with the same initial digit in
the channel's current context.  If that digit did not happen to exist in some
extension, a dialplan match would fail and the user would not be redirected.

This patch fixes it such that if the <c> option is used, the extensions are
matched in that context as opposed to the caller's original context.

(closes issue ASTERISK-18243)
Reported by: mjordan
Tested by: mjordan

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

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

Support VoiceMail d() option when extension does not exist in channel's context

The VoiceMail d([c]) option is documented to accept digits for a new extension
in context <c>, if played during the greeting.  This option works fine if the
extension being redirected to has an extension with the same initial digit in
the channel's current context.  If that digit did not happen to exist in some
extension, a dialplan match would fail and the user would not be redirected.

This patch fixes it such that if the <c> option is used, the extensions are
matched in that context as opposed to the caller's original context.

(closes issue ASTERISK-18243)
Reported by: mjordan
Tested by: mjordan

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

Fix error that caused truncate operations to fail

Another very inappropriate placement of a ')' (again introduced in r362151)
caused the various truncate operations to attempt to truncate the sound file
at a position of '0'.

(issue ASTERISK-19655)
Reported by: Matt Jordan

(issue ASTERISK-19810)
Reported by: colbec
........

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

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

Fix error that caused truncate operations to fail

Another very inappropriate placement of a ')' (again introduced in r362151)
caused the various truncate operations to attempt to truncate the sound file
at a position of '0'.

(issue ASTERISK-19655)
Reported by: Matt Jordan

(issue ASTERISK-19810)
Reported by: colbec
........

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

Fix error that caused truncate operations to fail

Another very inappropriate placement of a ')' (again introduced in r362151)
caused the various truncate operations to attempt to truncate the sound file
at a position of '0'.

(issue ASTERISK-19655)
Reported by: Matt Jordan

(issue ASTERISK-19810)
Reported by: colbec

Prevent overflow in calculation in ast_tvdiff_ms on 32-bit machines

The method ast_tvdiff_ms attempts to calculate the difference, in milliseconds,
between two timeval structs, and return the difference in a 64-bit integer.
Unfortunately, it assumes that the long tv_sec/tv_usec members in the timeval
struct are large enough to hold the calculated values before it returns.  On
64-bit machines, this might be the case, as a long may be 64-bits.  On 32-bit
machines, however, a long may be less (32-bits), in which case, the calculation
can overflow.

This overflow caused significant problems in MixMonitor, which uses the method
to determine if an audio factory, which has not presented audio to an audiohook,
is merely late in providing said audio or will never provide audio.  In an
overflow situation, the audiohook would incorrectly determine that an audio
factory that will never provide audio is merely late instead.  This led to
situations where a MixMonitor never recorded any audio.  Note that this happened
most frequently when that MixMonitor was started by the ConfBridge application
itself, or when the MixMonitor was attached to a Local channel.

(issue ASTERISK-19497)
Reported by: Ben Klang
Tested by: Ben Klang
Patches:
  32-bit-time-overflow-10-2012-04-26.diff (license #6283) by mjordan

(closes issue ASTERISK-19727)
Reported by: Mark Murawski
Tested by: Michael L. Young
Patches:
  32-bit-time-overflow-2012-04-27.diff (license #6283) by mjordan)

(closes issue ASTERISK-19471)
Reported by: feyfre
Tested by: feyfre

(issue ASTERISK-19426)
Reported by: Johan Wilfer

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

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

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

Prevent overflow in calculation in ast_tvdiff_ms on 32-bit machines

The method ast_tvdiff_ms attempts to calculate the difference, in milliseconds,
between two timeval structs, and return the difference in a 64-bit integer.
Unfortunately, it assumes that the long tv_sec/tv_usec members in the timeval
struct are large enough to hold the calculated values before it returns.  On
64-bit machines, this might be the case, as a long may be 64-bits.  On 32-bit
machines, however, a long may be less (32-bits), in which case, the calculation
can overflow.

This overflow caused significant problems in MixMonitor, which uses the method
to determine if an audio factory, which has not presented audio to an audiohook,
is merely late in providing said audio or will never provide audio.  In an
overflow situation, the audiohook would incorrectly determine that an audio
factory that will never provide audio is merely late instead.  This led to
situations where a MixMonitor never recorded any audio.  Note that this happened
most frequently when that MixMonitor was started by the ConfBridge application
itself, or when the MixMonitor was attached to a Local channel.

(issue ASTERISK-19497)
Reported by: Ben Klang
Tested by: Ben Klang
Patches:
  32-bit-time-overflow-10-2012-04-26.diff (license #6283) by mjordan

(closes issue ASTERISK-19727)
Reported by: Mark Murawski
Tested by: Michael L. Young
Patches:
  32-bit-time-overflow-2012-04-27.diff (license #6283) by mjordan)

(closes issue ASTERISK-19471)
Reported by: feyfre
Tested by: feyfre

(issue ASTERISK-19426)
Reported by: Johan Wilfer

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

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

Prevent overflow in calculation in ast_tvdiff_ms on 32-bit machines

The method ast_tvdiff_ms attempts to calculate the difference, in milliseconds,
between two timeval structs, and return the difference in a 64-bit integer.
Unfortunately, it assumes that the long tv_sec/tv_usec members in the timeval
struct are large enough to hold the calculated values before it returns.  On
64-bit machines, this might be the case, as a long may be 64-bits.  On 32-bit
machines, however, a long may be less (32-bits), in which case, the calculation
can overflow.

This overflow caused significant problems in MixMonitor, which uses the method
to determine if an audio factory, which has not presented audio to an audiohook,
is merely late in providing said audio or will never provide audio.  In an
overflow situation, the audiohook would incorrectly determine that an audio
factory that will never provide audio is merely late instead.  This led to
situations where a MixMonitor never recorded any audio.  Note that this happened
most frequently when that MixMonitor was started by the ConfBridge application
itself, or when the MixMonitor was attached to a Local channel.

(issue ASTERISK-19497)
Reported by: Ben Klang
Tested by: Ben Klang
Patches:
  32-bit-time-overflow-10-2012-04-26.diff (license #6283) by mjordan

(closes issue ASTERISK-19727)
Reported by: Mark Murawski
Tested by: Michael L. Young
Patches:
  32-bit-time-overflow-2012-04-27.diff (license #6283) by mjordan)

(closes issue ASTERISK-19471)
Reported by: feyfre
Tested by: feyfre

(issue ASTERISK-19426)
Reported by: Johan Wilfer

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

Allow for reloading SRTP crypto keys within the same SIP dialog

As a continuation of the patch in r356604, which allowed for the
reloading of SRTP keys in re-INVITE transfer scenarios, this patch
addresses the more common case where a new key is requested within
the context of a current SIP dialog.  This can occur, for example, when
certain phones request a SIP hold.

Previously, once a dialog was associated with an SRTP object, any
subsequent attempt to process crypto keys in any SDP offer - either
the current one or a new offer in a new SIP request - were ignored.  This
patch changes this behavior to only ignore subsequent crypto keys within
the current SDP offer, but allows future SDP offers to change the keys.

(issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont

Review: https://reviewboard.asteriskorg/r/1885/
........

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

AST-2012-005: Fix remotely exploitable heap overflow in keypad button handling

When handling a keypad button message event, the received digit is placed into
a fixed length buffer that acts as a queue.  When a new message event is
received, the length of that buffer is not checked before placing the new digit
on the end of the queue.  The situation exists where sufficient keypad button
message events would occur that would cause the buffer to be overrun.  This
patch explicitly checks that there is sufficient room in the buffer before
appending a new digit.

(closes issue ASTERISK-19592)
Reported by: Russell Bryant
........

Merged revisions 363100 from http://svn.asterisk.org/svn/asterisk/branches/1.6.2
........

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

Check for IO stream failures in various format's truncate/seek operations

For the formats that support seek and/or truncate operations, many of
the C library calls used to determine or set the current position indicator
in the file stream were not being checked.  In some situations, if an error
occurred, a negative value would be returned from the library call.  This
could then be interpreted inappropriately as positional data.

This patch checks the return values from these library calls before
using them in subsequent operations.

(issue ASTERISK-19655)
Reported by: Matt Jordan

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

Fix remotely exploitable stack overrun in Milliwatt

Milliwatt is vulnerable to a remotely exploitable stack overrun when using
the 'o' option.  This occurs due to the milliwatt_generate function not
accounting for AST_FRIENDLY_OFFSET when calculating the maximum number of
samples it can put in the output buffer.  For channels using a format with
a sample rate less than 32kHz, the buffer overrun should not be possible as
the buffer allocated is sufficient to hold the data, even with no bounds
checking.  For formats with a sample rate greater then 32kHz however, the
fixed length buffer will be overrun.

This patch resolves this issue by taking into account AST_FRIENDLY_OFFSET
when determining the maximum number of samples allowed.  Note that at no
point is remote code execution possible.  The data that is written into the
buffer is the pre-defined Milliwatt data, and not custom data.

(closes issue ASTERISK-19541)
Reported by: Russell Bryant
Tested by: Matt Jordan
Patches:
  milliwatt_stack_overrun.rev1.txt by Russell Bryant (license 6283)
  Note that this patch was written by Russell, even though Matt uploaded it
........

Merged revisions 359645 from http://svn.asterisk.org/svn/asterisk/branches/1.6.2
........

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

Allow SRTP policies to be reloaded

Currently, when using res_srtp, once the SRTP policy has been added to the
current session the policy is locked into place.  Any attempt to replace an
existing policy, which would be needed if the remote endpoint negotiated a new
cryptographic key, is instead rejected in res_srtp.  This happens in particular
in transfer scenarios, where the endpoint that Asterisk is communicating with
changes but uses the same RTP session.

This patch modifies res_srtp to allow remote and local policies to be reloaded
in the underlying SRTP library.  From the perspective of users of the SRTP API,
the only change is that the adding of remote and local policies are now added
in a single method call, whereas they previously were added separately.  This
was changed to account for the differences in handling remote and local
policies in libsrtp.

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

(closes issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches:
  srtp_renew_keys_2012_02_22.diff uploaded by Matt Jordan (license 6283)
  (with some small modifications for this check-in)

Free successfully translated frame in fax_gateway_framehook

A frame that is translated via ast_translate is also duplicated via ast_frdup.
This will allocate a new frame on the heap, which needs to be free'd
at the appropriate time.  This issue reporter used valgrind to find that this
occurred in res_fax's fax_gateway_framehook; a quick search through the code
showed that only place this was currently not handling the translatted frame
properly.

(closes issue ASTERISK-19133)
Reported by: Sylvain Rochet
........

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

Allow overriding of IMAP server settings on a user by user basis

This patch allows the imapserver, imapport, and imapflags settings to be
overridden for any voicemail user.  It also documents the settings in
the sample voicemail.conf file, and updates the voicemail schema to
allow storage of those columns.

(closes issue ASTERISK-16489)
Reporter: Hubert Mickael
Tested by: Matt Jordan

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

Fix for memory leaks / cleanup in cel_pgsql

There were a number of issues in cel_pgsql's pgsql_log method:
* If either sql or sql2 could not be allocated, the method would return while
the pgsql_lock was still locked
* If the execution of the log statement succeeded, the sql and sql2 structs
were never free'd
* Reconnection successes were logged as ERRORs.  In general, the severity of
several logging statements was reduced

(closes issue ASTERISK-18879)
Reported by: Niolas Bouliane
Tested by: Matt Jordan

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

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

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

Backed out core changes from r346391

During testing, it was discovered that there were a number of side effects
introduced by r346391 and subsequent check-ins related to it (r346429,
r346617, and r346655).  This included the /main/stdtime/ test 'hanging',
as well as the remote console option failing to receive the appropriate output
after a period of time.

I only backed out the changes to main/ and utils/, as this was adequate
to reverse the behavior experienced.

(issue ASTERISK-18974)

Added support for all slin formats to app_originate

Previously, app_originate could not originate a call into a non-8kHz conference
bridge as the formats for non-8kHz slin codecs were not applied to the created
channel.  This patch adds all of the formats by default, such that if a created
channel has a codec that supports a higher sampling rate, a translation path
can be built between it and other channels.
........

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

Fixed Asterisk crash when function QUEUE_MEMBER receives invalid input

The function QUEUE_MEMBER has two required parameters (queuename, option).  It
was only checking for the presence of queuename.  The patch checks for the
existence of the option parameter and provides better error logging when
invalid values are provided for the option parameter as well.
........

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

Fixed SendMessage stripping extension from To: header in SIP MESSAGE

When using the MessageSend application to send a SIP MESSAGE to a non-peer,
chan_sip attempted to validate the hostname or IP Address.  In the process,
it stripped off the extension and failed to add it back to the sip_pvt
structure before transmitting.  This patch adds the full URI passed in
from the message core to the sip_pvt structure.

(closes issue ASTERISK-18903)
Reported by: Shaun Clark
Tested by: Matt Jordan

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

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

Fixed crash from orphaned MWI subscriptions in chan_sip

This patch resolves the issue where MWI subscriptions are orphaned
by subsequent SIP SUBSCRIBE messages.  When a peer is removed, either
by pruning realtime SIP peers or by unloading / loading chan_sip, the
MWI subscriptions that were orphaned would still be on the event engine
list of valid subscriptions but have a pointer to a peer that no longer
was valid.  When an MWI event would occur, this would cause a seg fault.

(closes issue ASTERISK-18663)
Reported by: Ross Beer
Tested by: Ross Beer, Matt Jordan
Patches:
  blf_mwi_diff_12_06_11.txt uploaded by Matt Jordan (license 6283)

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

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

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

Improve error message in CONFBRIDGE_INFO

Provided a more descriptive error message when a value supplied for the parameter
type is not one of the acceptable values.

(closes issue ASTERISK-18717)
Reported by: Paul Belanger
Patches:
  __20111103-better-confbridge_info-error-msg.txt (License #4999)

Update SIP MESSAGE To parsing to correctly handle URI

The previous patch (r346040) incorrectly parsed the URI in the presence
of a port, e.g., user@hostname:port would fail as the port would be
double appended to the SIP message.  This patch uses the parse_uri function
to correctly parse the URI into its username and hostname parts, and places
them in the correct fields in the sip_pvt structure.

(issue ASTERISK-18903)
Review: https://reviewboard.asterisk.org/r/1597/
........

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

Merged revisions 340165 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/10

................
  r340165 | mjordan | 2011-10-10 15:30:18 -0500 (Mon, 10 Oct 2011) | 20 lines
  
  Merged revisions 340164 via svnmerge from
  https://origsvn.digium.com/svn/asterisk/branches/1.8
  
  ........
    r340164 | mjordan | 2011-10-10 15:23:48 -0500 (Mon, 10 Oct 2011) | 13 lines
    
    Updated chan_sip to place calls on hold if SDP address in INVITE is ANY
    
    This patch fixes the case where an INVITE is received with c=0.0.0.0 or ::.
    In this case, the call should be placed on hold.  Previously, we checked for
    the address being null; this patch keeps that behavior but also checks for
    the ANY IP addresses.
    
    Review: https://reviewboard.asterisk.org/r/1504/
    
    (closes issue ASTERISK-18086)
    Reported by: James Bottomley
    Tested by: Matt Jordan
  ........
................

Fix channel opaquification slip-up in r365477

Those channels are opaque now...

Support VoiceMail d() option when extension does not exist in channel's context

The VoiceMail d([c]) option is documented to accept digits for a new extension
in context <c>, if played during the greeting.  This option works fine if the
extension being redirected to has an extension with the same initial digit in
the channel's current context.  If that digit did not happen to exist in some
extension, a dialplan match would fail and the user would not be redirected.

This patch fixes it such that if the <c> option is used, the extensions are
matched in that context as opposed to the caller's original context.

(closes issue ASTERISK-18243)
Reported by: mjordan
Tested by: mjordan

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

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

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

Fix error that caused truncate operations to fail

Another very inappropriate placement of a ')' (again introduced in r362151)
caused the various truncate operations to attempt to truncate the sound file
at a position of '0'.

(issue ASTERISK-19655)
Reported by: Matt Jordan

(issue ASTERISK-19810)
Reported by: colbec
........

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

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

Prevent overflow in calculation in ast_tvdiff_ms on 32-bit machines

The method ast_tvdiff_ms attempts to calculate the difference, in milliseconds,
between two timeval structs, and return the difference in a 64-bit integer.
Unfortunately, it assumes that the long tv_sec/tv_usec members in the timeval
struct are large enough to hold the calculated values before it returns.  On
64-bit machines, this might be the case, as a long may be 64-bits.  On 32-bit
machines, however, a long may be less (32-bits), in which case, the calculation
can overflow.

This overflow caused significant problems in MixMonitor, which uses the method
to determine if an audio factory, which has not presented audio to an audiohook,
is merely late in providing said audio or will never provide audio.  In an
overflow situation, the audiohook would incorrectly determine that an audio
factory that will never provide audio is merely late instead.  This led to
situations where a MixMonitor never recorded any audio.  Note that this happened
most frequently when that MixMonitor was started by the ConfBridge application
itself, or when the MixMonitor was attached to a Local channel.

(issue ASTERISK-19497)
Reported by: Ben Klang
Tested by: Ben Klang
Patches:
  32-bit-time-overflow-10-2012-04-26.diff (license #6283) by mjordan

(closes issue ASTERISK-19727)
Reported by: Mark Murawski
Tested by: Michael L. Young
Patches:
  32-bit-time-overflow-2012-04-27.diff (license #6283) by mjordan)

(closes issue ASTERISK-19471)
Reported by: feyfre
Tested by: feyfre

(issue ASTERISK-19426)
Reported by: Johan Wilfer

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

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

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

Allow for reloading SRTP crypto keys within the same SIP dialog

As a continuation of the patch in r356604, which allowed for the
reloading of SRTP keys in re-INVITE transfer scenarios, this patch
addresses the more common case where a new key is requested within
the context of a current SIP dialog.  This can occur, for example, when
certain phones request a SIP hold.

Previously, once a dialog was associated with an SRTP object, any
subsequent attempt to process crypto keys in any SDP offer - either
the current one or a new offer in a new SIP request - were ignored.  This
patch changes this behavior to only ignore subsequent crypto keys within
the current SDP offer, but allows future SDP offers to change the keys.

(issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont

Review: https://reviewboard.asteriskorg/r/1885/
........

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

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

Reference skinny_subchannel object instead of skinny_device for r363103

The check-in to resolve ASTERISK-19592 (r363103) failed to switch to the
skinny_subchannel object instead of the skinny_device when attempting to
reference the buffer for the keypad digits.  This patch fixes that.

(issue ASTERISK-19592)
Reported by: Russell Bryant

AST-2012-005: Fix remotely exploitable heap overflow in keypad button handling

When handling a keypad button message event, the received digit is placed into
a fixed length buffer that acts as a queue.  When a new message event is
received, the length of that buffer is not checked before placing the new digit
on the end of the queue.  The situation exists where sufficient keypad button
message events would occur that would cause the buffer to be overrun.  This
patch explicitly checks that there is sufficient room in the buffer before
appending a new digit.

(closes issue ASTERISK-19592)
Reported by: Russell Bryant
........

Merged revisions 363100 from http://svn.asterisk.org/svn/asterisk/branches/1.6.2

Fix places in main where a negative return value could impact execution

This patch addresses a number of modules in main that did not handle the
negative return value from function calls adequately, or were not sufficiently
clear that the conditions leading to improper handling of the return values
could not occur.  This includes:

* asterisk.c: A negative return value from the read function would be used
directly as an index into a buffer.  We now check for success of the read
function prior to using its result as an index.

* manager.c: Check for failures in mkstemp and lseek when handling the
temporary file created for processing data returned from a CLI command in
action_command.  Also check that the result of an lseek is sanitized prior
to using it as the size of a memory map to allocate.

(issue ASTERISK-19655)
Reported by: Matt Jordan

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

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

Fix error that caused seek format operations to set max file size to '1' or '0'

A very inappropriate placement of a ')' (introduced in r362151) caused the
maximum size of a file to be set as the result of a comparison operation, as
opposed to the result of the ftello operation.  This resulted in seeking being
restricted to the beginning of the file, or 1 byte into the file.  Thanks to
the Asterisk Test Suite for properly freaking out about this on at least one
test.

(issue ASTERISK-19655)
Reported by: Matt Jordan

Prevent invalid access of free'd memory if DAHDI channel during an MWI event

In the MWI processing loop, when a valid event occurs the temporary caller ID
information is deallocated.  If a new DAHDI channel is successfully created,
the event is passed up to the analog_ss_thread without error and the loop
exits.  If, however, the DAHDI channel is not created, then the caller ID
struct has been free'd, and the gains reset to their previous level.  This
will almost certainly cause an invalid access to the free'd memory, either
in subsequent calls to callerid_free or calls to callerid_feed.

This patch makes it so that we only free the caller ID structure if a
DAHDI channel is successfully created, and we bump the gains back up
if we fail to make a DAHDI channel.
........

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

Prevent invalid access of free'd memory if DAHDI channel during an MWI event

In the MWI processing loop, when a valid event occurs the temporary caller ID
information is deallocated.  If a new DAHDI channel is successfully created,
the event is passed up to the analog_ss_thread without error and the loop
exits.  If, however, the DAHDI channel is not created, then the caller ID
struct has been free'd, and the gains reset to their previous level.  This
will almost certainly cause an invalid access to the free'd memory, either
in subsequent calls to callerid_free or calls to callerid_feed.

This patch makes it so that we only free the caller ID structure if a
DAHDI channel is successfully created, and we bump the gains back up
if we fail to make a DAHDI channel.
........

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

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