Currently, if an acknowledgement of a timer fails Asterisk will not realize
that a serious error occurred and will continue attempting to use the timer's
file descriptor. This can lead to situations where errors stream to the
CLI/log file. This consumes significant resources, masks the actual problem
that occurred (whatever caused the timer to fail in the first place), and
can leave channels in odd states.
This patch propagates the errors in the timing resource modules up through
the timer core, and makes users of these timers handle acknowledgement
failures. It also adds some defensive coding around the use of timers
to prevent using bad file descriptors in off nominal code paths.
Note that the patch created by the issue reporter was modified slightly for
this commit and backported to 1.8, as it was originally written for
Asterisk 10.
Review: https://reviewboard.asterisk.org/r/2178/
(issue ASTERISK-20032)
Reported by: Jeremiah Gowdy
patches:
jgowdy-timerfd-6-22-2012.diff uploaded by Jeremiah Gowdy (license 6358)
........
Merged revisions 375893 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Manager's tcp/tls objects have a periodic function that purge old manager
sessions periodically. During shutdown, the underlying container holding
those sessions can be disposed of and set to NULL before the tcp/tls periodic
function is stopped. If the periodic function fires, it will attempt to
iterate over a NULL container.
This patch checks for whether or not the sessions container exists before
attempting to purge sessions out of it. If the sessions container is NULL,
we simply return.
Note that this error was also caught by the Asterisk Test Suite.
........
Merged revisions 375800 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375801 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Its perfectly acceptable to have a gateway session unreserved when we go to
first allocate one. Unreffing the reserved gateway session - when its NULL -
will result in an assertion error.
This problem was caught by the Asterisk Test Suite (once we had enough of the
debugging flags enabled)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does two things:
1) It properly unregisters the manager CLI commands
2) It cleans up AMI users on exit. Prior to this patch, the AMI users
were not being disposed of properly, resulting in a memory leak.
(closes issue ASTERISK-20646)
Reported by: Corey Farrell
patches:
manager_shutdown.patch uploaded by Corey Farrell (license 5909)
........
Merged revisions 375793 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AstDB uses prepared SQLite3 statements to retrieve data from the SQLite3
database. These statements should be finalized during Asterisk shutdown so
that the SQLite3 database can be properly closed. Failure to finalize the
statements results in a memory leak and a failure when closing the database.
This patch fixes those issues by ensuring that all prepared statements are
properly finalized at shutdown.
(closes issue ASTERISK-20647)
Reported by: Corey Farrell
patches:
astdb-sqlite3_close.patch uploaded by Corey Farrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is a modified version of a patch originally committed for the
Asterisk 11 branch in r375756. A portion of that patch, that fixed the
memory leak during unloading XML documentation, applies to branches 1.8
and 10 as well.
The patch for this issue was modified for these two branches.
(issue ASTERISK-20648)
Reported by: Corey Farrell
Tested by: mjordan
patches:
xmldoc-memory_leak.patch uploaded by Corey Farrell (license 5909)
........
Merged revisions 375758 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Asterisk Test Suite caught an error condition where a scheduled CDR batch
write can be deleted twice if two channels attempt to post their CDRs at the
same time. The batch CDR mutex is locked while the CDRs are appended to the
current batch list; however, it is unlocked prior to actually scheduling the
CDR write. As such, two threads can attempt to remove the currently scheduled
batch write at the same time, resulting in an assertion error.
This patch extends the time that the mutex is locked to encompass actually
scheduling the write. This prevents two threads from unscheduling the
currently scheduled write at the same time.
........
Merged revisions 375727 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375728 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Replace links to missing text files removed in the 1.6.x series with links to the wiki. Doxygen can handle URLs fine, don't atempt to quote them. Also update the wiki link in the Readme to get everyone on the same page.
(issue ASTERISK-20259)
........
Merged revisions 375698 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r375519 | rmudgett | 2012-10-30 16:06:15 -0500 (Tue, 30 Oct 2012) | 11 lines
chan_misdn: Timer primitives must be handled first.
The frm->addr is a different "address space" than the stack/instance
address of other Lx primitives. The test for B channel instance address
could fail.
Patches:
patch01_timers.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2888
........
r375520 | rmudgett | 2012-10-30 16:14:58 -0500 (Tue, 30 Oct 2012) | 10 lines
chan_misdn: Free memory in error paths and other memory leaks.
The one line commented with BUG is not easily fixable because there is no
de-init function one can call.
Patches:
patch02_memory.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2888
........
r375521 | rmudgett | 2012-10-30 16:38:41 -0500 (Tue, 30 Oct 2012) | 14 lines
chan_misdn: ISDN NT L2 de-establish/establish
* An NT-PTMP cannot de/establish L2 since it doesn't know the TEIs.
* On NT-PTP L2 is started when L1 is finally active in handle_l1.
* L2 deactivation logging cleanup.
* L2 aggregate link status is unknown for NT-PTMP, show as "UNKN".
* Removed unused functions and code for L2 handling.
Patches:
patch03_L2estab.diff (license #6372) patch uploaded by Guenther Kelleter
Modified
JIRA ABE-2888
........
r375522 | rmudgett | 2012-10-30 16:56:14 -0500 (Tue, 30 Oct 2012) | 22 lines
chan_misdn: Fix broken upper_id/lower_id usage.
Sending PH prim via lower_id layer (3 or 1) simply does not work. For TE
(3) it returns an error (len=-6) which is not evaluated by handle_l1(), so
the L1 layer status ends up wrong. Instead PH must be sent via L4, only
then does it reach L1 without an error message.
And NT PH prims only reach L1 when they are sent to layer 2 id.
--> use upper_id to send PH primitives.
* Check for errors in PH_(DE)ACTIVATE | CONFIRM.
* Debug messages are improved.
* The lower_id is now not used for anything, except: Why is lower_id layer
deleted when it wasn't created? I removed this code since it looks very
wrong.
Patches:
patch04_l1activation.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2888
........
r375523 | rmudgett | 2012-10-30 17:29:15 -0500 (Tue, 30 Oct 2012) | 31 lines
chan_misdn: Fix loss of B channels if L1 is down.
If you make 2 calls out an NT PTMP port which is not connected to any
phone, the B channel associated with that call becomes unusable until
Asterisk is restarted.
The problem is the EVENT_SETUP is queued when L1 is not up in
misdn_lib_send_event(). If L1 cannot be activated the event won't be
dequeued. It gets even worse when the call is hung up. The queued
EVENT_SETUP will be overwritten by an EVENT_DISCONNECT. The reserved B
channel then will never be freed. If later someone connects a phone to
the port, L1 will eventually activate and the queued EVENT_DISCONNECT is
sent down the stack. However, it is ignored because it is the wrong call
state.
The real fix would be that activation and queueing for a new SETUP is done
by the NT stack. But since it doesn't, the workaround must be removed
because it doesn't always work.
Fix: The event is no longer queued but immediately sent to the stack. If
L1 cannot be activated, the L3 state machine that was started by the
EVENT_SETUP will do its work, i.e. a timeout will release the B channel
properly. The SETUP possibly cannot be sent the first time but is resent
by T303 in case L1 could be activated.
Patches:
patch05_bchan-loss.diff (license #6372) patch uploaded by Guenther Kelleter
Modified
JIRA ABE-2888
........
r375524 | rmudgett | 2012-10-30 18:26:05 -0500 (Tue, 30 Oct 2012) | 13 lines
chan_misdn: Remove some calls to exit().
Try proper cleanup when something goes wrong in misdn_lib_init().
Especially do not call exit()!
* Fix memory leak because stack_destroy() does not free the stack struct.
Patches:
patch06_cleanup-init.diff (license #6372) patch uploaded by Guenther Kelleter
Modified
JIRA ABE-2888
........
Merged revisions 375519-375524 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
........
Merged revisions 375625 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375626 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at some debug logs, I noticed that it was being reported that the
SDP origin line was unsupported or failed. Upon looking into this on my local
machine, I found that I too was getting this debug message yet everything seemed
to be getting processed properly. What was discovered is, that, the variable to
determine what is displayed in the debug message for the SDP line that was
processed, was not being set for the origin line when the result was successful.
This patch fixes this and was tested on local machine.
........
Merged revisions 375594 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unlike all other calendar modules, res_calendar_ews fails to extract the Body
information for a calendar item. This is due, in part, to a quirk in the
schema in the XML - not only does a CalendarItem contain a Body element, but
the CalendarItem exists as a descendant of a different Body element. The neon
parser was erroneously skipping all Body elements.
This patch fixes that by bypassing Body elements that are not a child of
CalendarItem, and parsing the Body element out if it is a child.
Note that the original patch by Terry Wilson only needed slight modifications
to make it properly pull the Body information out; as such, while I've linked
to the patch that I uploaded for Dmitry, I've attributed the patch to Terry.
(closes issue ASTERISK-19738)
Reported by: Dmitry Burilov
Tested by: Dmitry Burilov
patches:
calendar_ews_body_2012_10_29.diff uploaded by Terry Wilson (license 6283)
........
Merged revisions 375528 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375531 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When confbridge was changed to handle conference status with a state machine in
r374658. The function responsible for starting recording for a conference was
refactored with the function actually responsible for launching the recording
thread being split into a function with another name. The old function name was
still used for manually started recordings through AMI or CLI. This patch fixes
that by switching which function is used to start recording the conference.
(closes issue ASTERISK-20601)
Reported by: Vilius
Patches:
confbridge_mixmonitor.diff uploaded by Jonathan Rose (license 6182)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are a few code paths where the Queue application fails to count a paused
or in use queue member as being 'busy'. This can cause callers to get stuck
in the Queue until a paused agent unpauses themselves.
(closes issue ASTERISK-20623)
Reported by: Bryan Walters
patches:
app_queue.patch uploaded by Bryan Walters (license 5851)
........
Merged revisions 375450 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375451 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a "sip reload" is issued for a SIP peer, then his
IP address will be cleared, thus resulting in forgetting the
public IP address. Asterisk will then attempt to route SIP
traffic to the private IP address.
The fix here is to make "sip reload" ignore realtime peers
when "host = dynamic" is spotted. Realtime peers can now only
have their IP address reset if they have gone from being not
dynamic to being dynamic.
(closes issue ASTERISK-18203)
reported by daren ferreira
(closes issue ASTERISK-20572)
reported by JoshE
Patches:
fix_nat_realtime.diff uploaded by JoshE (license #6075)
........
Merged revisions 375415 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The tech support customer was using the AMI Redirect action shortly after
a call was placed. While the channel tried to do an ast_read(), the
masquerade resulting from the channel redirect took place. The masquerade
in the middle of the ast_read() resulted in the segfault.
(closes issue AST-1025)
Reported by: Trey Blancher
Patches:
jira_ast_1025_v1.8_v2.patch (license #5621) patch uploaded by rmudgett
........
Merged revisions 375361 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_app_group_match_get_count allocates memory with the regcomp
function and we previously forgot to free it when bailing out
due to a regex compilation failure against category.
(closes issue AST-1018)
Reported by: Guenther Kelleter
Patches:
regcomp_memleak.diff uploaded by Guenther Kelleter (license 6372)
........
Merged revisions 375299 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375300 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, adding, removing or reloading members to rrmemory would
cause the order to become completely jumbled. Now it behaves more or less like
rrordered other than the fact that it stores the members on a hash table rather
than a linked list. This patch also prevents removal of members and member
reloads from jumbling rrordered queues.
(issue AST-989)
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2164/
........
Merged revisions 375216 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Make git more attractive for managing work-in-progress. Especially
convenient when a potential patch set needs to be tested on multiple
platforms since one can use git to keep all the test environments in sync
independent of a subversion server.
Now the Asterisk version will show the exact git SHA5 that was used when
building (still appended by "M" if there are local modifications) from a
git clone of the Asterisk repository so the developer can more easily know
what is actually under test.
You will now get this:
$ asterisk -V
Asterisk GIT-1698298
Instead of this:
$ asterisk -V
Asterisk UNKNOWN__and_probably_unsupported
This has zero impact for those not using git with the exception of an
extra test in the configure script to gather git's path. This is
necessary to prevent "sudo make install" from failing since git may not be
in the path in make's shell environment.
(closes issue ASTERISK-20483)
Reported by: Shaun Ruffell
Patches:
0001-build_tools-Allow-Asterisk-to-report-git-SHAs-in-ver.patch (license #5417) patch uploaded by Shaun Ruffell
Modified
........
Merged revisions 375189 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When placing a call to a TCP/TLS SIP endpoint whose certificate is not
signed by a configured CA certificate, Asterisk would issue a warning
and continue to process the call as if there was not an issue with the
certificate. Asterisk now properly fails the call if the certificate
fails verification or if the certificate does not exist when
certificate checking is enabled (the default behavior).
(closes issue ASTERISK-20559)
Reported by: kmoore
Review: https://reviewboard.asterisk.org/r/2163/
........
Merged revisions 375146 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375147 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Passing an ast_str pointer by value that then calls
ast_str_set(), ast_str_set_va(), ast_str_append(), or
ast_str_append_va() can result in the pointer originally
passed by value being invalidated if the ast_str had
to be reallocated.
This fixes places in the code that do this. Only the
example in ccss.c could result in pointer invalidation
though since the other cases use a stack-allocated ast_str
and cannot be reallocated.
I've also updated the doxygen in strings.h to include
notes about potential misuse of the functions mentioned
previously.
Review: https://reviewboard.asterisk.org/r/2161
........
Merged revisions 375025 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@375026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update config.guess and config.sub to revision
fb456b34ef4aa02b95dc6be69aaa66fa94a844fb from the savannah.gnu.org git
repo. Adds support for e.g. aarch64 (ARM 64bit).
config.guess:timestamp='2012-09-25'
config.sub:timestamp='2012-10-10'
........
Merged revisions 374977 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is used to solve an issue where a poll on a file
descriptor does not necessarily correspond to the readiness
of a FILE handle to be read.
This change makes it so that for TCP connections, we do a
recv() on the file descriptor instead.
Because TCP does not guarantee that an entire message or even
just one single message will arrive during a read, a loop has
been introduced to ensure that we only attempt to handle a
single message at a time. The tcptls_session_instance structure
has also had an overflow buffer added to it so that if more
than one TCP message arrives in one go, there is a place to
throw the excess.
Huge thanks goes out to Walter Doekes for doing extensive review
on this change and finding edge cases where code could fail.
(closes issue ASTERISK-20212)
reported by Phil Ciccone
Review: https://reviewboard.asterisk.org/r/2123
........
Merged revisions 374905 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Similar to r369351, the billing duration can be skewed when batch mode is
enabled. This happened much more rarely than the duration, as it only
occured when the call was answered (thereby indicating an actual answer
time) and immediately hung up on (indicating a billsec of 0). Since
a billing time of '0' can either mean that the call immediately ended
or that the CDR was improperly answered, we have to use additional information
to know whether or not we can trust the CDR billsec value. Prior to this
patch, we looked to see if we had a valid answer time. If we did, and
billsec was zero, we used the current time to calculate what billsec value
we could from the CDR being written. If batch mode is enabled, this will
incorrectly report a billsec value being much greater than the actual
duration of the call.
Instead of relying on the presence of an answer time to know whether or not
we can re-calculate the billsec for the CDR, we now also use the presence
of the CDR's end time to know if we need to re-calculate or whether we can
trust the billsec value that we have. This prevents erroneous jumps in the
billsec value, while still making sure that in the worst case, some billing
time will be calculated.
(closes issue AST-1016)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
........
Merged revisions 374843 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374844 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Party A calls Party B
Party B puts Party A on hold.
Party B calls a queue.
Ringing queue member D sees Party B identification.
Party B transfers Party A to the queue.
Queue member D does not get a connected line update for Party A.
Queue member D answers the call and still sees Party B information.
However, if Party A later transfers the call to Party C then queue member
D gets a connected line update for Party C.
* Made pass connected line updates from the caller to queue members while
the queue members are ringing.
(closes issue AST-1017)
Reported by: Thomas Arimont
(closes issue ABE-2886)
Reported by: Thomas Arimont
Tested by: rmudgett
........
Merged revisions 374801 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
........
Merged revisions 374802 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The fix for ASTERISK-18243 added code that could potentially use
dst_exten[] uninitialized. As a result the 'i' exten may not be executed
when it should.
(closes issue ASTERISK-20455)
Reported by: Richard Miller
Patches:
pbx-1.8.16.0.diff (license #5685) patch uploaded by Richard Miller
Made some cosmetic modifications.
........
Merged revisions 374758 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This contains an edited version of the patch originally created by John
Bigelow.
(closes issue ASTERISK-14435)
Reported by: John Bigelow
Patches:
buffers.patch (license #5091) patch uploaded by John Bigelow
0001-dahdi.conf.sample-Add-description-for-buffers-settin.patch (license #5417) patch uploaded by Shaun Ruffell
Modified
........
Merged revisions 374727 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374728 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If scan_service() cannot open the spool file, it logs a message saying
that it will delete the file and calls remove_from_queue() to do it.
However, remove_from_queue() fails to delete the spool file because struct
outgoing has not yet been fully initialized.
* Merged allocating a new struct outgoing and init_outgoing() into
new_outgoing(). Allocation is initialization.
* Made apply_outgoing() not initialize the spool filename in struct
outgoing.
* Made apply_outgoing() call ast_trim_blanks() and ast_skip_blanks()
rather than manually inlining them.
* Reduced indentation levels in apply_outgoing().
* Fixed a garbled comment in remove_from_queue().
* Reworked scan_service() to simplify it.
(closes issue ASTERISK-17231)
Reported by: David Chappell
Patches:
spool_open_failure.diff (license #4997) patch uploaded by David Chappell
Started with this patch.
........
Merged revisions 374686 from http://svn.asterisk.org/svn/asterisk/branches/1.8
* Fixed some memory leaks on off nominal paths in init_outgoing() when
merging into the new_outgoing() function dealing with o->capabilities.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374695 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Thank's to Neil Tallim (flan)'s tireless testing, issue reporting, and patches
it became clear that app_confbridge had some complex logic in how it handled
interactions between marked, waitmarked, and unmarked users. In particular,
there were some areas in which the interactions between the users resulted
in inconsistent behavior, and app_confbridge was missing logic in how to handle
some corner cases. Some areas included:
* Poor handling of mixing unmarked and waitmarked users
* Inconsistencies in how MOH and muting was applied to various users
* Handling of various announcements for different user profile options
flan's patches seem to fix the various issues, but highlighted how hard the
code could be to maintain. In an attempt to make things easier to maintain and
to more fully enumerate the various cases that exist, this patch breaks up the
logic into a state machine-like setup.
Please note that the various state transitioned are documented on the Asterisk
wiki:
https://wiki.asterisk.org/wiki/display/AST/Confbridge+state+changes
Review: //https://reviewboard.asterisk.org/r/2072/
Note that for the following issues, mjordan uploaded the patch, although it
was written by twilson. Any contributor license discrepency is due to that.
(closes issue ASTERISK-19562)
Reported by: flan
Tested by: flan, mjordan, jrose
patches:
bugASTERISK-19562_ASTERISK-19726_ASTERISK-20181.patch uploaded by twilson (license 6283)
(closes issue ASTERISK-19726)
Reported by: flan
Tested by: flan
patches:
bugASTERISK-19562_ASTERISK-19726_ASTERISK-20181.patch uploaded by twilson (license 6283)
(closes issue ASTERISK-20181)
Reported by: Jonathan White
Tested by: Jonathan White
patches:
bugASTERISK-19562_ASTERISK-19726_ASTERISK-20181.patch uploaded by twilson (license 6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r374570 | dlee | 2012-10-05 15:14:41 -0500 (Fri, 05 Oct 2012) | 22 lines
Improve AMI long line error handling
In AMI's parser, when it receives a long line (> 1024 characters), it discards
that line, but continues to process the message normally.
Typically, this is not a problem because a) who has lines that long and b)
usually a discarded line results in an invalid message. But if that line is
specifying an optional field, then the message will be processed, you get a
'Response: Success', but things don't work the way you expected them to.
This patch changes the behavior when a line-too-long parse error occurs.
* Changes the log message to avoid way-too-long (and truncated anyways) log
messages
* Adds a 'parsing' status flag to Response: Success
* Sets parsing = MESSAGE_LINE_TOO_LONG if, well, a line is too long
* Responds with an appropriate error if parsing != MESSAGE_OKAY
(closes issue AST-961)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2142/
........
r374581 | dlee | 2012-10-05 15:20:28 -0500 (Fri, 05 Oct 2012) | 1 line
I've committed too much. Reverting part of r374570.
........
Merged revisions 374570,374581 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
................
r374515 | rmudgett | 2012-10-04 17:52:36 -0500 (Thu, 04 Oct 2012) | 10 lines
chan_misdn: Remove some deadcode
* Made setup_bc() static.
Patches:
patch1_unused-code.diff (license #6372) patch uploaded by Guenther Kelleter
Modified
JIRA ABE-2882
................
r374516 | rmudgett | 2012-10-04 18:01:01 -0500 (Thu, 04 Oct 2012) | 7 lines
chan_misdn: Remove unused bchan states
Patches:
patch2_unused-states.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374517 | rmudgett | 2012-10-04 18:17:51 -0500 (Thu, 04 Oct 2012) | 16 lines
chan_misdn: Remove unnecessary null pointer checks and checks for stack->nt
* cleanup_bc() is always called with valid bc (or it would've crashed
before).
* Value of stack->nt is known in advance at some places.
* Rename handle_event() to handle_event_te(), handle_frm() to
handle_frm_te().
Patches:
patch3_checks.diff (license #6372) patch uploaded by Guenther Kelleter
Modified
JIRA ABE-2882
................
r374518 | rmudgett | 2012-10-04 18:21:59 -0500 (Thu, 04 Oct 2012) | 7 lines
chan_misdn: Fix spelling in log messages
Patches:
patch4_spelling.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374519 | rmudgett | 2012-10-04 18:31:59 -0500 (Thu, 04 Oct 2012) | 15 lines
chan_misdn: Don't cleanup a bc twice.
In handle_frm_te() after calling misdn_lib_send_event(bc,
EVENT_RELEASE_COMPLETE) bc is emptied, cleaned and set not in use,
although misdn_lib_send_event() already did the same. This is bad. When
it's not in use we are not allowed to touch it.
* Moved log message in front of the resulting actions and fixed it to
match the case.
Patches:
patch5_bccleanup.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374520 | rmudgett | 2012-10-04 18:43:56 -0500 (Thu, 04 Oct 2012) | 12 lines
chan_misdn: Fix memory leaks, bc, chan not cleaned up etc., really bad stuff.
* Fix return codes of cb_events() for EVENT_SETUP to use caller's cleanup
mechanisms.
* Move cl_queue_chan() call after bearer check.
Patches:
patch6_leaks.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374521 | rmudgett | 2012-10-04 18:48:38 -0500 (Thu, 04 Oct 2012) | 11 lines
chan_misdn: We must initialize cause on sending a DISCONNECT.
We must initialize cause on sending a DISCONNECT, so it is later correctly
indicated to ast_channel in case the answer (RELEASE/RELEASE_COMPLETE)
does not include one.
Patches:
patch7_hangupcause.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374522 | rmudgett | 2012-10-04 19:03:56 -0500 (Thu, 04 Oct 2012) | 7 lines
chan_misdn: Remove unused code for upqueue
Patches:
patch8_unused-upqueue.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374523 | rmudgett | 2012-10-04 19:11:50 -0500 (Thu, 04 Oct 2012) | 7 lines
chan_misdn: Improve debugging (port number, messages fixed, dups removed)
Patches:
patch9_debug.diff (license #6372) patch uploaded by Guenther Kelleter
JIRA ABE-2882
................
r374533 | rmudgett | 2012-10-05 12:17:18 -0500 (Fri, 05 Oct 2012) | 8 lines
chan_misdn: Better debug: we can print_bc_info even if there's no ast leg.
Patches:
patch10_debug-bc-2.diff (license #6372) patch uploaded by Guenther Kelleter
Modified.
JIRA ABE-2882
................
r374534 | rmudgett | 2012-10-05 12:34:10 -0500 (Fri, 05 Oct 2012) | 16 lines
chan_misdn: setup_bc() is called too early for an incoming SETUP on TE.
This prevents the B channel from being setup for HDLC mode when requested
by the bearer capability and config option hdlc=yes. It violates
ETS300102 Ch.5.2.3.2: "The user, in any case, must not connect to the
channel until a CONNECT ACKNOWLEDGE message has been received."
* Call setup_bc() on receipt of CONNECT_ACKNOWLEGDE for PTMP, and on first
response to SETUP for PTP.
Patches:
abe-2881-2.diff (license #6372) patch uploaded by Guenther Kelleter
Modified.
JIRA ABE-2881
................
r374535 | rmudgett | 2012-10-05 12:41:05 -0500 (Fri, 05 Oct 2012) | 2 lines
chan_misdn: Remove some more deadcode.
................
........
Merged revisions 374536 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/10@374537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk Autobuilder
Matthew Jordan
Richard Mudgett
Jonathan Rose
Andrew Latham
Michael L. Young
Mark Michelson
Kinsey Moore
Walter Doekes
Tzafrir Cohen
David M. Lee