https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79748 | mmichelson | 2007-08-16 16:16:40 -0500 (Thu, 16 Aug 2007) | 8 lines
Fixes a problem where agents would get stuck busy due to their wrapuptime being longer than the queue's wrapuptime and
ringinuse=no for the queue.
(closes issue #10215, reported by Doug, repaired by me)
Special thanks to fkasumovic for pointing out the source of the problem and to bweschke for helping to come up with a solution!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: lunn
Patches:
pbx_dundi.diff uploaded by lunn (license 179)
Don't print a warning saying an ethernet interface was found when it indeed was.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79665 | phsultan | 2007-08-16 11:37:10 +0200 (Thu, 16 Aug 2007) | 21 lines
A fix for two critical problems detected while working with Daniel
McKeehan in issue #10184.
Upon priority change, the resource list is not NULL terminated when
moving an item to the end of the list. This makes Asterisk endlessy
loop whenever it needs to read the list. Jids with different resource and
priority values, like in Gmail's and GoogleTalk's jabber clients put
that problem in evidence.
Upon reception of a 'from' attribute with an empty resource string,
Asterisk crashes when trying to access the found->cap pointer if the
resource list for the given buddy is not empty. This situation is
perfectly valid and must be handled. The Gizmoproject's jabber client
put that problem in evidence.
Also added a few comments in the code as well as a handle for the
capabilities from Gmail's jabber client, which are stored in a caps:c tag
rather than the usual c tag.
Closes issue #10184.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r79523 | file | 2007-08-15 11:18:44 -0300 (Wed, 15 Aug 2007) | 6 lines
(closes issue #10456)
Reported by: irroot
Patches:
sip_timeout.patch uploaded by irroot (license 52)
Change hardcoded timer value to defined value. I'm doing this in 1.4 as well so if it needs to be changed in the future this place would not have been forgotten.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: pj
Two of the three places ast_waitfor_nandfds could branch off to did not clear outfd and exception. If the calling function did not clear these there was a chance they could get a false positive on testing to see whether they were set.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
The way a device state change propagates is kind of silly, in my opinion. A
device state provider calls a function that indicates that the state of a
device has changed. Then, another thread goes back and calls a callback for
the device state provider to find out what the new state is before it can go
send it off to whoever cares.
I have changed it so that you can include the state that the device has changed
to in the first function call from the device state provider. This removes the
need to have to call the callback, which locks up critical containers to go find
out what the state changed to.
This change set changes the "simple" device state providers to use the new method.
This includes parking, meetme, and SLA.
I have also mostly converted chan_agent in my branch, but still have some more
things to think through before presenting the plan for converting channel drivers
to ensure all of the right events get generated ...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r78995 | russell | 2007-08-10 10:20:09 -0500 (Fri, 10 Aug 2007) | 4 lines
The last set of changes that I made to "core show locks" made it not able to
track mutexes unless they were declared using AST_MUTEX_DEFINE_STATIC. Locks
initialized with ast_mutex_init() were not tracked. It should work now.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@79005 65c4cc65-6c06-0410-ace0-fbb531ad65f3