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
The old prompts for the administrator menu were inadequate. They didn't mention
that the menu had additional options through the 8 key and pressing the 8 key
wouldn't reveal what those options were. This patch fixes all of that while
also organizing code pertaining to each individual menu type which was
previously all stored in one gigantic function along with many of the basic
conference functions.
(closes issue AST-996)
Reported by: John Bigelow
Review: http://reviewboard.digium.internal/r/360/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379885 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes two bugs:
* If an outbound call is made from a SLA phone using SLAStation, then there is
no ringtone audible to the phone that originates the call. The indication of
the ringing was not being passed to the SLA station; this patch fixes that
by passing through the progress indications.
* If an SLA station hangs up before the called party answers, then the channel
to the called party continues to ring until a timeout occurs. If the called
party manages to answer, Asterisk attempts to connect the called party to
a non-existant MeetMe room. This patch corrects the behavior by abandoning
the call attempt if it detects that the SLA station is no longer in use
while attempting to call the called party.
Review: https://reviewboard.asterisk.org/r/2275/
(closes issue ASTERISK-20462)
Reported by: dkerr
patches:
asterisk-11-bugid20440+20462.patch uploaded by dkerr (license 5558)
asterisk-11-bugid20462.patch uploaded by dkerr (license 5558)
(closes issue ASTERISK-20440)
Reported by: dkerr
patches:
asterisk-11-bugid20440.patch uploaded by dkerr (license 5558)
asterisk-11-bugid20440+20462.patch uploaded by dkerr (license 5558)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When r376428 was commited to re-order start up sequences to be more tolerant of
forking with thread primitives, a few items were changed that caused changes
in behavior on some distros. This includes:
* Not displaying the splash screen on a remote console.
* Displaying an error message on stderr when a remote console cannot connect
to a running instance of Asterisk.
In the first case, the splash screen was re-added (thanks to Michael L. Young).
In the second case, the various init.d scripts were modified to pipe stderr
to /dev/null, as the error message is useful - if you execute a remote
console or a remote console command execution and it fail, it should tell
you. Note that the error message was always present, it just failed to be
printed prior to r376428.
Much thanks to the folks who quickly reported this problem, provided solutions,
and promptly tested the various init.d scripts on a variety of distros.
(closes issue ASTERISK-20945)
Reported by: Warren Selby
Tested by: Michael L. Young, Jamuel Starkey, kaldemar, Danny Nicholas, mjordan
patches:
asterisk-20945-remote-intro-msg.diff uploaded by elguero (license 5026)
ASTERISK-20945-1.8-mjordan.diff uploaded by mjordan (license 6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When iLBC is being used with a jitter buffer and the jb has to
interpolate frames, it generates frames with a null pointer and a
non-zero datalen. This is now handled properly.
(closes issue ASTERISK-20914)
Reported By: John McEleney
Patches:
ASTERISK-20914-1.8.diff uploaded by Matt Jordan (license 6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add LDAP dev package to Debian/Ubuntu install list. Existed in Redhat already. Merged from 11 to Trunk in 379643. Sorry for forgeting 1.8
(issue ASTERISK-20886)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
An incorrect string initializations was left in ast_str_encode_mime from the
patch that converted string manipulations to use ast_str strings (r191140).
The string initialization causes a crash when ast_str_set is called on
the string later on in the function.
(closes issue ASTERISK-18697)
Reported by: Chris Boot
patches:
minivm-null-pointer-dereference-fix.patch uploaded by bootc (license 6309)
(issue ASTERISK-20854)
Reported by: Chris Warr
Tested by: Chris Warr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk forks itself into the background via a call to daemon, it must
re-set the pid value of the new process. Otherwise, astcanary gets the pid
value of the process before the fork, which prevents it from running. Asterisk
eventually starts lowering its priority, as it can no longer communicate
with the proverbial canary in the coal mine.
This patch ensures that the correct process identifier is used by astcanary.
(closes issue ASTERISK-20947)
Reported by: Jakob Hirsch
Tested by: mjordan
patches:
asterisk-10.12.0.astcanary_ppid.diff uploaded by Jakob Hirsch (license 6113)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Record-Route parsing copied the header into a char[256] array, which can
be a problem if the header is longer than that. This patch parses the
header in place, without the copy, avoiding the issue.
In addition to the original patch, I added a unit test for the new
get_in_brackets_const function.
(closes issue ASTERISK-20837)
Reported by: Corey Farrell
Patches:
chan_sip-build_route-optimized-rev1.patch uploaded by Corey Farrell (license 5909)
(with minor changes by dlee)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per the bluez API, in order to bind to the first available port, the rc_channel
field of the socket addressing structure used to bind the socket should be set
to 0. Previously, Asterisk had set the rc_channel field set to 1, causing it
to connect to whatever happens to be on port 1.
We could probably not explicitly set rc_channel to 0 since we memset the struct
earlier, but explicitly setting it will hopefully prevent someone from coming
in and setting it to some explicit port in the future.
(closes issue ASTERISK-16357)
Reported by: challado
Tested by: Alexander Heinz, Nikolay Ilduganov, benjamin, eliafino, David van Geyn
patches:
ASTERISK-16357.diff uploaded by Nikolay Ilduganov (license 6253)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The parser for SMS messages would incorrectly parse out the from number.
The parsing would incorrectly start scanning for the from number at the
same index as the first double quote ("); this would inadvertently cause
it to treat the first double quote as the terminating double quote for
the from number as well.
The SMSSRC should now populate correctly.
(closes issue ASTERISK-16822)
Reported by: menschentier
Tested by: Jonas Falck
patches:
fixSMSSRC.patch uploaded by jonax (license 6320)
(closes issue ASTERISK-19153)
Reported by: Panos Gkikakis
patches:
sms-sender-fix.diff uploaded by roeften (license 5884)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379178 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The chan_misdn channel driver will send a channel with an invalid destination
to the 'i' extension itself if said extension can be reached. It forgot,
however, to set the INVALID_EXTEN channel variable when it bounces the channel
to this extension. Dialplan writers everywhere moaned at yet another
inconsistency.
This is yet another example of why duplicating logic in multiple places results
in bugs that stick around in Jira for just under three years.
Yes: ASTERISK-15456 was created on January 18th, 2010. Patch committed on
January 15th, 2013. Ouch.
(closes issue ASTERISK-15456)
Reported by: Thomas Omerzu
patches:
chan_misdn_invalid.patch2 uploaded by Thomas Omerzu (license 5927)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@379145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
