Don't offer AST_FORMAT_SLINEAR on DAHDI/Zaptel channels... while it could provide a slight performance benefit, the translation core in Asterisk has some flaws when a channel driver offers multiple raw formats. this fix is much simpler than fixing the translation core to solve that issue (although that will be done later).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@186458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I came across this while doing some testing of my ast_channel_ao2 branch.
After running a test overnight that generated over 5 million calls, Asterisk
had taken up about 1 GB of my system memory. So, I re-ran the test with
MALLOC_DEBUG turned on. However, it showed no leaks in Asterisk during the
test, even though Asterisk was still consuming it somehow.
Instead, I turned to valgrind, which when run with --leak-check=full, told
me exactly where the leak came from, which was from allocations inside the
radiusclient-ng library. This explains why MALLOC_DEBUG did not report it.
After a bit of analysis, I found that we were leaking a little bit of memory
every time a CDR record was passed to cdr_radius.
I don't actually have a radius server set up to receive CDR records. However,
I always have my development systems compile and install all modules. In
addition to making sure there are not build errors across modules, always
loading modules helps find bugs like this, too, so it is strongly recommend for
all developers.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@186229 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Acknowledgement for 491 responses were never being processed because it didn't match our pending invite's seqno. Since the ACK was never processed, the 491 frame would continue to be retransmitted until eventually the call was dropped due to max retries. Now during a pending invite, if we receive another invite, we send an 491 and hold on to that glare invite's seqno in the "glareinvite" variable for that sip_pvt struct. When ACK's are received, we first check to see if it is in response to our pending invite, if not we check to see if it is in response to a glare invite. In this case, it is in response to the glare invite and must be dealt with or the call is dropped. I've changed the wait time for resending the re-Invite after receving a 491 response to comply with RFC 3261. Before this patch the scheduled re-Invite would only change a flag indicating that the re-Invite should be sent out, now it actually sends it out as well.
(closes issue #12013)
Reported by: alx
Review: http://reviewboard.digium.com/r/213/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185845 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes a situation where an audiohook that wants DTMF would not
actually get it. This is in the code path where we end DTMF digit length
emulation while handling a NULL frame.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
To drill into the xmpp to find the capabilities between channels, chan_gtalk
calls iks_child() and iks_next(). iks_child() and iks_next() are functions in
the iksemel xml parsing library that traverse xml nodes. The bug here is that
both iks_child() and iks_next() will return the next iks_struct node
*regardless* of type. chan_gtalk expects the next node to be of type IKS_TAG,
which in most cases, it is, but in this case (a call being made from the
Empathy IM client), there exists iks_struct nodes which are not IKS_TAG data
(they are extraneous whitespaces), and chan_gtalk doesn't handle that case,
so capabilities don't match, and a call cannot be made.
iks_first_tag() and iks_next_tag(), on the other hand, will not return the
very next iks_struct, but will check to see if the next iks_struct is of
type IKS_TAG. If it isn't, it will be skipped, and the next struct of type
IKS_TAG it finds will be returned. This assures that chan_gtalk will find
the iks_struct it is looking for.
This fix simply changes all calls to iks_child() and iks_next() to become
calls to iks_first_tag() and iks_next_tag(), which resolves the capability
matching.
The following is a payload listing from Empathy, which, due to the extraneous
whitespace, will not be parsed correctly by iksemel:
<iq from='dbrooksjab@235-22-24-10/Telepathy' to='astjab@235-22-24-10/asterisk' type='set' id='542757715704'> <session xmlns='http://www.google.com/session' initiator='dbrooksjab@235-22-24-10/Telepathy' type='initiate' id='1837267342'> <description xmlns='http://www.google.com/session/phone'> <payload-type clockrate='16000' name='speex' id='96'/>
<payload-type clockrate='8000' name='PCMA' id='8'/>
<payload-type clockrate='8000' name='PCMU' id='0'/>
<payload-type clockrate='90000' name='MPA' id='97'/>
<payload-type clockrate='16000' name='SIREN' id='98'/>
<payload-type clockrate='8000' name='telephone-event' id='99'/>
</description>
</session>
</iq>
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185362 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Issue #14359 was fixed between the time that I posted the review of the backport
of the state interface change for 1.4. This merges the changes from that issue
back into 1.4.
(closes issue #14359)
Reported by: francesco_r
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Handle the scenario where we are called to move audiohooks between channels
and the source channel does not actually have any on it.
(closes issue #14734)
Reported by: corruptor
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel allocation collisions are not handled by chan_misdn very well.
This patch simply avoids the problem for BRI only.
For PRI, allocation collisions are still possible but less likely since
there are simply more channels available and each end could use a different
allocation strategy.
misdn.conf options available:
te_choose_channel - Use to force the TE side to allocate channels.
method - Specify the channel allocation strategy.
(closes issue #13488)
Reported by: Christian_Pinedo
Patches:
isdn_lib.patch.txt uploaded by crich
Tested by: crich, siepkes, festr
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(This is copied and pasted from the review request I made for this patch)
Asterisk has some odd behavior when queue weights are used. The current logic used when
potentially calling a queue member is:
If the member we are going to call is part of another queue and _that other queue has any
callers in it_ and has a higher weight than the queue we are calling from, then don't try
to contact that member. The issue here is what I have marked with underscores. If the
higher-weighted queue has any callers in it at all, then the queue member will be unreachable
from the lower-weighted queue. This has the potential to be really really bad if using a
queue strategy, such as leastrecent or fewestcalls, with the potential to call the same
member repeatedly.
The fix proposed by garychen on issue 13220 is very simple and, as far as I can see, works
well for this situation. With this set of changes, the logic used becomes:
If the member we are going to call is part of another queue, the other queue has a higher
weight than the queue we are calling from, and the higher weight queue has at least as many
callers as available members, then do not try to contact the queue member. If the higher
weighted queue has fewer callers than available members, then there is no reason to deny
the call to this member since the other queue can afford to spare a member.
Since the fix involved writing a generic function for determining the number of available
members in the queue, I also modified the is_our_turn function to make use of the new
num_available_members function to determine if it is our turn to try calling a member. There
is one small behavior change. Before writing this patch, if you had autofill disabled, then
if you were the head caller in a queue, you would automatically be told that it was your
turn to try calling a member. This did not take into account whether there were actually any
queue members available to take the call. Now we actually make sure there is at least one
member available to take the call if autofill is disabled.
(closes issue #13220)
Reported by: garychen
Review: http://reviewboard.digium.com/r/202/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@185031 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After several issues raised on the Asterisk bugtracker against
the 1.4 branch were determined to be fixable with the state interface
change available in the 1.6.X series, it finally came time to just
suck it up and backport the change.
For a detailed explanation of what this change entails, the original
trunk commit for this feature may be found here:
http://svn.digium.com/view/asterisk?view=revision&revision=97203
In addition, the details for the use of this change to fix the problems
stated in issue #12970 may be found in the review request I made for
this change. It is linked below.
(closes issue #12970)
Reported by: edugs15
Review: http://reviewboard.digium.com/r/116
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184980 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We now answer with matching media streams to what is requested. If an INVITE
is received with both a T38 and RTP media stream this means we answer with both.
For any outgoing calls created as a result of this inbound one no T38 is requested
in the initial INVITE. Instead if we start receiving udptl packets we trigger a
reinvite on the outbound side.
(closes issue #12437)
Reported by: marsosa
Tested by: pinga-fogo, okrief, file, afu
Review: http://reviewboard.digium.com/r/208/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If calls were placed using an IP address or hostname the global nat setting was copied over
but was not set on the RTP session itself. This caused the RTP stack to not perform symmetric RTP
actions.
(closes issue #14546)
Reported by: acunningham
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
app_test was failing when sending the last DTMF digit, 8, because of the 100ms pause issued after DTMF is sent. During this pause the other side would hang up causing the test to look like it failed. Now the other side waits a second before hanging up.
(closes issue #12442)
Reported by: tzafrir
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When moving the cursor backward and pressing TAB to autocomplete, a NULL is put
in the line and we are loosing what we have already wrote after the actual
cursor position.
(closes issue #14373)
Reported by: eliel
Patches:
asterisk.c.patch uploaded by eliel (license 64)
Tested by: lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184188 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'digit' variable is guaranteed to be non-NULL, so the if
statement could never evaluate true. Changing to ast_strlen_zero
makes the logic correct.
This was found while reviewing ast_channel_ao2 code review.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@184078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The only way that this leak would occur is if Monitor were started
using the Manager interface and no File: header were given. Discovered
while reviewing the ast_channel_ao2 review request.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@183700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Initialized ast_call_feature in detect_disconnect to avoid accessing uninitialized memory. Cleaned up /param tags in features.h. No longer send dynamic features in ast_feature_detect.
issue #11583
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@183386 65c4cc65-6c06-0410-ace0-fbb531ad65f3
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@183126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A user was having an issue where if an outgoing SIP call was canceled, the SIP device
would remain in use if we had not received any response to the initial INVITE we sent out.
The SIP device would remain in use until the autocongestion timer was exhausted.
I tracked down the cause of this to be the section of code I am removing here. I asked several
people what the purpose of this code was meant to be, but no one could give me any sort of
answer as to why this was here. The person who was having this issue has been using this patch
for several months and it has stopped the problems they have had.
AST-196
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@183115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Chan_h323 can now be compiled against both the previously supported versions of
OpenH323 as well as the current H.323 Plus (version 1.20.2). The configure
script has been modified to look in the default install location of h323 to
hopefully help avoid using the environment variables OPENH323DIR and PWLIBDIR.
Also, the CLI command "h323 show version" has been added which indicates which
version of h323 is in use.
(closes issue 0011261)
Reported by: vhatz
Patches:
asterisk-1.6.0.6-h323plus.patch uploaded by jthurman (license 614)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@182963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
