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/branches/1.8@294740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@294734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r294639 | jpeeler | 2010-11-11 13:31:00 -0600 (Thu, 11 Nov 2010) | 53 lines
Merged revisions 294384 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r294384 | jpeeler | 2010-11-09 11:37:59 -0600 (Tue, 09 Nov 2010) | 47 lines
Fix a deadlock in device state change processing.
Copied from some notes from the original author (Russell):
Deadlock scenario:
Thread 1: device state change thread
Holds - rdlock on contexts
Holds - hints lock
Waiting on channels container lock
Thread 2: SIP monitor thread
Holds the "iflock"
Holds a sip_pvt lock
Holds channel container lock
Waiting for a channel lock
Thread 3: A channel thread (chan_local in this case)
Holds 2 channel locks acquired within app_dial
Holds a 3rd channel lock it got inside of chan_local
Holds a local_pvt lock
Waiting on a rdlock of the contexts lock
A bunch of other threads waiting on a wrlock of the contexts lock
To address this deadlock, some locking order rules must be put in place and
enforced. Existing relevant rules:
1) channel lock before a pvt lock
2) contexts lock before hints lock
3) channels container before a channel
What's missing is some enforcement of the order when you involve more than any
two. To fix this problem, I put in some code that ensures that (at least in the
code paths involved in this bug) the locks in (3) come before the locks in (2).
To change the operation of thread 1 to comply, I converted the storage of hints
to an astobj2 container. This allows processing of hints without holding the
hints container lock. So, in the code path that led to thread 1's state, it no
longer holds either the contexts or hints lock while it attempts to lock the
channels container.
(closes issue #18165)
Reported by: antonio
ABE-2583
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@294640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@294349 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@294278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@294125 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@293970 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@293807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@293803 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r293723 | jpeeler | 2010-11-02 18:07:13 -0500 (Tue, 02 Nov 2010) | 15 lines
Merged revisions 293722 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r293722 | jpeeler | 2010-11-02 18:02:51 -0500 (Tue, 02 Nov 2010) | 8 lines
Add enabled/disabled information for rtautoclear sip show settings output.
When setting to zero/"no", the numeric default was shown making it not obvious
the disabled setting was respected.
(closes issue #18123)
Reported by: zerohalo
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@293724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@293648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@293530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using directmedia, Asterisk needs to limit the codecs offered to just
the ones that both sides recognize, otherwise they may end up sending audio
that the other side doesn't understand.
(closes issue #17403)
Reported by: one47
Patches:
sip_codecs_simplified4 uploaded by one47 (license 23)
Tested by: one47, falves11
Review: https://reviewboard.asterisk.org/r/967/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@293493 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@293305 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@293119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.8@292868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r292786 | lmadsen | 2010-10-22 16:16:12 -0500 (Fri, 22 Oct 2010) | 13 lines
Update the LDIF file for LDAP.
The LDIF file asterisk.ldif was quite a bit out of date from the asterisk.ldap-schema file, so I've
now updated that to be in sync. The asterisk.ldif file being out of sync was a problem on my systems
where I was doing an ldapadd to import the schema into the LDAP database, and the existing file
would cause problems and ERROR messages when registering.
Additional documention has been added based on feedback in the issue I'm closing.
(closes issue #13861)
Reported by: scramatte
Patches:
ldap-update.txt uploaded by lmadsen (license 10)
Tested by: lmadsen, jcovert, suretec, rgenthner
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@292787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The array of test subscriptions was declared "static," meaning that the
data.count field would retain its value between runs of the test. After the
first test run, this would result in false reports of test failures.
I chose to just remove the "static" keyword from the structure since it's not
a huge deal to construct this structure during each run of the test. Another
alternative would have been to zero out the data.count fields of each test
subscription instead.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@292741 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This script is useful for quickly generating self-signed CA, server, and client
certificates for use with Asterisk. It is still recommended to obtain
certificates from a recognized Certificate Authority and to develop an
understanding how SSL certificates work. Real security is hard work.
OPTIONS:
-h Show this message
-m Type of cert "client" or "server". Defaults to server.
-f Config filename (openssl config file format)
-c CA cert filename (creates new CA cert/key as ca.crt/ca.key if not passed)
-k CA key filename
-C Common name (cert field)
For a server cert, this should be the same address that clients
attempt to connect to. Usually this will be the Fully Qualified
Domain Name, but might be the IP of the server. For a CA or client
cert, it is merely informational. Make sure your certs have unique
common names.
-O Org name (cert field)
An informational string (company name)
-o Output filename base (defaults to asterisk)
-d Output directory (defaults to the current directory)
Example:
To create a CA and a server (pbx.mycompany.com) cert with output in /tmp:
ast_tls_cert -C pbx.mycompany.com -O "My Company" -d /tmp
This will create a CA cert and key as well as asterisk.pem and the the two
files that it is made from: asterisk.crt and asterisk.key. Copy asterisk.pem
and ca.crt somewhere (like /etc/asterisk) and set tlscertfile=/etc/asterisk.pem
and tlscafile=/etc/ca.crt. Since this is a self-signed key, many devices will
require you to import the ca.crt file as a trusted cert.
To create a client cert using the CA cert created by the example above:
ast_tls_cert -m client -c /tmp/ca.crt -k /tmp/ca.key -C "Joe User" -O \
"My Company" -d /tmp -o joe_user
This will create client.crt/key/pem in /tmp. Use this if your device supports
a client certificate. Make sure that you have the ca.crt file set up as
a tlscafile in the necessary Asterisk configs. Make backups of all .key files
in case you need them later.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@292740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a call is transfered by ECT or implicitly by disconnect in sig_pri or
implicitly by disconnect in chan_misdn, the connected line information is
not exchanged. The connected line interception macros also need to be
executed if defined.
The CALLER interception macro is executed for the held call.
The CALLEE interception macro is executed for the active/ringing call.
JIRA ABE-2589
JIRA SWP-2296
Patches:
abe_2589_c3bier.patch uploaded by rmudgett (license 664)
abe_2589_v1.8_v2.patch uploaded by rmudgett (license 664)
Review: https://reviewboard.asterisk.org/r/958/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@292704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It is possible for a AMI session to freeze because of invalid
use of recursive locks during the EVENT processing. This
patch removes the unnecessary locks.
(closes issue #18167)
Reported by: sustav
Patches:
manager_locking_v1.diff uploaded by dvossel (license 671)
Tested by: sustav
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@292595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
