Paul Belanger pointed out that using sed in the Makefile is an issue with multiple platforms. We are cleaning up the Doxygen config as a following step so I just switched the sed inplace changes to be an echo append instead.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add app_skel.c as an example in app.c and fix some formating for the "Dial Privacy scripts" so it actually shows up in the Doxygen output.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374956 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Doxygen uses the ASTERISKVERSION as a sub header. If a SVN export is done and no .svn or .version file exists it defualts to UNKNOWN__and_probably_unsupported which is honest but not great for the online docs. During the "make progdocs" I added a test for this and just warned and ommitted the version.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374949 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During testing I used an alternate output directory and mistakenly committed it. Matt Jordan noticed and I reverted. This is the correct setting for local output to match with all branches.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Begin update of static-http files and general clean ups. This only adds the standard header to the files.
(issue ASTERISK-20503)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The autoconf configuration system had a test for DOT but not for Doxygen. I added the test for Doxygen and did an overhaul of the Makefile check to a much simpler process.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a format name was not found by ast_getformatbyname, a NULL pointer
would be passed into ast_format_rate and immediately dereferenced.
This ensures that a valid pointer is used since the structure is
already allocated on the stack.
(closes issue DPH-523)
Reported-by: Steve Pitts
........
Merged revisions 374932 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374933 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
........
Merged revisions 374906 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374914 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add Doxygen to the Debian install list. I will check for other platforms like Red Hat
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374897 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The JQuery URL to version 1.4 will be removed within the life span of Asterisk 11. This is a compatible upgrade by using the URL for 1.8.
(issue ASTERISK-20503)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revert a local testing config that I made. This was not intended to be committed.
Thank you Matt Jordan for noticing this.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During testing, it was discovered that having chan_sip
export global symbols was problematic.
The biggest problem was that load order was affected.
Trying to use realtime could be problematic since in
all likelihood the necessary realtime driver(s) would
not be loaded before chan_sip.
In addition, it was found that it was impossible to
use the Digium Phone Module for Asterisk since it
must be loaded before chan_sip since it must hook
into chan_sip's configuration parsing.
The solution is to use a virtual table in the same
manner that other modules in Asterisk do, like
app_voicemail.
(closes issue ASTERISK-20545)
Reported by: kmoore
........
Merged revisions 374842 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374849 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
........
Merged revisions 374844 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374845 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374846 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
........
Merged revisions 374803 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374804 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374805 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to usage of ast_hook_send_action, AMI action handling code should
be able to handle a NULL mansession->session. This would cause a crash
on NULL dereference if action_originate was called from
ast_hook_send_action.
(closes issue ASTERISK-20544)
........
Merged revisions 374792 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374793 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.
........
Merged revisions 374695 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374708 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since there are a number of legacy devices out there that fail to handle ICE
candidates properly (which is a nice way of saying something much uglier),
disable it by default.
Support for ICE candidates can be enabled in rtp.conf using the icesupport
setting.
........
Merged revisions 374676 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374677 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)
........
Merged revisions 374652 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374657 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374658 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pjproject, in order to solve build problems on Windows [1], undefines s_addr in
one of it's headers that is included in res_rtp_asterisk.c. On Solaris s_addr
is not a structure member, but defined to map to the real strucuture member,
therefore when building on Solaris it's possible to get build errors like:
[CC] res_rtp_asterisk.c -> res_rtp_asterisk.o
In file included from /export/home/admin/asterisk-11-svn/include/asterisk/stun.h:29,
from res_rtp_asterisk.c:51:
/export/home/admin/asterisk-11-svn/include/asterisk/network.h: In function `inaddrcmp':
/export/home/admin/asterisk-11-svn/include/asterisk/network.h:92: error: structure has no member named `s_addr'
/export/home/admin/asterisk-11-svn/include/asterisk/network.h:92: error: structure has no member named `s_addr'
res_rtp_asterisk.c: In function `ast_rtp_on_ice_tx_pkt':
res_rtp_asterisk.c:706: warning: dereferencing type-punned pointer will break strict-aliasing rules
res_rtp_asterisk.c:710: warning: dereferencing type-punned pointer will break strict-aliasing rules
res_rtp_asterisk.c: In function `rtp_add_candidates_to_ice':
res_rtp_asterisk.c:1085: error: structure has no member named `s_addr'
make[2]: *** [res_rtp_asterisk.o] Error 1
make[1]: *** [res] Error 2
make[1]: Leaving directory `/export/home/admin/asterisk-11-svn'
gmake: *** [_cleantest_all] Error 2
Unfortunately, in order to make this work, I also had to make sure pjproject
only used the typdef pj_in_addr and not the struct pj_in_addr so that when
building Asterisk I could "typedef struct in_addr pj_in_addr". It's possible
then that the library and users of those interfaces in Asterisk have a different
idea about the type of the argument, while on the surface it looks like they are
all 32 bit big endian values.
[1] http://trac.pjsip.org/repos/changeset/484
(issues ASTERISK-20366)
Reported by: Ben Klang
Tested by: Ben Klang, mjordan
patches:
0001-pjproject-Fix-for-Solaris-builds.-Do-not-undef-s.patch uploaded by Shaun Ruffell (license 5417)
........
Merged revisions 374642 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes trivial build error on Solaris:
acl.c: In function `get_local_address':
acl.c:196: error: `best_score' undeclared (first use in this function)
acl.c:196: error: (Each undeclared identifier is reported only once
acl.c:196: error: for each function it appears in.)
make[2]: *** [acl.o] Error 1
(issue ASTERISK-20366)
Reported by: Ben Klang
Tested by: Ben Klang
patches:
0002-main-acl.c-Trivial.-best_score-should-be-defined-for.patch by Shaun Ruffell (license 5417)
........
Merged revisions 374632 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While XEP-0115 states that the node and ver attributes are both required, some
devices fail to provide either field. Prior to this patch, failure to provide
the node or ver attribute would cause a crash in res_xmpp. While failing to
provide the node or ver attribute is technically invalid, since this
information is not utilized by Asterisk except for reporting purposes, for
interoperability reasons, we continue to process the capability stanza anyways.
(closes issue ASTERISK-20495)
Reported by: Martin W
Tested by: Martin W
patches:
20495.patch uploaded by Martin W (license #6434)
........
Merged revisions 374622 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the channel technology agnostic application/AMI command MessageSend,
the "From" field is technically optional for the SIP channel driver. However,
if being sent by the XMPP resource module (either res_xmpp or res_jabber), the
"From" field is necessary, and must correspond to a defined account. This
patch updates the documentation for this application/AMI command to reflect
this.
(closes issue ASTERISK-20405)
Reported by: Leif Madsen
........
Merged revisions 374611 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374612 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
........
Merged revisions 374586 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374587 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374588 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
........
Merged revisions 374537 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374538 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The AMI DBDelTree command will return Success/Key tree deleted successfully even
if the given key does not exist. The CLI command 'database deltree' had a
similar problem, but was saved because it actually responded with '0 database
entries removed'. AGI had a slightly different error, where it would return
success if the database was unavailable.
This came from confusion about the ast_db_deltree retval, which is -1 in the
event of a database error, or number of entries deleted (including 0 for
deleting nothing).
* Changed some poorly named res variables to num_deleted
* Specified specific errors when calling ast_db_deltree (database unavailable
vs. entry not found vs. success)
* Fixed similar bug in AGI database deltree, where 'Database unavailable'
results in successful result
(closes issue AST-967)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2138/
........
Merged revisions 374426 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374427 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374428 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374429 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk's DTMF Specifications are based on AT&T specs, which may not be compatible in other countries.
Various countries have different specifications for the maximum power level differences
between the DTMF low group and high group of frequencies.
Power level difference between frequencies for different Administrations/RPOAs
NTT = Max. 5 dB
AT&T = 4dB(reverse) to 8dB(normal)
Danish = Max. 6 dB
Australian = Max. 10 dB
Brazilian = Max. 9 dB
ETSI = Max. 6 dB from ETSI ES 201 235-3 V1.3.1 (2006-03)
Now allow 4 variables to be individually configured in dsp.conf, with reasonable min/max of 2dB to 20dB.
Default is AT&T specifications
Add's the following variables to dsp.conf
;dtmf_normal_twist=6.31
;dtmf_reverse_twist=2.51
;relax_dtmf_normal_twist=6.31
;relax_dtmf_reverse_twist=3.98
(closes issue ASTERISK-20442)
Reported by: tbsky
Tested by: tbsky,alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2141/
........
Merged revisions 374384 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374385 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374386 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374387 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_jabber resource module uses the ASTOBJ library for managing its ref
counted objects. After calling ASTOBJ_CONTAINER_FIND to locate a buddy object,
the pointer to the object has to be checked to see if the buddy existed.
Prior to this patch, the buddy object was not checked for NULL; with this patch
in both aji_client_info_handler and aji_dinfo_handler the pointer is checked
before used and, if no buddy object was found, the handlers return an error
code.
This patch does not take the approach that our JID can be used to log in from
another resource. If that approach is desired, an improvement could be made to
this patch to create the buddy on the fly. This patch seeks only to prevent
Asterisk from crashing.
FYI: In Asterisk 11+, you really should be using res_xmpp. It does not have
this problem, as it moved to the astobj2 library.
Note that multiple people have proposed patches for this issue; the patch being
committed here is based on those.
(closes issue ASTERISK-19532)
Reported by: Karsten Wemheuer
Tested by: Byron Clark
patches:
fix-jabber uploaded by Karsten Wemheuer (license #5930)
xmpp_no_crash_with_ejabberd.patch uploaded by Byron Clark (license #6157)
(closes issue ASTERISK-19557)
Reported by: ulugutz
........
Merged revisions 374335 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374336 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374337 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For each item in core_instances disposed of in the shutdown of ccss, any
generic monitor instances referenced by the objects will be removed from
generic_monitors during their destruction. Hilarity ensues if
generic_monitors no longer exists.
Thanks to the Asterisk Test Suite's generic_ccss test for complaining loudly
when it ran into this.
........
Merged revisions 374300 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374301 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Because hashtest2 has to provide symbols for things in asterisk that items
it includes may use, when astobj2 decided to use ast_register_atexit it needed
to provide a declaration for that as well. Otherwise - no linky.
On a related note, ASTERISK-20505 was filed to convert hashtest/hashtest2 into
actual unit tests, so we don't run into this problem again.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374229 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard pointed out two problems with the check-in from r374177:
* The ast_msg_shutdown function declaration doesn't match the prototype
in main/message.c.
* The ref/alloc function usage in astobj2 (in trunk) can use the ao2_t_*
variants of the functions to allow the REF_DEBUG flag to enable/disable
their debug counterparts.
........
Merged revisions 374210 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374211 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374213 65c4cc65-6c06-0410-ace0-fbb531ad65f3