https://origsvn.digium.com/svn/asterisk/trunk
........
r144523 | murf | 2008-09-25 15:18:12 -0600 (Thu, 25 Sep 2008) | 13 lines
I added a little verbage to hashtab for the hashtab_destroy func.
It was pretty sparsely documented.
This update fleshes out the pbx_lua module, to
add the switch statements to the extensions in the
extensions.lua file, as well as removing them when
the module is unloaded.
Many thanks to Matt Nicholson for his fine
contribution!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@144524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r144482 | murf | 2008-09-25 11:51:11 -0600 (Thu, 25 Sep 2008) | 14 lines
(closes issue #13558)
Reported by: mnicholson
Considering that the example extensions.lua used nothing but ["12345"] notation,
and that the resulting error message:
[Sep 24 17:01:16] ERROR[12393]: pbx_lua.c:1204 exec: Error executing lua extension: attempt to call a nil value
is not very informative as to the nature of the problem, I think this bug
fix is a big win!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@144483 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r144199 | tilghman | 2008-09-24 01:43:05 -0500 (Wed, 24 Sep 2008) | 4 lines
Create a 'hashcompat' option that permits the results of a CURL() able to be
passed directly into the HASH() function. Requested via the -users list, and
committed at Astricon in the Code Zone.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@144200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r144067 | murf | 2008-09-23 10:52:32 -0600 (Tue, 23 Sep 2008) | 37 lines
Merged revisions 144066 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144066 | murf | 2008-09-23 10:41:49 -0600 (Tue, 23 Sep 2008) | 29 lines
(closes issue #13489)
Reported by: DougUDI
Tested by: murf
(closes issue #13490)
Reported by: seanbright
Tested by: murf
(closes issue #13467)
Reported by: edantie
Tested by: murf, edantie, DougUDI
This crash happens because we are unsafely handling old pointers.
The channel whose cdr is being handled, has been hung up and
destroyed already. I reorganized the code a bit, and tried not
to lose the fork-cdr-chain concepts of the previous code.
I now verify that the 'previous' channel (the channel we
had when the bridge was started), still exists, by looking it up
by name in the channel list. I also do not try to reset the
CDR's of channels involved in bridges.
Testing shows it solves the crash problem, and should not
negatively impact previous fixes involving CDR's generated
during/after blind transfers. (The reason we need to reset
the CDR's on the "beginning" channels in the first place).
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@144068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r144025 | mmichelson | 2008-09-23 10:37:00 -0500 (Tue, 23 Sep 2008) | 16 lines
When a promiscuous redirect contained both a user and
host portion in the Contact URI and specifies a
transport, the parsing done in parse_moved_contact
resulted in a malformed URI.
This commit fixes the parsing so that a proper
Dial string may be formed when the forwarded
call is placed.
(closes issue #13523)
Reported by: mattdarnell
Patches:
13523v2.patch uploaded by putnopvut (license 60)
Tested by: mattdarnell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@144026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r143840 | mvanbaak | 2008-09-21 11:31:54 +0200 (Sun, 21 Sep 2008) | 3 lines
document the new context argument for privacymanager
so people can do pattern matching on the input
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@143842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r143609 | mmichelson | 2008-09-19 10:43:28 -0500 (Fri, 19 Sep 2008) | 11 lines
We should only unsubscribe to the device state event
subscription if we have previously subscribed. Otherwise
a segfault will occur.
(closes issue #13476)
Reported by: jonnt
Patches:
13476.patch uploaded by putnopvut (license 60)
Tested by: jonnt
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@143610 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r143400 | mmichelson | 2008-09-17 15:25:40 -0500 (Wed, 17 Sep 2008) | 16 lines
If attempting to free a NULL pointer when MALLOC_DEBUG
is set, don't bother searching for a region to free, just
immediately exit.
This has the dual benefit of suppressing a warning message
about freeing memory at (nil) and of optimizing the free()
replacement by not having to do any futile searching for
the proper region to free.
(closes issue #13498)
Reported by: pj
Patches:
13498.patch uploaded by putnopvut (license 60)
Tested by: pj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@143401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
................
r143340 | mmichelson | 2008-09-17 13:26:35 -0500 (Wed, 17 Sep 2008) | 14 lines
Merged revisions 143337 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r143337 | mmichelson | 2008-09-17 13:24:15 -0500 (Wed, 17 Sep 2008) | 6 lines
Allow for "G.729" if offered in an SDP even though
it is not RFC 3551 compliant. Some Cisco switches
will send this in an SDP, and it doesn't hurt to
be able to accept this.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@143348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r142992 | tilghman | 2008-09-12 18:30:03 -0500 (Fri, 12 Sep 2008) | 27 lines
Create a new config file status, CONFIG_STATUS_FILEINVALID for differentiating
when a file is invalid from when a file is missing. This is most important when
we have two configuration files. Consider the following example:
Old system:
sip.conf users.conf Old result New result
======== ========== ========== ==========
Missing Missing SIP doesn't load SIP doesn't load
Missing OK SIP doesn't load SIP doesn't load
Missing Invalid SIP doesn't load SIP doesn't load
OK Missing SIP loads SIP loads
OK OK SIP loads SIP loads
OK Invalid SIP loads incompletely SIP doesn't load
Invalid Missing SIP doesn't load SIP doesn't load
Invalid OK SIP doesn't load SIP doesn't load
Invalid Invalid SIP doesn't load SIP doesn't load
So in the case when users.conf doesn't load because there's a typo that
disrupts the syntax, we may only partially load users, instead of failing with
an error, which may cause some calls not to get processed. Worse yet, the old
system would do this with no indication that anything was even wrong.
(closes issue #10690)
Reported by: dtyoo
Patches:
20080716__bug10690.diff.txt uploaded by Corydon76 (license 14)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r142866 | tilghman | 2008-09-12 15:49:46 -0500 (Fri, 12 Sep 2008) | 18 lines
Merged revisions 142865 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142865 | tilghman | 2008-09-12 15:37:18 -0500 (Fri, 12 Sep 2008) | 11 lines
Create rules for disallowing contacts at certain addresses, which may
improve the security of various installations. As this does not change
any default behavior, it is not classified as a direct security fix for
anything within Asterisk, but may help PBX admins better secure their
SIP servers.
(closes issue #11776)
Reported by: ibc
Patches:
20080829__bug11776.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76, blitzrage
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r142676 | murf | 2008-09-11 22:50:48 -0600 (Thu, 11 Sep 2008) | 40 lines
Merged revisions 142675 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142675 | murf | 2008-09-11 22:29:34 -0600 (Thu, 11 Sep 2008) | 29 lines
Tested by: sergee, murf, chris-mac, andrew, KNK
This is a "second attempt" to restore the previous "endbeforeh" behavior
in 1.4 and up. In order to capture information concerning all the
legs of transfers in all their infinite combinations, I was forced
to this particular solution by a chain of logical necessities, the
first being that I was not allowed to rewrite the CDR mechanism from
the ground up!
This change basically leaves the original machinery alone, which allows
IVR and local channel type situations to generate CDR's as normal, but
a channel flag can be set to suppress the normal running of the h exten.
That flag would be set by the code that runs the h exten from the
ast_bridge_call routine, to prevent the h exten from being run twice.
Also, a flag in the ast_bridge_config struct passed into ast_bridge_call
can be used to suppress the running of the h exten in that routine. This
would happen, for instance, if you use the 'g' option in the Dial app.
Running this routine 'early' allows not only the CDR() func to be used
in the h extension for reading CDR variables, but also allows them to
be modified before the CDR is posted to the backends.
While I dearly hope that this patch overcomes all problems, and
introduces no new problems, reality suggests that surely someone
will have problems. In this case, please re-open 13251 (or 13289),
and we'll see if we can't fix any remaining issues.
** trunk note: some code to suppress the h exten being run
from app_queue was added; for the 'continue' option available
only in trunk/1.6.x.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r142576 | murf | 2008-09-11 17:12:53 -0600 (Thu, 11 Sep 2008) | 28 lines
Merged revisions 142575 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142575 | murf | 2008-09-11 16:55:49 -0600 (Thu, 11 Sep 2008) | 20 lines
(closes issue #13364)
Reported by: mdu113
Well, fundamentally, the problems revealed in 13364 are
because of the ForkCDR call that is done before the dial.
When the bridge is in place, it's dealing with the first
(and wrong) cdr in the list.
So, I wrote a little func to zip down to the first non-locked
cdr in the chain, and thru-out the ast_bridge_call, these
results are used instead of raw chan->cdr and peer->cdr pointers.
This shouldn't affect anyone who isn't forking cdrs before a
dial, and should correct the cdr's of those that do.
So, this change ends up correcting the dstchannel
and userfield; the disposition was fixed by a previous
patch, it was OK coming into this problem.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142631 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r142536 | tilghman | 2008-09-11 16:45:07 -0500 (Thu, 11 Sep 2008) | 4 lines
Add usegmtime, as per the recent -users list discussion, and also add my
explanation to the file, since that additional text helps people understand
the concept.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r142475 | murf | 2008-09-10 16:11:27 -0600 (Wed, 10 Sep 2008) | 38 lines
Merged revisions 142474 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142474 | murf | 2008-09-10 15:58:17 -0600 (Wed, 10 Sep 2008) | 30 lines
(closes issue #12318)
Reported by: krtorio
I made a small change to the code that handles local channel situations.
In that code, I copy the answer time from the peer cdr, to the bridge_cdr,
but I wasn't also copying the disposition from the peer cdr.
So, Now I copy the disposition, and I've tested against
these cases:
1. phone 1 never answers the phone; no cdr is generated at all.
this should show up as a manager command failure or something.
2. phone 2 never answers. CDR is generated, says NO ANSWER
3. phone 2 is busy. CDR is generated, says BUSY
4. phone 2 answers: CDR is generated, times are correct; disposition
is ANSWERED, which is correct. The start time is the time that
the manager dialed the first phone. The answer time is the time
the second phone picks up.
I purposely left the cid and src fields blank; since this call really
originates from the manager, there is no 'easy' data to put in these
fields. If you feel strongly that these fields should be filled in,
re-open this bug and I'll dig further.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r142355 | russell | 2008-09-10 11:41:55 -0500 (Wed, 10 Sep 2008) | 15 lines
Merged revisions 142354 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142354 | russell | 2008-09-10 11:39:53 -0500 (Wed, 10 Sep 2008) | 7 lines
It is a normal situation that a task gets put in the scheduler that should run
as soon as possible. Accept "0" as an acceptable time to run, and also treat
negative as "run now", and don't print a debug message about it.
(inspired by a message asking about the "request to schedule in the past"
debug message on the -dev list)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r142146 | mmichelson | 2008-09-09 12:15:29 -0500 (Tue, 09 Sep 2008) | 21 lines
This is the trunk version of the patch to close
issue 12979. The difference between this and the
1.6.0 and 1.6.1 versions is that this is a much more
invasive change. With this, we completely get rid
of the interfaces list, along with all its helper
functions.
Let me take a moment to say that this change personally
excites me since it may mean huge steps forward regarding
proper lock order in app_queue without having to strew
seemingly unnecessary locks all over the place. It also
results in a huge reduction in lines of code and complexity.
Way to go Brett!
(closes issue #12979)
Reported by: sigxcpu
Patches:
20080710_issue12979_queue_custom_state_interface_trunk_2.diff uploaded by bbryant (license 36)
Tested by: sigxcpu, putnopvut
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142147 65c4cc65-6c06-0410-ace0-fbb531ad65f3
can correctly parse custom device states (and any
other device which does not contain a '/').
1.6.1 will be getting this patch as well, but trunk
is going to get a much more massive patch by bbryant
which does some very nice overhauling of some
structures in app_queue.
(closes issue #12979)
Reported by: sigxcpu
Patches:
12979.patch uploaded by putnopvut (license 60)
Tested by: sigxcpu
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
................
r142080 | mmichelson | 2008-09-09 11:20:41 -0500 (Tue, 09 Sep 2008) | 29 lines
Merged revisions 142079 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r142079 | mmichelson | 2008-09-09 11:19:17 -0500 (Tue, 09 Sep 2008) | 21 lines
When determining if codecs used by SIP peers allow
the media to be natively bridged, use the jointcapability
instead of the peercapability.
It seems that the intent of using the peercapability was to
expand the choice of codecs for the call to increase the
chances of being able to native bridge the channels. The
problem is that if a codec were settled on for the native
bridge and that wasn't a codec that was configured to be used
by Asterisk for that peer, then Asterisk would send a
REINVITE with no codecs in the SDP which is a bug no matter
how you slice it.
(closes issue #13076)
Reported by: ramonpeek
Patches:
13076.patch uploaded by putnopvut (license 60)
Tested by: tbelder
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@142081 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r141998 | mmichelson | 2008-09-09 07:32:38 -0500 (Tue, 09 Sep 2008) | 7 lines
Use ast_debug for debug messages. I was wondering why debug
messages weren't showing up when I had set the debug level
high for just app_queue.c. It's because we were only checking
the global option_debug variable instead of using the awesome
macro which checks both the global and file-specific value
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@141999 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r141949 | russell | 2008-09-08 20:47:56 -0500 (Mon, 08 Sep 2008) | 9 lines
Modify ast_answer() to not hold the channel lock while calling ast_safe_sleep()
or when calling ast_waitfor(). These are inappropriate times to hold the channel
lock. This is what has caused "could not get the channel lock" messages from
chan_sip and has likely caused a negative impact on performance results of SIP
in Asterisk 1.6. Thanks to file for pointing out this section of code.
(closes issue #13287)
(closes issue #13115)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@141950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r141906 | mmichelson | 2008-09-08 18:00:06 -0500 (Mon, 08 Sep 2008) | 9 lines
Optimization: The only reason we should check member
status is if the queue has a joinempty or a leavewhenempty
setting which could cause the caller to not join the queue
or exit the queue. Prior to this patch, we could potentially
traverse the entire queue's member list for no reason since
even if the members are currently not available in some way
we're going to let the caller join the queue anyway.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@141907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
................
r141810 | mmichelson | 2008-09-08 16:18:49 -0500 (Mon, 08 Sep 2008) | 22 lines
Merged revisions 141809 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r141809 | mmichelson | 2008-09-08 16:10:10 -0500 (Mon, 08 Sep 2008) | 14 lines
Fix pedantic mode of chan_sip to only check the
remote tag of an endpoint once a dialog has
been confirmed. Up until that point, it is possible
and legal for the far-end to send provisional
responses with a different To: tag each time. With
this patch applied, these provisional messages
will not cause a matching problem.
(closes issue #11536)
Reported by: ibc
Patches:
11536v2.patch uploaded by putnopvut (license 60)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@141811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
