When res_rtp_asterisk.c was altered to avoid attempting to apply
unprotect algorithms to non-audio RTP packets, the test used was
incorrect. This caused the audio packets to not be decrypted and
resulted in loud white noise on the other endpoint (or both endpoints
depending on the call legs involved). The test now properly checks the
version field in the RTP header to ensure that RTP and RTCP are
decrypted while other types of packets are not.
(closes issue ASTERISK-21323)
Reported by: andrea
Tested by: Kinsey Moore, andrea, John Bigelow
Patches:
whitenoise_fix.diff uploaded by Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@384048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When authenticating a SIP request with alwaysauthreject enabled, allowguest
disabled, and autocreatepeer disabled, Asterisk discloses whether a user
exists for INVITE, SUBSCRIBE, and REGISTER transactions in multiple ways. The
information is disclosed when:
* A "407 Proxy Authentication Required" response is sent instead of a
"401 Unauthorized" response
* The presence or absence of additional tags occurs at the end of "403
Forbidden" (such as "(Bad Auth)")
* A "401 Unauthorized" response is sent instead of "403 Forbidden" response
after a retransmission
* Retransmission are sent when a matching peer did not exist, but not when a
matching peer did exist.
This patch resolves these various vectors by ensuring that the responses sent
in all scenarios is the same, regardless of the presence of a matching peer.
This issue was reported by Walter Doekes, OSSO B.V. A substantial portion of
the testing and the solution to this problem was done by Walter as well - a
huge thanks to his tireless efforts in finding all the ways in which this
setting didn't work, providing automated tests, and working with Kinsey on
getting this fixed.
(closes issue ASTERISK-21013)
Reported by: wdoekes
Tested by: wdoekes, kmoore
patches:
AST-2013-003-1.8 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-10 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-11 uploaded by kmoore, wdoekes (License 6273, 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AST-2012-014, fixed in January of this year, contained a fix for Asterisk's
HTTP server for a remotely-triggered crash. While the fix put in place fixed
the possibility for the crash to be triggered, a denial of service vector still
exists with that solution if an attacker sends one or more HTTP POST requests
with very large Content-Length values. This patch resolves this by capping
the Content-Length at 1024 bytes. Any attempt to send an HTTP POST with
Content-Length greater than this cap will not result in any memory allocation.
The POST will be responded to with an HTTP 413 "Request Entity Too Large"
response.
This issue was reported by Christoph Hebeisen of TELUS Security Labs
(closes issue ASTERISK-20967)
Reported by: Christoph Hebeisen
patches:
AST-2013-002-1.8.diff uploaded by mmichelson (License 5049)
AST-2013-002-10.diff uploaded by mmichelson (License 5049)
AST-2013-002-11.diff uploaded by mmichelson (License 5049)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r373424, several reentrancy problems in chan_sip were addressed. As a
result, the SIP channel driver is now properly locking the channel driver
private information in certain operations that it wasn't previously. This
exposed two latent problems either in register_verify or by functions called
by register_verify. This includes:
* Holding the private lock while calling sip_send_mwi_to_peer. This can create
a new sip_pvt via sip_alloc, which will obtain the channel container lock.
This is a locking inversion, as any channel related lock must be obtained
prior to obtaining the SIP channel technology private lock.
* Holding the privat elock while calling sip_poke_peer. In the same vein as
sip_send_mwi_to_peer, sip_poke_peer can create a new SIP private, causing
the same locking inversion.
Note that this locking inversion typically occured when CLI commands were run
while a SIP REGISTER request was being processed, as many CLI commands (such
as 'sip show channels', 'core show channels', etc.) have to obtain the channel
container lock.
(issue ASTERISK-21068)
Reported by: Nicolas Bouliane
(issue ASTERISK-20550)
Reported by: David Brillert
(issue ASTERISK-21314)
Reported by: Badalian Vyacheslav
(issue ASTERISK-21296)
Reported by: Gabriel Birke
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
r375757 attempted to resolve a race condition between multiple submissions of
CDRs while in batch mode from attempting to destroy the scheduled batch
submission by extending the batch CDR lock. Unfortunately, this causes a
deadlock between the pending CDR lock and the batch CDR lock. This patch
resolves the intent of r375757 by simply providing a new lock that protects
the scheduling of the batches. The original batch CDR lock is kept to protect
manipulation of the batch CDR settings, but has been placed such that it
is not held when the pending lock is held.
Thanks to Chase Venters for providing lock analysis on the issue.
(issue ASTERISK-21162)
Reported by: Chase Venters
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383839 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an SLA trunk is ringing (inbound call on the trunk) Asterisk will
make outbound calls to the stations that have that trunk. If more than
one station answers the call at the same time, all channels other than
the first one to answer are left in a bad state. The channel gets
leaked, is not connected to anything, and there's no way to get rid of
it.
We now properly clean up these losing channels by hanging up on them.
Since they lost the race, as we process their answer, there is no
ringing trunk for them to answer.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CALLEDTON channel variable is set for incoming ISDN calls to the lower
7 bits of the Q.931 type-of-number/numbering-plan octet. The
CALLERID(dnid-num-plan) should have the same value.
(closes issue ASTERISK-21248)
Reported by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI, HTTP, and chan_sip all support TLS in some way, but none of them
support all the options that Asterisk's TLS core is capable of
interpreting. This prevents consumers of the TLS/SSL layer from setting
TLS/SSL options that they do not support.
This also gets tlsverifyclient closer to a working state by requesting
the client certificate when tlsverifyclient is set. Currently, there is
no consumer of main/tcptls.c in Asterisk that supports this feature and
so it can not be properly tested.
Review: https://reviewboard.asterisk.org/r/2370/
Reported-by: John Bigelow
Patch-by: Kinsey Moore
(closes issue AST-1093)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a session timer expires during a dialog that has re-negotiated to T.38
and Asterisk is the refresher, Asterisk will send a re-INVITE with an SDP
containing audio media only. This causes some hilarity with the poor fax
session under weigh.
This patch corrects that by sending T.38 parameters if we are in the middle of
a T.38 session.
(closes issue ASTERISK-21232)
Reported by: Nitesh Bansal
patches:
dont-send-audio-reinvite-for-sess-timer-in-t38-call.patch uploaded by nbansal (License 6418)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In certain situations, call files are not processed when using KQueue with
pbx_spool. Asterisk was sending an invalid timeout value when the spool
directory is empty, causing the call to kevent to error immediately. This
can create a tight loop, increasing the CPU load on the system.
(closes issue ASTERISK-21176)
Reported by: Carlton O'Riley
patches:
kqueue_osx.patch uploaded by coriley (License 6473)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@383120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When retrieving the parking lots from a MySQL database table, the current order
is "filename, cat_metric desc, var_metric asc, category". If there are multiple
parking lots with the same cat_metric but different categories, everything is
being sorted on cat_metric first resulting in errors when loading the parking
lots.
This patch fixes the problem by sorting on the category field first, then the
cat_metric field.
(closes issue ASTERISK-21035)
Reported by: Alex Epshteyn
Patches:
asterisk-21035-orderby.diff Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382942 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit updates some fields in the contributed realtime schema files to
handle IPv6 addresses.
(closes issue ASTERISK-21173)
Reported by: Torrey Searle
Patches:
realtime_sql.patch Torrey Searle (license 5334)
asterisk-21173-update-ip-fields.diff Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-17888, the AMI Registry event during SIP registrations was supposed
to include the Username field. Somehow, one of the events was missed. This
patch corrects that - the Username field should be included in all AMI Registry
events involving SIP registrations.
(issue ASTERISK-17888)
(closes issue ASTERISK-21201)
Reported by: Dmitriy Serov
patches:
chan_sip.c.diff uploaded by Dmitriy Serov (license 6479)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'A' and 'n' options for Page() mention that the announcement will
be played simultaneously. This is not necessarily the case.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382513 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A deadlock can occur in chan_iax2 when it attempts to set the caller ID, as it
already holds the iax2 private lock and improperly fails to obtain the channel
lock before calling ast_set_callerid. By not safely obtaining the channel lock,
a locking inversion can take place, causing a deadlock.
This patch solves this by calling the required deadlock avoidance functions
that obtain the channel lock before setting the caller ID.
Thanks to Pavel for fixing my syntax errors and testing this patch out.
(closes issue ASTERISK-21128)
Reported by: Pavel Troller
Tested by: Pavel Troller
patches:
ASTERISK-21128-1.8.diff uploaded by mjordan (license 6283)
ASTERISK-21128-modified-1.8.diff uploaded by Pavel Troller (license 6302)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382233 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some channel drivers, specifically those that have a varying rate in the
number of audio samples, the audio quality for a MeetMe conference can be
exceedingly poor. This is due to a unilateral application of the DENOISE
function in func_speex to channels joining the conference.
The denoiser function in the speex library is initialized with the number of
audio samples in each sample that will be provided to it. If the number of
audio samples changes, the denoiser has to be thrown away and re-initialized.
While this could be worked around by removing func_speex, that doesn't help
if you actually use the denoiser with other channels on the system.
This patches does the following:
* Checks for the presence of func_speex as opposed to codec_speex when
determining if the DENOISE function is present (which is where the function
is actually implemented)
* Adds an option to MeetMe 'n' that causes the denoiser to not be applied
to a channel when it joins. This keeps the current behavior the default, but
let's users disable the denoiser if it causes problems on their system.
Review: https://reviewboard.asterisk.org/r/2358
(closes issue AST-1062)
Reported by: Thomas Arimont
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As of r380520 the configure scripts converts the value of linux-gnueabi*
of OSARCH to "linux-gnu". So no point in testing for those values.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There were several problems using variadic argument macros in res_config_mysql.
* Improper use of va_end. Multiple calls to va_end were possible resulting in
an unbalanced matching of va_start/va_end.
* Calls to va_arg after a possible encounter of a SENTINEL value.
This patch corrects those errors.
(closes issue ASTERISK-19451)
Reported by: wdoekes
patches:
ASTERISK-19451-1.8--2.diff uploaded by wdoekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@382021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Somehow, chan_jingle has managed to operate for years without setting the
sin_family on its bindaddr socket. This patch properly sets the field during
initial module load to AF_INET.
Note that the patch on the issue was modified slightly to change the
initialization of the socket from allocation of a chan_jingle private to the
module initialization, as the bindaddr object (which is static) only needs to
have the address set once.
(closes issue ASTERISK-19341)
Reported by: andre valentin
patches:
0105-chan_jingle.patch uploaded by avalentin (License 6064)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When converting AMI class authorizations to a string representation, the
method always appends the ALL class authorization. This is especially
important for events, as they should always communicate that class
authorization - even if the event itself does not specify ALL as a class
authorization for itself. (Events have always assumed that the ALL class
authorization is implied when they are raised)
Unfortunately, this did mean that specifying a user with restricted class
authorizations would show up in the 'manager show user' CLI command as
having the ALL class authorization.
Rather then modifying the existing string manipulation function, this patch
adds a function that will only return a string if the field being compared
explicitly matches class authorization field it is being compared against.
This prevents ALL from being returned unless it is actually specified for
the user.
(closes issue ASTERISK-20397)
Reported by: Johan Wilfer
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ParkAndAnnounce application documentation for the optional return_context
parameter states the following:
return_context
The goto-style label to jump the call back into after timeout. Default
'priority+1'.
Unfortunately, the application was sending the channel back into the dialplan
at 'priority', which is the ParkAndAnnounce application call. This causes an
infinite loop of the channel constantly being parked, announced, timed out,
parked, announced, timed out... while fun, especially for those callers you
wish to drive to the end of madness, this was not the intent of the
application.
(closes issue ASTERISK-20113)
Reported by: serginuez
patches:
app_parkandannounce.diff uploaded by serginuez (License 6405)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk was a little too pro-active in claiming that it found launchd. On
systems without launchd - such as FreeBSD - this resulted in certain items
in Asterisk that conflict with launchd to not be selectable, such as
res_timing_kqueue.
(closes issue ASTERISK-20749)
Reported by: Oleg Baranov
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The incorrect callid was being written to the "data1" field in queue_log table
for transfer events. The callid of the queue was being written instead of the
transfer target's callid. This now gets the correct "transfer to" number and
places that in the "data1" field of the queue_log table when a transfer event
is triggered.
(closes issue ASTERISK-19960)
Reported by: vladimir shmagin
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "registertrying" option was removed in r343220. The "rtp_engine"
option was added in r186078 but erroneously named "engine" in the sample.
Note that there is no global sip setting for a different engine.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381668 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The function call ast_db_deltree returns the number of row deleted, or a
negative number if it failed. DBdeltree was treating any non-zero return
as an error, causing a spurious verbose error message to be displayed.
This patch handles the return code of ast_db_deltree correctly.
(closes issue ASTERISK-21070)
Reported by: ianc
patches:
dbdeltree.diff uploaded by ianc (License #5955)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The RTP engine will no longer allow for local and remote native RTP bridges
if packetization of streams differs. Allowing native bridging in this scenario
has been known to cause FAX failures.
(closes ASTERISK-20650)
Reported by: Maciej Krajewski
Patches:
ASTERISK-20659.patch uploaded by Mark Michelson (License #5049)
Review: https://reviewboard.asterisk.org/r/2319
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If say.conf did not exists prior to originally loading module app_playback it
would not load on subsequent reloads of the module once it had been created.
This occurred because upon reload of the app_playback module it would only
load a new configuration if an old one had previously existed. This fix simply
removed the association between checking if an old configuration existed and
the loading of the new one.
(closes issue ASTERISK-20800)
Reported by: pgoergler
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@381216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When I added my extensive suite of session timer unit tests, apparently one of
them was failing and I never noticed. If neither Min-SE nor Session-Expires is
set in the header, it was responding with a Session-Expires of the global
maxmimum instead of the configured max for the endpoint.
(issue ASTERISK-20787)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380973 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, Asterisk only processed session timer information if both the
'Supported: timer' and 'Session-Expires' headers were present. However, the
Session-Expires header is optional. If we were to receive a request with a
Min-SE greater than our configured session-expires, we would respond with a
'Session-Expires' header that was too small.
This patch cleans the situation up a bit, always processing timer information
if the 'Supported: timer' header is present.
(closes issue ASTERISK-20787)
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/2299/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Building Asterisk on Raspbian with hard-float support fails as it uses the
string 'linux-gnueabihf' for host os, as opposed to 'linux-gnueabi'. This patch
modifies the configure script for Asterisk such that it will match on any
string beginning with 'linux-gnueabi', as opposed to requiring an explicit
match.
(closes issue ASTERISK-21006)
Reported by: Christian Hesse
Tested by: Christian Hesse
patches:
linux-gnueabihf.patch uploaded by Christian Hesse (license 6459)
linux-gnueabihf-autoconf.patch uploaded by Christian Hesse (license 6459)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC5347 section 2.5.2 states the following:
...
The attribute "T38MaxBitRate" was once incorrectly registered with
IANA as "T38maxBitRate" (lower-case "m"). In accordance with T.38
examples and common implementation practice, the form "T38MaxBitRate"
SHOULD be generated by implementations conforming to this package.
In general, it is RECOMMENDED that implementations of this package
accept lowercase, uppercase, and mixed upper/lowercase encodings of
all the T.38 attributes.
...
Asterisk currently does not perform case insensitive matching on the T.38
attributes. This causes the T38MaxBitRate attribute to be negotiated at
2400 baud instead of 14400 (or whatever value you actually wanted).
This patch makes it so that when we compare T.38 attributes, we do so in a case
insensitive fashion.
Note that while the issue reporter did not directly write the patch, they
contributed to it (and would have provided one themselves if the license had
gone through a tad faster), and hence get attribution for it.
(closes issue ASTERISK-20897)
Reported by: Eric Hill
Tested by: Eric Hill
patches:
-- uploaded by Eric Hill
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ICalendar module had a systemic memory leak on each fetch of data from
the ICalendar source. The previous fetched data was not being properly
disposed. This patch makes it so that before each fetch of data, we dispose
of the previously fetched data.
(closes issue ASTERISK-21012)
Reported by: Joel Vandal
Tested by: Joel Vandal
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Multiple channels logging in as the same agent can result in dead channels
waiting for a condition signal that will never come because another
channel thread stole it. A symptom is chan_sip repeatedly generating
warning messages about rescheduling autodestruction of dialogs with an
agent channel owner.
* Made only login_exec() (the app AgentLogin) clear the agent_pvt->chan
pointer to prevent multiple channels from logging in as the same agent.
agent_read(), agent_call(), and agent_set_base_channel() no longer
disconnect the agent channel from the agent_pvt. This also eliminates the
need to keep checking for agent_pvt->chan being NULL.
* Made agent_hangup() not wake up the AgentLogin agent thread until it is
done.
* Made agent_request() not able to get the agent until he has logged in
and any wrapup time has expired.
* Made agent_request() use ast_hangup() instead of agent_hangup() to
correctly dispose of a channel.
* Removed agent_set_base_channel(). Nobody calls it and it is a bad thing
in general.
* Made only agent_devicestate() determine the current device state of an
agent. Note: Agent group device states have never been supported.
Review: https://reviewboard.asterisk.org/r/2260/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original fix (r380043) for getting Asterisk to respond with the correct
tag overlooked some corner cases, and the fact that the same code is in 1.8.
This patch moves the building of the crypto line out of
sdp_crypto_process(). Instead, it merely copies the accepted tag. The call to
sdp_crypto_offer() will build the crypto line in all cases now, using a tag of
"1" in the case of sending offers.
(closes issue ASTERISK-20849)
Reported by: José Luis Millán
Review: https://reviewboard.asterisk.org/r/2295/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With ptlib 2.10.9, the configure script fails due to grep returning multiple
matches for the pattern it searches for. This patch updates the pattern
matching to return only the actual version for the symbol searched for,
PTLIB_VERSION.
(closes issue ASTERISK-20980)
Reported by: Stefan Reuter
patches:
ASTERISK-20980-1.patch uploaded by Stefan Reuter (license 5339)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is currently an edge case where call number 32768 might be allocated for
a call, even though the IAX2 protocol requires call numbers be only 15 bits.
This resulted in some unpredictable behavior when call number 32678 is chosen.
This patch was mostly written by Richard Mudgett via ReviewBoard. I'm just
committing it.
Review: https://reviewboard.asterisk.org/r/2293/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch came about due to a problem observed where wav files had an
empty header. The header is supposed to be updated in wav_close(). It
turns out that this was broken when the cache_record_files option from
asterisk.conf was enabled. The cleanup code was moving the file to its
final destination *before* running the close() method of the file
destructor, so the header didn't get updated.
Another problem here is that the move was being done before actually
closing the FILE *.
Finally, the last bug fixed here is that I noticed that wav_close()
checks for stream->filename to be non-NULL. In the previous cleanup
order, it's checking a pointer to freed memory. This doesn't actually
cause anything to break, but it's treading on dangerous waters. Now the
free() of stream->filename is happening after the format module's
close() method gets called, so it's safer.
Review: https://reviewboard.asterisk.org/r/2286/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@380210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
