https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r233092 | russell | 2009-12-04 11:12:47 -0600 (Fri, 04 Dec 2009) | 7 lines
Only do frame payload check for HOLD frames.
This code was added for helping to debug the source of invalid HOLD frames.
However, a side effect of this is that it will incorrectly report errors for
frames that have an integer payload. Make the check for this block specific
to the HOLD frame case.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@233100 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r231911 | jpeeler | 2009-12-01 15:29:31 -0600 (Tue, 01 Dec 2009) | 12 lines
Fix crash with invalid frame data
The crash was happening as a result of a frame containing an invalid data
pointer, but was set with data length of zero. The few times the issue was
reproduced it _seemed_ that the frame was queued properly, that is the data
pointer was set to NULL. I never could reproduce the crash so as a last resort
the crash has been fixed, but a check in __ast_read has been added to give as
much information about the source of problematic frames in the future.
(closes issue #16058)
Reported by: atis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231927 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Telecom Specs in NZ suggests that SUB ADDRESS is always on, so doing
"desk to desk" between offices each with an asterisk box over the ISDN
should then be possible, without a whole load of DDI numbers required.
(closes issue #15604)
Reported by: alecdavis
Patches:
asterisk_subaddr_trunk.diff11.txt uploaded by alecdavis (license 585)
Some minor modificatons were made.
Tested by: alecdavis, rmudgett
Review: https://reviewboard.asterisk.org/r/405/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch finishes the implementation of OBJ_MULTIPLE in astobj2 (the
case where multiple results need to be returned; OBJ_NODATA mode
already was supported). In addition, it converts ast_channel_iterators
(only the targeted versions, not the ones that iterate over all
channels) to use this method.
During this work, I removed the 'ao2_flags' arguments to the
ast_channel_iterator constructor functions; there were no uses of that
argument yet, there is only one possible flag to pass, and it made the
iterators less 'opaque'. If at some point in the future someone really
needs an ast_channel_iterator that does not lock the container, we can
provide constructor(s) for that purpose.
Review: https://reviewboard.asterisk.org/r/379/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channels are stored in an ao2_container. When accessing an item within
an ao2_container the proper locking order is to first lock the container,
and then the items within it.
In ast_do_masquerade both the clone and original channel must be locked
for the entire duration of the function. The problem with this is that
it attemptes to unlink and link these channels back into the ao2_container
when one of the channel's name changes. This is invalid locking order as
the process of unlinking and linking will lock the ao2_container while
the channels are locked!!! Now, both the channels in do_masquerade are
unlinked from the ao2_container and then locked for the entire function.
At the end of the function both channels are unlocked and linked back
into the container with their new names as hash values.
This new method of requiring all channels and tech pvts to be unlocked
before ast_do_masquerade() or ast_change_name() required several
changes throughout the code base.
(closes issue #15911)
Reported by: russell
Patches:
masq_deadlock_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel, atis
(closes issue #15618)
Reported by: lmsteffan
Patches:
deadlock_local_attended_transfers_trunk.diff uploaded by dvossel (license 671)
Tested by: lmsteffan, dvossel
Review: https://reviewboard.asterisk.org/r/387/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_channel_get_full() tries to use OBJ_POINTER to optimize name-based
channel lookups, but this will not work properly when the channel's full
name was not supplied; for name-prefix searches, there is no value in
doing a hash-based lookup, and in fact doing so could result in many
channels being skipped.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220494 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h.
(closes issue #15316)
Reported by: vmarrone
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/362/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214701 | tilghman | 2009-08-28 15:13:32 -0500 (Fri, 28 Aug 2009) | 8 lines
Modify comment to be a bit more accurate.
We have kept this comment around long enough, that it's pretty clear that we're
keeping the code, because changing the code would require a pretty fundamental
architectural shift. We've also taken criticism in some quarters, because it
was believed that it was referring to the code being nasty. No, the code isn't
nasty, just the operation itself is rather odd. Fixed for eternity (probably
not).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r214194 | dvossel | 2009-08-26 11:36:42 -0500 (Wed, 26 Aug 2009) | 19 lines
ast_write() ignores ast_audiohook_write() results
In ast_write(), if a channel has a list of audiohooks, those
lists are written to and the resulting frame is what ast_write()
should continue with. The problem was the returned audiohook frame
was not being handled at all, and the original frame passed
into it did not contain the mixed audio, so essentially audio
was being lost. One result of this was chan_spy's whisper
mode no longer worked. To complicate the issue, frames
passed into ast_write may either be a single frame, or a list
of frames. So, as the list of frames is processed in the
audiohook_write, the returned frames had to be added to a new
list.
(closes issue #15660)
Reported by: corruptor
Tested by: dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214195 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Even though the get_channel_by_name() API advertised that you could search by
name or uniqueid (just as the old API did), searching by uniqueid was not
actually implemented. This patch fixes that problem.
The ast_channel_get_full() function now makes a second search attempt by
uniqueid if the parameter was a name. The channel comparison function also
now knows how to compare by unqieueid.
Finally, a bug was fixed in passing where OBJ_POINTER was being passed in some
scenarios where it should not have been.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@211390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r210913 | tilghman | 2009-08-06 16:45:01 -0500 (Thu, 06 Aug 2009) | 7 lines
Because channel information can be accessed outside of the channel thread, we must lock the channel prior to modifying it.
(closes issue #15397)
Reported by: caspy
Patches:
20090714__issue15397.diff.txt uploaded by tilghman (license 14)
Tested by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207360 | russell | 2009-07-20 11:26:24 -0500 (Mon, 20 Jul 2009) | 9 lines
Only do the chan->fdno check in ast_read() in a developer build.
I changed this check to only happen in a dev-mode build. I also added a
comment explaining what is going on. I also made it so that detection of
this situation does not affect ast_read() operation.
(closes issue #14723)
Reported by: seadweller
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@207361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows applications that request T.38 negotiation on a channel that
does not support it to get the proper indication that it is not supported, rather
than thinking that negotiation was started when it was not.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r201450 | mmichelson | 2009-06-17 14:59:31 -0500 (Wed, 17 Jun 2009) | 9 lines
Change the datastore traversal in ast_do_masquerade to use a safe list traversal.
It is possible for datastore fixup functions to remove the datastore from the list
and free it. In particular, the queue_transfer_fixup in app_queue does this. While
I don't yet know of this causing any crashes, it certainly could.
Found while discussing a separate issue with Brian Degenhardt.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r200991 | kpfleming | 2009-06-16 12:05:38 -0500 (Tue, 16 Jun 2009) | 11 lines
Improve support for media paths that can generate multiple frames at once.
There are various media paths in Asterisk (codec translators and UDPTL, primarily)
that can generate more than one frame to be generated when the application calling
them expects only a single frame. This patch addresses a number of those cases,
at least the primary ones to solve the known problems. In addition it removes the
broken TRACE_FRAMES support, fixes a number of bugs in various frame-related API
functions, and cleans up various code paths affected by these changes.
https://reviewboard.asterisk.org/r/175/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201056 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When allocating the channel use ao2_ref(-1) to release it, instead of calling
ast_free().
Also avoid freeing structures inside that channel (on error) if they will be
released by the channel destructor being called if the reference counter reachs
0.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@200108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also I removed an unnecessary free of a cid_name. This will be freed properly
in the channel destructor.
Reported by mnicholson in #asterisk-dev.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@199923 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The function ast_call_forward() forwards a call to an extension specified in an ast_channel's call_forward string. After an ast_channel is called, if the channel's call_forward string is set this function can be used to forward the call to a new channel and terminate the original one. I have included this api call in both channel.c's ast_request_and_dial() and feature.c's feature_request_and_dial(). App_dial and app_queue already contain call forward logic specific for their application and options.
(closes issue #13630)
Reported by: festr
Review: https://reviewboard.asterisk.org/r/271/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198856 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When connected line updates are received or generated in the middle
of an application call, it is now possible to execute a macro to
manipulate the connected line data. This way, phone numbers may be
manipulated to be more presentable to users, names may be changed
for...whatever reason, or whatever else needs to be done may be.
Review: https://reviewboard.asterisk.org/r/256
AST-165
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r198068 | mnicholson | 2009-05-29 13:53:01 -0500 (Fri, 29 May 2009) | 15 lines
Use AST_CDR_NOANSWER instead of AST_CDR_NULL as the default CDR disposition.
This change also involves the addition of an AST_CDR_FLAG_ORIGINATED flag that is used on originated channels to distinguish: them from dialed channels.
(closes issue #12946)
Reported by: meral
Patches:
null-cdr2.diff uploaded by mnicholson (license 96)
Tested by: mnicholson, dbrooks
(closes issue #15122)
Reported by: sum
Tested by: sum
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds 'const' tags to a number of Asterisk APIs where they are appropriate (where the API already demanded that the function argument not be modified, but the compiler was not informed of that fact). The list includes:
- CLI command handlers
- CLI command handler arguments
- AGI command handlers
- AGI command handler arguments
- Dialplan application handler arguments
- Speech engine API function arguments
In addition, various file-scope and function-scope constant arrays got 'const' and/or 'static' qualifiers where they were missing.
Review: https://reviewboard.asterisk.org/r/251/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@196072 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As in previous commits, when channels are allocated (with ast_channel_alloc) or datastores are allocated (with ast_datastore_alloc) properly account for the memory being owned by the caller, instead of the allocator function itself.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@192318 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r191488 | jpeeler | 2009-05-01 12:40:46 -0500 (Fri, 01 May 2009) | 9 lines
Fix DTMF not being sent to other side after a partial feature match
This fixes a regression from commit 176701. The issue was that
ast_generic_bridge never exited after the feature digit timeout had elapsed,
which prevented the queued DTMF from being sent to the other side.
This issue was reported to me directly.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@191489 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There is a lot that could be said about this, but the patch is a big
improvement for performance, stability, code maintainability,
and ease of future code development.
The channel list is no longer an unsorted linked list. The main container
for channels is an astobj2 hash table. All of the code related to searching
for channels or iterating active channels has been rewritten. Let n be
the number of active channels. Iterating the channel list has gone from
O(n^2) to O(n). Searching for a channel by name went from O(n) to O(1).
Searching for a channel by extension is still O(n), but uses a new method
for doing so, which is more efficient.
The ast_channel object is now a reference counted object. The benefits
here are plentiful. Some benefits directly related to issues in the
previous code include:
1) When threads other than the channel thread owning a channel wanted
access to a channel, it had to hold the lock on it to ensure that it didn't
go away. This is no longer a requirement. Holding a reference is
sufficient.
2) There are places that now require less dealing with channel locks.
3) There are places where channel locks are held for much shorter periods
of time.
4) There are places where dealing with more than one channel at a time becomes
_MUCH_ easier. ChanSpy is a great example of this. Writing code in the
future that deals with multiple channels will be much easier.
Some additional information regarding channel locking and reference count
handling can be found in channel.h, where a new section has been added that
discusses some of the rules associated with it.
Mark Michelson also assisted with the development of this patch. He did the
conversion of ChanSpy and introduced a new API, ast_autochan, which makes it
much easier to deal with holding on to a channel pointer for an extended period
of time and having it get automatically updated if the channel gets masqueraded.
Mark was also a huge help in the code review process.
Thanks to David Vossel for his assistance with this branch, as well. David
did the conversion of the DAHDIScan application by making it become a wrapper
for ChanSpy internally.
The changes come from the svn/asterisk/team/russell/ast_channel_ao2 branch.
Review: http://reviewboard.digium.com/r/203/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@190423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r189277 | mmichelson | 2009-04-20 09:04:41 -0500 (Mon, 20 Apr 2009) | 12 lines
Move the check for chan->fdno == -1 to after the zombie/hangup check.
Many users were finding that their hung up channels were staying up and
causing 100% CPU usage.
(issue #14723)
Reported by: seadweller
Patches:
14723_1-4-tip.patch uploaded by mmichelson (license 60)
Tested by: falves11, bamby
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@189278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was accomplished using a set of options and the setoption channel callback.
The core calls into the channel driver using these options and the channel driver
either returns success or failure.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@187360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Jeff Peeler
Tilghman Lesher
Leif Madsen
David Vossel
Richard Mudgett
Kevin P. Fleming
Matthew Nicholson
Mark Michelson
Joshua Colp
Eliel C. Sardanons