Outgoing SS7 calls fail to detect incoming DTMF so any bridged channel
that requires out-of-band DTMF will not work.
* Added sig_ss7_open_media() calls at appropriate places in sig_ss7.c.
The new call converts conditionaled out unconverted code and shows that
the code really did something useful.
* Improved some chan_dahdi DTMF debug messages to help track DTMF
handling.
(closes issue ASTERISK-19312)
Reported by: Igor Nikolaev
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@358260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The process_output function in manager.c attempted to call fclose and close immediately
afterwards. Since fclose implies close, this resulted in a potential double free on file
descriptors. This patch changes that behavior and also adds error checking to fclose and
close depending on which was deemed necessary. Also error messages. Thanks to Rosen
Iliev for pointing out the location of the problem.
(closes issue ASTERISK-18453)
Reported By: Jaco Kroon
Review: https://reviewboard.asterisk.org/r/1793/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@358214 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk was not setting pendinginvite in the upper half of
handle_request_invite such that the 4xx was retransmitted repeatedly even
though an ack was received for every retransmission.
(closes issue ASTERISK-19303)
Reported by: Jon Tsiros
Patches:
fix-19303.patch uploaded by Jeremiah Gowdy (license 6358)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@358115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
All of these were pretty obviously unused. Some were unused because
the code that used them was #if 0'd. In those cases, I just commented
out the unused-but-set variables.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@358029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes case-sensitivity for device-specific subscriptions such that
the technology identifier is case-insensitive while the remainder of the device
string is still case-sensitive. This should also preserve the original case of
the device string as passed in to the event system. CCSS is the only feature
affected as it is the only consumer of device-specific event subscriptions.
The second part of this patch addresses similar case-sensitivity issues within
CCSS itself that prevented it from functioning correctly after the fix to the
events system.
This adds a unit test to verify that the event system works as expected.
(closes issue ASTERISK-19422)
Review: https://reviewboard.asterisk.org/r/1780/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The check if an ISDN call is bridged before it could be placed on hold is
not necessary and is overly restrictive. The check was originally done to
prevent problems with call transfers in case a user tried to transfer a
call connected to an application to another call connected to an
application. The ISDN transfer code has not required this restriction for
quite some time because ECT could transfer any two active calls to each
other.
* Remove ISDN hold restriction for calls connected to applications.
* Made ast_waitfordigit_full() ignore AST_CONTROL_HOLD and
AST_CONTROL_UNHOLD instead of generating a warning message.
(closes issue ASTERISK-19388)
Reported by: Birger Harzenetter
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This takes two actions.
1. Move the reading of the alertpipe in __ast_read() to immediately before the
removal of frames from the readq. This means we won't do something silly like
read from the alertpipe, then ignore the fact that there's a frame to get from
the readq since channel's fdno is the AST_TIMING_FD.
2. When ast_settimeout() sets the rate to 0 and the timingfunc to NULL, if the
channel's fdno is the AST_TIMING_FD, then set the fdno to -1. This is because
if the rate is 0 and the timingfunc is NULL, it means that the channel's timing
fd is being invalidated, so any pending reads should not occur.
This may actually solve more issues than the referenced one below, but it's not
known at this time for sure.
(closes issue ASTERISK-19223)
reported by Frank-Michael Wittig
Review: https://reviewboard.asterisk.org/r/1779
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This borrows code heavily from changes made in translation code in Asterisk 10.
This uses the quality and sample rate change of translation in order to pick
paths rather than the computational cost of translations. Computational cost
is used solely in determining if a single translation step from a specific
translator is better than the same translation step provided by a different
translator.
(closes issue ASTERISK-16821)
reported by Andrew Lindh
Review: https://reviewboard.asterisk.org/r/1772
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the change from 1.6.2 to 1.8, ast_sockaddr was introduced which changed the
behavior of ast_find_ourip such that port number was wiped out. This caused
the port in internip (which is used for Contact and Call-ID on NOTIFYs) to be
0. This change causes ast_find_ourip to be port-preserving again.
(closes issue ASTERISK-19430)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r203638, during the addition of the Channel Event Logging, in mid-2009, this
got broken in trunk and ended up in asterisk 1.8 and higher. This fixes so the
CDR(accountcode) from the calling channel is available to dialed channels again
as well as showing up properly in the CDR's.
(closes issue ASTERISK-19384)
Reported by: jamicque
Patches: accountcode.patch (License #6033) by jamicque
Review: https://reviewboard.asterisk.org/r/1775/
Reviewed by: Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(issue ASTERISK-19352)
Reported by: jamicque
Patches:
asterisk-19352-transport-warning-message-v1.patch uploaded by Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reporter was uable to use varchar utf8_unicode_ci with cdr_adaptive_odbc, so
this patch adds those along with some other character types to the list of types
cdr_adaptive_odbc will work using the varchar conditions. The problem wasn't really
UTF8 characters as much as it was a failure to respond to the exact type that was
declared/in use on that database.
(closes issue ASTERISK-19334)
Reported By: Igor Nikolaev
Patches:
cdr_adaptive_odbc.patch uploaded by Igor Nikolaev (license 6236)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357455 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the stack frame is allocated, we save the address to which we should
return, when the Gosub returns. However, if we just want to restore the
priority, then we need to subtract 1 before setting it. Otherwise, when
a Gosub goes to a nonexistent address, it will skip a priority in the
dialplan. This is because when we return from an application, the PBX
increments the priority for us.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, Using "transport=" multiple times would cause them to add to one
another like allow/deny. This patch changes that behavior to simply use the transport
option specified last. Also, if no transport option is applied now, the default will
automatically be UDP.
(closes ASTERISK-19352)
Reported by: jamicque
Patches:
asterisk-19352-transport-warning-message-v1.patch uploaded by Michael L. Young (license 5026)
issueA19352_no_transport_is_udp.patch uploaded by Walter Doekes (license 5674)
Review: https://reviewboard.asterisk.org/r/1745/diff/#index_header
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The build system has some special magic to ensure that if Asterisk is built
with --enable-dev-mode *and* DONT_OPTIMIZE, that all the source is still compiled
with the optimizer enabled (even though the result will be thrown away), because
the compiler is able to find a great deal of coding errors and bugs as a result
of running its optimizers. Unfortunately at some point this mode got broken,
and the 'throwaway' compile of the code was no longer done with the optimizer
enabled. This patch corrects that problem.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@357212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r354890, a memory leak in app_voicemail was fixed by properly disposing of
the allocated heard/deleted pointers. However, there are situations,
particularly when no messages are found in a folder, where these pointers are
not allocated and not NULL. In that case, an invalid free would be attempted,
which could crash app_voicemail. As there are a number of code paths where
this could occur, this patch uses the number of messages detected in the folder
before it attempts to free the pointers. This resolves the crash detected in
the Asterisk Test Suite's check_voicemail_nominal test.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SIP TCP/TLS worker threads were created joinable but noone could join
them if they died on their own.
* Fix the SIP TCP/TLS worker threads to not be created joinable.
* _sip_tcp_helper_thread() only needs one parameter since the pvt
parameter is only passed in as NULL and never used.
(closes issue ASTERISK-19203)
Reported by: Steve Davies
Review: https://reviewboard.asterisk.org/r/1714/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The patch for ASTERISK-19253 included properly shutting down the libsrtp
library in the case of module unload. Unfortunately, not all distributions
have the srtp_shutdown call. As such, this patch removes calling
srtp_shutdown.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356650 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Currently, when using res_srtp, once the SRTP policy has been added to the
current session the policy is locked into place. Any attempt to replace an
existing policy, which would be needed if the remote endpoint negotiated a new
cryptographic key, is instead rejected in res_srtp. This happens in particular
in transfer scenarios, where the endpoint that Asterisk is communicating with
changes but uses the same RTP session.
This patch modifies res_srtp to allow remote and local policies to be reloaded
in the underlying SRTP library. From the perspective of users of the SRTP API,
the only change is that the adding of remote and local policies are now added
in a single method call, whereas they previously were added separately. This
was changed to account for the differences in handling remote and local
policies in libsrtp.
Review: https://reviewboard.asterisk.org/r/1741/
(closes issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches:
srtp_renew_keys_2012_02_22.diff uploaded by Matt Jordan (license 6283)
(with some small modifications for this check-in)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356604 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Custom parking extensions may not be coded such that the first and only
extension priority is the Park application. These custom parking
extensions will not be recognized as parking extensions. When a call is
blind transferred to an extension that is not recognized as a parking
extension, the normal blind transfer code causes the transferred channel
to start executing dialplan. Calls that get parked in this manner do not
know the original channel name that parked the call so the original parker
could never be called back if the parked call is not retrieved before the
timeout time. The parking space is also announced to the call being
parked as a side effect of not knowing the original parking channel.
* Fix handling of BLINDTRANSFER channel variable for call parking.
* Fixed SIP blind transfer using the wrong dialplan context variable to
check for the parking extension.
(closes issue ASTERISK-19322)
Reported by: aragon
Tested by: rmudgett, jparker
Review: https://reviewboard.asterisk.org/r/1730/
JIRA AST-766
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we send an ACK for a 2xx response to an INVITE, we are supposed
to use the learned route set. However, when we receive a non-2xx final
response to an INVITE, we are supposed to send the ACK to the same place
we initially sent the INVITE.
We had been doing this up until the changes went in that would build a route
set from provisional responses. That introduced a regression where we would
use the learned route set under all circumstances.
With this change, we now will set the destination of our ACK based on the
invitestate. If it is INV_COMPLETED then that means that we have received
a non-2xx final response (INV_TERMINATED indicates a 2xx response was received).
If it is INV_CANCELLED, then that means the call is being canceled, which
means that we should be ACKing a 487 response.
The other change introduced here is setting the invitestate to INV_CONFIRMED
when we send an ACK *after* the reqprep instead of before. This way, we can
tell in reqprep more easily what the invitestate is prior to sending the ACK.
(closes issue ASTERISK-19389)
reported by Karsten Wemheuer
patches:
ASTERISK-19389v2.patch uploaded by Mark Michelson (license #5049)
(with some slight modifications prior to commit)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356475 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the res_calendar module was followed immediately by one of the
calendar tech modules and "core stop gracefully" was run, Asterisk
would crash.
This patch adds use count tracking for res_calendar so that it is
unloaded after the tech modules when shutting down gracefully. It
is now not possible to unload all the of the calendar modules via
"module unload res_calednar.so", but it is still possible to unload
them all via "module unload -h res_calendar.so".
Review: https://reviewboard.asterisk.org/r/1752/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356291 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "sip show peers" command uses a fix sized array to sort the current peers
in the peers ao2_container. The size of the array is based on the current
number of peers in the container. However, once the size of the array is
determined, the number of peers in the container can change, as the peers
container is not locked. This could cause a buffer overrun when populating
the array, if peers were added to the container after the array was created.
Additionally, a memory leak of the allocated array would occur if a user
caused the _show_peers method to return CLI_SHOWUSAGE.
We now create a snapshot of the current peers using an ao2_callback with the
OBJ_MULTIPLE flag. This size of the array is set to the number of peers
that the iterator will iterate over; hence, if peers are added or removed
from the peers container it will not affect the execution of the "sip show
peers" command.
Review: https://reviewboard.asterisk.org/r/1738/
(closes issue ASTERISK-19231)
(closes issue ASTERISK-19361)
Reported by: Thomas Arimont, Jamuel Starkey
Tested by: Thomas Arimont, Jamuel Starkey
Patches: sip_show_peers_2012_02_16.diff uploaded by mjordan (license 6283)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@356214 65c4cc65-6c06-0410-ace0-fbb531ad65f3
'p->outgoing' in chan_dahdi and sig_analog wern't kept in sync, particulary FXS ast_hangup didn't clear the 'outgoing' flag.
sig_pri and sig_ss7 were keeping 'outgoing' flag insync.
Now provides a callback for all the low level sig_XXX modules.
(issue ASTERISK-19316)
alecdavis (license 585)
Reported by: Jeremy Pepper
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/1747/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@355850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
IAX2 uses the trunkfreq variable to determine how often to send trunk packets, but
this value is in milliseconds while ast_timer_set_rate() expects the rate argument
to be ticks per second. So we divide 1000 by trunkfreq and pass that in instead.
With a default of 20ms, this change makes IAX2 send trunk packets every 20ms
instead of every 50ms.
Tracked down by myself and Bob Wienholt.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@355746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes two main issues:
1. Asterisk would send a CANCEL to the route created by the provisional response
instead of using the same destination it did in the initial INVITE.
2. If a new route set arrives in a 200 OK than was in the 1XX response (perfectly
possible if our outbound INVITE gets forked), then the route set in the 200 OK
needs to overwrite the route set in the 1XX response.
(closes issue ASTERISK-19358)
Reported by: Karsten Wemheuer
Tested by: Karsten Wemheuer
patches:
ASTERISK-19358.patch uploaded by Mark Michelson (license 5049)
ASTERISK-19358.patch uploaded by Stefan Schmidt (license 6034)
Review: https://reviewboard.asterisk.org/r/1749
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@355732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
