https://origsvn.digium.com/svn/asterisk/trunk
........
r114146 | murf | 2008-04-15 13:59:50 -0600 (Tue, 15 Apr 2008) | 8 lines
These changes:
a. fix a self-found problem with SPAWN-ing an extension,
where matches were not being found
b. correct some wording in a comment
c. Add some debug for future debugging.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114147 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r114124 | twilson | 2008-04-14 14:12:27 -0500 (Mon, 14 Apr 2008) | 2 lines
Don't unref user twice on failure. Also, when adding sorted list of users, it is best to check the entry already in the list for a "next" entry instead of the newly created entry...
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114129 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114113 | mmichelson | 2008-04-14 11:25:09 -0500 (Mon, 14 Apr 2008) | 17 lines
Merged revisions 114112 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114112 | mmichelson | 2008-04-14 11:24:22 -0500 (Mon, 14 Apr 2008) | 9 lines
If the datastore has been moved to another channel due to a masquerade, then
freeing the datastore here causes an eventual double free when the new channel
hangs up. We should only free the datastore if we were able to successfully remove
it from the channel we are referencing (i.e. the datastore was not moved).
(closes issue #12359)
Reported by: pguido
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114114 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r114109 | file | 2008-04-14 12:36:02 -0300 (Mon, 14 Apr 2008) | 2 lines
During hangup it is possible for p->chan or p->owner to be NULL, so just return what the channel is bridged to instead of what they are *really* bridged to. Thanks Matt Nicholson!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114107 | mmichelson | 2008-04-14 10:01:36 -0500 (Mon, 14 Apr 2008) | 13 lines
Merged revisions 114106 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114106 | mmichelson | 2008-04-14 09:58:02 -0500 (Mon, 14 Apr 2008) | 5 lines
Save a local copy of the generate callback prior to unlocking the channel in
case the generate callback goes NULL on us after the channel is unlocked. Thanks
to Russell for pointing this need out to me.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r114084 | twilson | 2008-04-11 17:48:52 -0500 (Fri, 11 Apr 2008) | 15 lines
Merged revisions 114083 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r114083 | twilson | 2008-04-11 17:32:51 -0500 (Fri, 11 Apr 2008) | 7 lines
Several places in the code called find_callno() (which releases the lock on the pvt structure) and then immediately locked the call and did things with it. Unfortunately, the call can disappear between the find_callno and the lock, causing Bad Stuff(tm) to happen.
Added find_callno_locked() function to return the callno withtout unlocking for instances that it is needed.
(issue #12400)
Reported by: ztel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r114080 | twilson | 2008-04-11 17:23:34 -0500 (Fri, 11 Apr 2008) | 2 lines
Make sure that ${LINE} is set even if linenumber is not set in users.conf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r114067 | twilson | 2008-04-11 16:04:46 -0500 (Fri, 11 Apr 2008) | 3 lines
Fix the fact that global_variables 1) weren't being updated on reload (thanks for the report, Doug), and 2) weren't actually being appended to the list of profile variables because build_profile was called before the list was populated. Also needed to free the contents returned by load_file().
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r114049 | file | 2008-04-10 17:28:40 -0300 (Thu, 10 Apr 2008) | 2 lines
A 'b' option has been added which causes chan_local to return the actual channel that is behind it when queried. This is useful for transfer scenarios as the actual channel will be transferred, not the Local channel. If you have been using Local channels as queue members and having issues when the agent did a blind transfer this option may solve the issue.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@114050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113928 | mmichelson | 2008-04-09 15:56:14 -0500 (Wed, 09 Apr 2008) | 16 lines
Merged revisions 113927 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113927 | mmichelson | 2008-04-09 15:54:31 -0500 (Wed, 09 Apr 2008) | 8 lines
We need to set the persistant_route [sic] parameter for the sip_pvt
during the initial INVITE, no matter if we're building the route set from
an INVITE request or response.
(closes issue #12391)
Reported by: benjaminbohlmann
Tested by: benjaminbohlmann
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113875 | tilghman | 2008-04-09 14:00:40 -0500 (Wed, 09 Apr 2008) | 12 lines
Merged revisions 113874 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113874 | tilghman | 2008-04-09 13:57:33 -0500 (Wed, 09 Apr 2008) | 4 lines
If the [csv] section does not exist in cdr.conf, then an unload/load sequence
is needed to correct the problem. Track whether the load succeeded with a
variable, so we can fix this with a simple reload event, instead.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113876 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r113836 | mmichelson | 2008-04-09 12:48:33 -0500 (Wed, 09 Apr 2008) | 14 lines
There was a subtle logical difference between 1.4 and trunk with regards to how timeouts
were handled. In 1.4, if the absolute timeout were reached on a call, no matter what
the return value of ast_spawn_extension was, the pbx would attempt to go to the 'T'
extension or hangup otherwise. The rearrangement of this function in trunk made this check
only happen in the case that ast_spawn_extension returned 0. If ast_spawn_extension returned
1, then the fact that the timeout expired resulted in a no-op, and would cause an infinite
loop to occur in __ast_pbx_run. This change fixes this problem. Now timeouts will
behave as they did in 1.4
(closes issue #11550)
Reported by: pj
Tested by: putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r113785 | file | 2008-04-09 13:52:04 -0300 (Wed, 09 Apr 2008) | 12 lines
Merged revisions 113784 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r113784 | file | 2008-04-09 13:50:45 -0300 (Wed, 09 Apr 2008) | 4 lines
If we receive an AUTHREQ from the remote server and we are unable to reply (for example they have a secret configured, but we do not) then queue a hangup frame on the Asterisk channel. This will cause the channel to hangup and a HANGUP to be sent via IAX2 to the remote side which is the proper thing to do in this scenario.
(closes issue #12385)
Reported by: viraptor
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@113786 65c4cc65-6c06-0410-ace0-fbb531ad65f3
