https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294905 | jpeeler | 2010-11-12 14:52:06 -0600 (Fri, 12 Nov 2010) | 30 lines
Merged revisions 294904 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r294904 | jpeeler | 2010-11-12 14:51:15 -0600 (Fri, 12 Nov 2010) | 23 lines
Merged revisions 294903 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r294903 | jpeeler | 2010-11-12 14:49:09 -0600 (Fri, 12 Nov 2010) | 16 lines
Fix regression causing abort in voicemail after opening a mailbox with no mesgs.
In order to be more safe, some error handling code was changed to respect more
error conditions including the potential memory allocation failure for deleted
and heard message tracking introduced in 293004. However, last_message_index
returns -1 for zero messages (perhaps as expected) and was triggering the
stricter error checking. Because last_message_index is only called directly
in one place, just return 0 from open_mailbox (for file based storage) when no
messages are detected unless a real error has occurred.
(closes issue #18240)
Reported by: leobrown
Patches:
bug18240.1-6-2.diff.txt uploaded by alecdavis (license 585)
Tested by: pabelanger
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294823 | rmudgett | 2010-11-11 20:45:22 -0600 (Thu, 11 Nov 2010) | 25 lines
Merged revisions 294822 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r294822 | rmudgett | 2010-11-11 20:44:12 -0600 (Thu, 11 Nov 2010) | 18 lines
Merged revisions 294821 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r294821 | rmudgett | 2010-11-11 20:41:13 -0600 (Thu, 11 Nov 2010) | 11 lines
Asterisk is getting a "No D-channels available!" warning message every 4 seconds.
Asterisk is just whining too much with this message: "No D-channels
available! Using Primary channel XXX as D-channel anyway!".
Filtered the message so it only comes out once if there is no D channel
available without an intervening D channel available period.
(closes issue #17270)
Reported by: jmls
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r294740 | russell | 2010-11-11 16:13:38 -0600 (Thu, 11 Nov 2010) | 11 lines
Remove most of the contents of the doc dir in favor of the wiki content.
This merge does the following things:
* Removes most of the contents from the doc/ directory in favor
of the wiki - http://wiki.asterisk.org/
* Updates the build_tools/prep_tarball script to know how to export
the contents of the wiki in both PDF and plain text formats so that
the documentation is still included in Asterisk release tarballs.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294741 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294734 | jpeeler | 2010-11-11 15:58:25 -0600 (Thu, 11 Nov 2010) | 32 lines
Merged revisions 294733 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r294733 | jpeeler | 2010-11-11 15:57:22 -0600 (Thu, 11 Nov 2010) | 25 lines
Merged revisions 294688 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r294688 | jpeeler | 2010-11-11 15:12:27 -0600 (Thu, 11 Nov 2010) | 18 lines
Fix problem with qualify option packets for realtime peers never stopping.
The option packets not only never stopped, but if a realtime peer was not in
the peer list multiple options dialogs could accumulate over time. This
scenario has the potential to progress to the point of saturating a link just
from options packets. The fix was to ensure that the poke scheduler checks to
see if a peer is in the peer list before continuing to poke. The reason a peer
must be in the peer list to be able to properly manage an options dialog is
because otherwise the call pointer is lost when the peer is regenerated from
the database, which is how existing qualify dialogs are detected.
(closes issue #16382)
(closes issue #17779)
Reported by: lftsy
Patches:
bug16382-3.patch uploaded by jpeeler (license 325)
Tested by: zerohalo
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r294349 | rmudgett | 2010-11-09 10:55:32 -0600 (Tue, 09 Nov 2010) | 17 lines
Analog lines do not transfer CONNECTED LINE or execute the interception macros.
Add connected line update for sig_analog transfers and simplify the
corresponding sig_pri and chan_misdn transfer code.
Note that if you create a three-way call in sig_analog before transferring
the call, the distinction of the caller/callee interception macros make
little sense. The interception macro writer needs to be prepared for
either caller/callee macro to be executed. The current implementation
swaps which caller/callee interception macro is executed after a three-way
call is created.
Review: https://reviewboard.asterisk.org/r/996/
JIRA ABE-2589
JIRA SWP-2372
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294278 | jpeeler | 2010-11-08 15:59:45 -0600 (Mon, 08 Nov 2010) | 23 lines
Merged revisions 294277 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r294277 | jpeeler | 2010-11-08 15:58:13 -0600 (Mon, 08 Nov 2010) | 16 lines
Fix playback failure when using IAX with the timerfd module.
To fix this issue the alert pipe will now be used when the timerfd module is
in use. There appeared to be a race that was not solved by adding locking in the
timerfd module, but needed to be there anyway. The race was between the timer
being put in non-continuous mode in ast_read on the channel thread and the IAX
frame scheduler queuing a frame which would enable continuous mode before the
non-continuous mode event was read. This race for now is simply avoided.
(closes issue #18110)
Reported by: tpanton
Tested by: tpanton
I put tested by tpanton because it was tested on his hardware. Thanks for the
remote access to debug this issue!
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r294125 | rmudgett | 2010-11-08 11:16:01 -0600 (Mon, 08 Nov 2010) | 33 lines
valgrind reported references to freed memory during a mISDN hangup collision.
Bad things have been happening in chan_misdn because the chan_misdn
channel private struct chan_list is not protected from reentrancy. Hangup
collisions have be causing read and write accesses to freed memory.
Converted chan_misdn struct chan_list to an ao2 object for its reference
counting feature.
**********
Removed an impediment to converting chan_list to an ao2 object.
The use of the other_ch member in chan_list is shaky at best. It is set
if the incoming and outgoing call legs are mISDN. The use of the other_ch
member goes against the Asterisk architecture and can even cause problems.
1) It is used to disable echo cancellation. This could be bad if the call
is forked and the winning call leg is not mISDN or the winning call leg is
not the last mISDN channel called by the fork. The other_ch would become
a dangling pointer.
2) It is used when the far end is alerting to hear the far end's inband
audio instead of Asterisk's generated ringback tone. This is bad if the
call is forked. You would only hear the last forked mISDN channel and it
may not be ringing yet.
The other_ch would become a dangling pointer if the call is later
transferred.
**********
JIRA SWP-2423
JIRA ABE-2614
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294127 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC3261 section 12 about dialog creation says an INVITE transaction
results in an established dialog once it receives the 200 OK response.
It is possible to receive multiple differing 200 OK responses for a
single outbound INVITE Request, and this should result in establishing
multiple dialogs.
This patch allows for all differing 200 OK responses to an INVITE request
to establish a separate dialog, but only the first dialog is kept. All other
resulting dialogs from the initial request are immediately ACKed and then
immediately terminated with a BYE request.
Review: https://reviewboard.asterisk.org/r/946/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294083 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r293970 | sruffell | 2010-11-04 19:07:11 -0500 (Thu, 04 Nov 2010) | 32 lines
Merged revisions 293969 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r293969 | sruffell | 2010-11-04 19:06:02 -0500 (Thu, 04 Nov 2010) | 25 lines
Merged revisions 293968 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r293968 | sruffell | 2010-11-04 19:02:53 -0500 (Thu, 04 Nov 2010) | 17 lines
codecs/codec_dahdi: Prevent "choppy" audio when receiving unexpected frame sizes.
dahdi-linux 2.4.0 (specifically commit 9034) added the capability for
the wctc4xxp to return more than a single packet of data in response to
a read. However, when decoding packets, codec_dahdi was still assuming
that the default number of samples was in each read.
In other words, each packet your provider sent you, regardless of size,
would result in 20 ms of decoded data (30 ms if decoding G723). If your
provider was sending 60 ms packets then codec_dahdi would end up
stripping 40 ms of data from each transcoded frame resulting in "choppy"
audio.
This would only affect systems where G729 packets are arriving in sizes
greater than 20ms or G723 packets arriving in sizes greater than 30ms.
DAHDI-744.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293971 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293803 | twilson | 2010-11-03 11:05:14 -0700 (Wed, 03 Nov 2010) | 25 lines
Avoid valgrind warnings for ast_rtp_instance_get_xxx_address
The documentation for ast_rtp_instance_get_(local/remote)_address stated that
they returned 0 for success and -1 on failure. Instead, they returned 0 if the
address structure passed in was already equivalent to the address instance
local/remote address or 1 otherwise. 90% of the calls to these functions
completely ignored the return address and passed in an uninitialized struct,
which would make valgrind complain even though the operation was technically
safe.
This patch fixes the documentation and converts the get_xxx_address functions
to void since all they really do is copy the address and cannot fail.
Additionally two new functions
(ast_rtp_instance_get_and_cmp_(local/remote)_address) are created for the 3
times where the return value was actually checked. The
get_and_cmp_local_address function is currently unused, but exists for the sake
of symmetry.
The only functional change as a result of this change is that we will not do an
ast_sockaddr_cmp() on (mostly uninitialized) addresses before doing the
ast_sockaddr_copy() in the get_*_address functions. So, even though it is an
API change, it shouldn't have a noticeable change in behavior.
Review: https://reviewboard.asterisk.org/r/995/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r293807 | rmudgett | 2010-11-03 13:35:19 -0500 (Wed, 03 Nov 2010) | 34 lines
Merged revisions 293806 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r293806 | rmudgett | 2010-11-03 13:31:57 -0500 (Wed, 03 Nov 2010) | 27 lines
Merged revisions 293805 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r293805 | rmudgett | 2010-11-03 13:23:04 -0500 (Wed, 03 Nov 2010) | 20 lines
Party A in an analog 3-way call would continue to hear ringback after party C answers.
All parties are analog FXS ports.
1) A calls B.
2) A flash hooks to call C.
3) A flash hooks to bring C into 3-way call before C answers. (A and B hear ringback)
4) C answers
5) A continues to hear ringback during the 3-way call. (All parties can hear each other.)
* Fixed use of wrong variable in dahdi_bridge() that stopped ringback on
the wrong subchannel.
* Made several debug messages have more information.
A similar issue happens if B and C are SIP channels. B continues to hear
ringback. For some reason this only affects v1.8 and trunk.
* Don't start ringback on the real and 3-way subchannels when creating the
3-way conference. Removing this code is benign on v1.6.2 and earlier.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r293648 | rmudgett | 2010-11-02 16:29:25 -0500 (Tue, 02 Nov 2010) | 20 lines
Merged revisions 293647 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r293647 | rmudgett | 2010-11-02 16:26:30 -0500 (Tue, 02 Nov 2010) | 13 lines
Merged revisions 293639 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r293639 | rmudgett | 2010-11-02 16:24:13 -0500 (Tue, 02 Nov 2010) | 6 lines
Make warning message have more useful information in it.
Change "Unable to get index, and nullok is not asserted" to "Unable to get
index for '<channel-name>' on channel <number> (<function>(), line
<number>)".
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293530 | rmudgett | 2010-11-01 12:29:30 -0500 (Mon, 01 Nov 2010) | 10 lines
Analog 3-way call would not connect all parties if one was using sig_pri.
Also the "dahdi show channel" would not show the correct 3-way call
status.
* Synchronized the inthreeway flag between chan_dahdi and sig_analog.
* Fixed a my_set_linear_mode() sign error and made take an analog sub
channel enum.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293531 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293305 | jpeeler | 2010-10-29 16:48:38 -0500 (Fri, 29 Oct 2010) | 9 lines
Modify sip_setoption to not complain about unknown options.
This now behaves just like the other setoption callbacks. For the curious the
offending option for the reporter was AST_OPTION_CHANNEL_WRITE which was getting
passed due to a fix for chan_local in 286189.
(closes issue #17985)
Reported by: globalnetinc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r293119 | jpeeler | 2010-10-26 13:49:08 -0500 (Tue, 26 Oct 2010) | 43 lines
Merged revisions 293118 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r293118 | jpeeler | 2010-10-26 13:33:24 -0500 (Tue, 26 Oct 2010) | 36 lines
Merged revisions 293004 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r293004 | jpeeler | 2010-10-25 17:55:28 -0500 (Mon, 25 Oct 2010) | 29 lines
Fix inprocess_container in voicemail to correctly restrict max messages.
The comparison function logic was off, so the number of sessions for a given
mailbox were not being incremented properly. This problem caused the maximum
number of messages per folder to not be respected when simultaneously leaving
multiple voicemails just below the threshold.
These problems should be fixed by the above, but just in case:
Fixed resequence_mailbox to rely on the actual number of detected number of
files in a directory rather than just assuming only 10 messages more than the
maximum had been left. Also if more messages than the maximum are deleted they
are actually removed now.
The second purpose of this commit should have been separated out probably, but
is related to the above. Again, if the number of messages in a given voicemail
folder exceeds the maximum set limit make sure to allocate enough space for the
deleted and heard index tracking array.
A few random fixes:
There was a forgotten decrement of the inprocess count in imap_store_file.
When using IMAP storage, do not look in the directory where file based storage
messages may still reside and influence the message count.
Ensure to use only the first format in sendmail.
ABE-2516
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r292868 | dvossel | 2010-10-25 14:07:50 -0500 (Mon, 25 Oct 2010) | 39 lines
Merged revisions 292867 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r292867 | dvossel | 2010-10-25 14:06:21 -0500 (Mon, 25 Oct 2010) | 32 lines
Merged revisions 292866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r292866 | dvossel | 2010-10-25 14:05:07 -0500 (Mon, 25 Oct 2010) | 27 lines
This patch turns chan_local pvts into astobj2 objects.
chan_local does some dangerous things involving deadlock avoidance.
tech_pvt functions like hangup and queue_frame are provided with a
locked channel upon entry. Those functions are completely safe as
long as you don't attempt to give up that channel lock, but that is
impossible to guarantee due to the required deadlock avoidance necessary
to lock both the tech_pvt and both channels involved.
In the past, we have tried to account for this by doing things like
setting a "glare" flag that indicates what function should destroy the
pvt. This was used in local_hangup and local_queue_frame to decided
who should destroy the pvt if they collided in separate threads. I
have removed the need to do this by converting all chan_local tech_pvts
to astobj2. This means we can ref a pvt before deadlock avoidance
and not have to worry about that pvt possibly getting destroyed under
us. It also cleans up where we destroy the tech_pvt. The only unlink
from the tech_pvt container occurs in local_hangup now, which is where
it should occur.
Since there still may be thread collisions on some functions like
local_hangup after deadlock avoidance, I have added some checks to detect
those collisions and exit appropriately. I think this patch is going to
solve quite a bit of weirdness we have had with local channels in the past.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Tilghman Lesher
Jeff Peeler
Richard Mudgett
Matthew Nicholson
Terry Wilson
Brett Bryant
David Vossel
Shaun Ruffell
Paul Belanger
Mark Michelson