https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79276 | russell | 2007-08-13 15:18:30 -0500 (Mon, 13 Aug 2007) | 4 lines
Release the pvt lock before calling find_peer in register_verify to avoid a
deadlock. Also, remove some unnecessary locking in auth_fail that was only done
recursively.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79272 | russell | 2007-08-13 14:27:39 -0500 (Mon, 13 Aug 2007) | 9 lines
I am fighting deadlocks in chan_iax2. I have tracked them down to a single
core issue. You can not call find_callno() while holding a pvt lock as this
function has to lock another (every) other pvt lock. Doing so can lead to a
classic deadlock. So, I am tracking down all of the code paths where this
can happen and fixing them.
The fix I committed earlier today was along the same theme. This patch fixes
some code down the path of authenticate_reply.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79273 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79214 | russell | 2007-08-13 10:28:13 -0500 (Mon, 13 Aug 2007) | 4 lines
Fix a potential deadlock in socket_process. check_provisioning can eventually
call find_callno. You can't hold a pvt lock while calling find_callno because
it goes through and locks every single one looking for a match.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79174 | file | 2007-08-13 11:18:04 -0300 (Mon, 13 Aug 2007) | 4 lines
(closes issue #10437)
Reported by: haklin
Don't set the callerid name and number a second time on a newly created channel. ast_channel_alloc itself already sets it and setting it twice would cause a memory leak.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79175 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78103 | mmichelson | 2007-08-03 15:25:22 -0500 (Fri, 03 Aug 2007) | 7 lines
Changed the behavior of sip's realtime_peer function to match the corresponding way of matching for non-realtime peers.
Now matches are made on both the IP address and port number, or if the insecure setting is set to "port" then just match on the
IP address.
In order to accomplish this, I also added a new API call, ast_category_root, which returns the first variable of an ast_category struct
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@78186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78182 | file | 2007-08-06 13:32:44 -0300 (Mon, 06 Aug 2007) | 2 lines
It is possible for a transfer to occur before the remote device has our tag in which case they send none in the transfer. In this case we need to not fail the transfer dialog lookup.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@78183 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78063 | russell | 2007-08-03 12:01:07 -0500 (Fri, 03 Aug 2007) | 4 lines
Only pass through HOLD and UNHOLD control frames when the mohinterpret option
is set to "passthrough". This was pointed out by Kevin in the middle of a
training session.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@78064 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78028 | russell | 2007-08-02 21:04:22 -0500 (Thu, 02 Aug 2007) | 6 lines
Don't reuse the timespec that was set to 0 in the previous timedwait as it
will just return immediately. Also, fix some logic so the thread's lock
isn't unlocked twice in the weird case of dynamic threads getting acquired
right after a timeout.
(pointed out by SteveK)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@78029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77949 | russell | 2007-08-02 14:25:14 -0500 (Thu, 02 Aug 2007) | 5 lines
Fix the case where a dynamic thread times out waiting for something to do
during the first time it runs. This shouldn't ever happen, but we should
account for it anyway.
(pointed out by pete, who works with mihai)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #10299)
........
r77947 | qwell | 2007-08-02 13:42:36 -0500 (Thu, 02 Aug 2007) | 5 lines
Make sure we clear the prompt status message on a hangup.
Also rearrange messages to better fit with what a wireshark trace shows it should be.
Issue 10299, initial patch and solution by sbisker, modified by me to fit with wireshark trace.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77943 | russell | 2007-08-02 13:04:43 -0500 (Thu, 02 Aug 2007) | 9 lines
Fix another race condition in the handling of dynamic threads. If the dynamic
thread timed out waiting for something to do, but was acquired to perform an
action immediately afterwords, then wait on the condition again to give the
other thread a chance to finish setting up the data for what action this thread
should perform. Otherwise, if it immediately continues, it will perform the
wrong action.
(reported on IRC by mihai, patch by me)
(related to issue #10289)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77944 65c4cc65-6c06-0410-ace0-fbb531ad65f3
trunk version of find_idle_thread() where the old full frame processing
information was not cleared out. This would have caused full frames to get
deferred for processing by threads that weren't actually processing frames for
that call. Nice catch!!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
(closes issue #10358)
........
r77894 | qwell | 2007-08-02 10:15:45 -0500 (Thu, 02 Aug 2007) | 5 lines
Make sure that we show the correct extension if dialed from a macro
"From: 5555" rather than "From: s"
Issue 10358, initial patch by DEA, reworked by me to use S_OR, tested by sbisker
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77887 | russell | 2007-08-01 17:16:17 -0500 (Wed, 01 Aug 2007) | 23 lines
Fix some race conditions which have been causing weird problems in chan_iax2.
The most notable problem is that people have been seeing storms of VNAK frames
being sent due to really old frames mysteriously being in the retransmission
queue and never getting removed.
It was possible that a dynamic thread got created, but did not acquire its lock
before the thread that created it signals it to perform an action. When this
happens, the thread will sleep until it hits a timeout, and then get destroyed.
So, the action never gets performed and in some cases, means a frame doesn't
get transmitted and never gets freed since the scheduler never gets a chance
to reschedule transmission.
Another less severe race condition is in the handling of a timeout for a dynamic
thread. It was possible for it to be acquired to perform at action at the same
time that it hit a timeout. When this occurs, whatever action it was acquired
for would never get performed.
(patch contributed by Mihai and SteveK)
(closes issue #10289)
(closes issue #10248)
(closes issue #10232)
(possibly related to issue #10359)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77883 | qwell | 2007-08-01 16:08:42 -0500 (Wed, 01 Aug 2007) | 7 lines
Fix an issue that caused one-way audio on some newer devices (specifically the 7921),
due to sending packets in the wrong order during hangup.
Also make sure we clear tones/messages on the correct line/instance.
Issue 10291, patch by DEA, tested by sbisker and myself.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77824 | mmichelson | 2007-07-31 10:21:22 -0500 (Tue, 31 Jul 2007) | 6 lines
This patch makes Asterisk send 100 Trying provisional responses upon receipt of re-invites. This makes it so that if there are two or more Asterisk
servers between endpoints, the Asterisk servers will not keep retransmitting the re-invites.
(closes issue #10274, reported by cstadlmann, patched by me with approval from file)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r77794 | russell | 2007-07-30 15:16:43 -0500 (Mon, 30 Jul 2007) | 8 lines
Fix an issue that could potentially cause corruption of the global iax frame
queue. In the network_thread() loop, it traverses the list using the
AST_LIST_TRAVERSE_SAFE macro. However, to remove an element of the list within
this loop, it used AST_LIST_REMOVE, instead of AST_LIST_REMOVE_CURRENT, which I
believe could leave some of the internal variables of the SAFE macro invalid.
Mihai says that he already made this change in his local copy and it didn't help
his VNAK storm issues, but I still think it's wrong. :)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77797 65c4cc65-6c06-0410-ace0-fbb531ad65f3
+ place the link field at the beginning of struct sip_pvt,
and not somewhere in the middle;
+ in __sip_reliable_xmit, remove a duplicate assignment, and
put the statements in a more logical order (i.e. first copy
the payload and associated info, then copy arguments from the
caller, then finish initializing the headers...)
nothing to backport.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77766 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP_NOVIDEO, SIP_DIALOG_ANSWEREDELSEWHERE, SIP_PAGE2_NOTEXT,
SIP_PAGE2_OUTGOING_CALL
These are seldom used so the diff is relatively small.
Note that 'OUTGOING_CALL' is dangerously similar to another
dialog flag, 'SIP_OUTGOING', so the description will need to
clarify the different meaning of the two.
Also note that the description of NOTEXT is a bit unclear - does
it mean we don't support it, or 'not requested or not supported' ?
On passing fix a comment referring to video instead of text.
Finally, mark with XXX a possibly misleading debugging message.
(maybe the latter is worth backporting).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@77739 65c4cc65-6c06-0410-ace0-fbb531ad65f3
