https://origsvn.digium.com/svn/asterisk/trunk
........
r157639 | tilghman | 2008-11-18 19:02:45 -0600 (Tue, 18 Nov 2008) | 7 lines
Starting with a change to ensure that ast_verbose() preserves ABI compatibility
in 1.6.1 (as compared to 1.6.0 and versions of 1.4), this change also
deprecates the use of Asterisk with FreeBSD 4, given the central use of va_copy
in core functions. va_copy() is C99, anyway, and we already require C99 for
other purposes, so this isn't really a big change anyway. This change also
simplifies some of the core ast_str_* functions.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157641 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r157632 | mmichelson | 2008-11-18 18:59:48 -0600 (Tue, 18 Nov 2008) | 10 lines
If malloc returns NULL, we need to return NULL immediately or
else Asterisk will crash when attempting to dereference the NULL
pointer
(closes issue #13858)
Reported by: eliel
Patches:
astmm.c.patch uploaded by eliel (license 64)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157636 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r157306 | mmichelson | 2008-11-18 12:31:08 -0600 (Tue, 18 Nov 2008) | 20 lines
Merged revisions 157305 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r157305 | mmichelson | 2008-11-18 12:25:55 -0600 (Tue, 18 Nov 2008) | 12 lines
Fix a crash in the end_bridge_callback of app_dial and
app_followme which would occur at the end of an attended
transfer. The error occurred because we initially stored
a pointer to an ast_channel which then was hung up due
to a masquerade.
This commit adds a "fixup" callback to the bridge_config
structure to allow for end_bridge_callback_data to be
changed in the case that a new channel pointer is needed
for the end_bridge_callback.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r157302 | murf | 2008-11-18 11:07:55 -0700 (Tue, 18 Nov 2008) | 18 lines
(closes issue #13420)
Reported by: alex70
Patches:
13420.13539.patch uploaded by murf (license 17)
Tested by: murf, awk
This fixes two problems: a spurious linefeed insertion
probably left over from pre-precomment times. Only
generated when category had no previous comments.
The other problem: Insertions could get the line-numbering
out of whack and generate negative line numbers, causing
chunks of line numbers to be emitted, on the scale of the
number of lines up to that point in the file. In such cases,
abort the looping, and all is well.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@157304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r156649 | jpeeler | 2008-11-13 13:17:50 -0600 (Thu, 13 Nov 2008) | 6 lines
(closes issue #13891)
Reported by: smurfix
This reverts a change I made in 116297. At the time it seemed the change was required to solve an issue with attempting a transfer but then letting it timeout without dialing any digits. However, I didn't realize that having an empty extension was possible. I'm removing the immediate return that was added in pbx_find_extension if the extension is null.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@156650 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r156299 | murf | 2008-11-12 12:47:29 -0700 (Wed, 12 Nov 2008) | 26 lines
Merged revisions 156297 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156297 | murf | 2008-11-12 12:36:16 -0700 (Wed, 12 Nov 2008) | 18 lines
It turns out that the 0x0XX00 codes being returned for
N, X, and Z are off by one, as per conversation with
jsmith on #asterisk-dev; he was teaching a class
and disconcerted that this published rule was not
being followed, with patterns _NXX, _[1-8]22 and
_[2-9]22... and NXX was winning, but [1-8] should
have been.
This change, tested on these 3 patterns now
picks the proper one.
However, this change may surprise users who
set up dialplans based on previous behavior,
which has been there for what, 2 and half
years or so now.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@156354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r156166 | russell | 2008-11-12 11:38:20 -0600 (Wed, 12 Nov 2008) | 15 lines
Merged revisions 156164 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r156164 | russell | 2008-11-12 11:29:52 -0600 (Wed, 12 Nov 2008) | 7 lines
Move the sanity check that makes sure "always fork" is not set along with the
console option to be after the code that reads options from asterisk.conf.
This resolves a situation where Asterisk can start taking up 100% when
misconfigured.
(Thanks to Bryce Porter (x86 on IRC) for letting me log in to his system to
figure out what was causing the 100% CPU problem.)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@156168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r153181 | twilson | 2008-10-31 13:55:33 -0500 (Fri, 31 Oct 2008) | 5 lines
Recent CDR fixes moved execution of the 'h' exten into the bridging code, so variables that were set after ast_bridge_call was called would not show up in the 'h' exten. Added a callback function to handle setting variables, etc. from w/in the bridging code. Calls back into a nested function within the function calling ast_bridge_call
(closes issue #13793)
Reported by: greenfieldtech
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@153266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
which were committed to trunk in revision 153223. I blocked that
commit from 1.6.1 since it also contained a new feature.
Note to self: Separate commits so that you don't end up with
a situation where part of a commit should be merged but part
should be blocked from stable branches.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@153225 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152536 | murf | 2008-10-28 23:01:00 -0600 (Tue, 28 Oct 2008) | 57 lines
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r151906 | russell | 2008-10-25 06:02:11 -0500 (Sat, 25 Oct 2008) | 16 lines
Merged revisions 151905 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r151905 | russell | 2008-10-25 05:59:02 -0500 (Sat, 25 Oct 2008) | 8 lines
Move AMI initialization to occur after loading modules. This prevents a
deadlock when someone tries to initiate a module reload from the AMI just
as Asterisk is starting.
(closes issue #13778)
Reported by: hotsblanc
Fix suggested by hotsblanc
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151101 | kpfleming | 2008-10-19 22:11:28 +0300 (Sun, 19 Oct 2008) | 13 lines
cleaup of the TCP/TLS socket API:
1) rename 'struct server_args' to 'struct ast_tcptls_session_args', to follow coding guidelines
2) make ast_make_file_from_fd() static and rename it to something that indicates what it really is for (again coding guidelines)
3) rename address variables inside 'struct ast_tcptls_session_args' to be more descriptive (dare i say it... coding guidelines)
4) change ast_tcptls_client_start() to use the new 'remote_address' field of the session args for the destination of the connection, and use the 'local_address' field to bind() the socket to the proper source address, if one is supplied
5) in chan_sip, ensure that we pass in the PP address we are bound to when creating outbound (client) connections, so that our connections will appear from the correct address
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r150817 | bweschke | 2008-10-17 22:18:33 -0400 (Fri, 17 Oct 2008) | 8 lines
Using the GetVar handler in AMI is potentially dangerous (insta-crash [tm]) when you use a dialplan function that requires a channel and then you don't provide one or provide an invalid one in the Channel: parameter. We'll handle this situation exactly the same way it was handled in pbx.c back on r61766.
We'll create a bogus channel for the function call and destroy it when we're done. If we have trouble allocating the bogus channel then we're not going to try executing the function call at all and run the risk of crashing.
(closes issue #13715)
reported by: makoto
patch by: bweschke
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@150829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r150305 | mmichelson | 2008-10-16 18:41:16 -0500 (Thu, 16 Oct 2008) | 14 lines
Merged revisions 150304 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r150304 | mmichelson | 2008-10-16 18:40:54 -0500 (Thu, 16 Oct 2008) | 6 lines
Reverting changes from commits 150298 and 150301 since
I was mistakenly under the assumption that dialplan functions
*always* required that a channel be present. I need to go
home earlier, I think :)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@150306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r150302 | mmichelson | 2008-10-16 18:36:49 -0500 (Thu, 16 Oct 2008) | 24 lines
Merged revisions 150298,150301 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r150298 | mmichelson | 2008-10-16 18:34:37 -0500 (Thu, 16 Oct 2008) | 10 lines
Don't try to call a dialplan function's read callback from
the manager's GetVar handler if an invalid channel has
been specified. Several dialplan functions, including
CHANNEL and SIP_HEADER, do not check for NULL-ness of
the channel being passed in.
(closes issue #13715)
Reported by: makoto
........
r150301 | mmichelson | 2008-10-16 18:35:07 -0500 (Thu, 16 Oct 2008) | 3 lines
And don't forget to return on the error condition
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@150303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r149205 | mmichelson | 2008-10-14 18:04:44 -0500 (Tue, 14 Oct 2008) | 20 lines
Merged revisions 149204 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r149204 | mmichelson | 2008-10-14 18:00:01 -0500 (Tue, 14 Oct 2008) | 12 lines
Add a tolerance period for sync-triggered audiohooks
so that if packetization of audio is close (but not equal)
we don't end up flushing the audiohooks over small
inconsistencies in synchronization.
Related to issue #13005, and solves the issue
for most people who were experiencing the problem.
However, a small number of people are still experiencing
the problem on long calls, so I am not closing
the issue yet
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@149206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r148519 | murf | 2008-10-13 11:14:38 -0600 (Mon, 13 Oct 2008) | 15 lines
Hmmm. Nobody (but me) is interested in seeing
the trie info when they do 'dialplan show ...'
(even with debug set to non-zero); so I set up a
'dialplan debug [context]' cli command instead,
to explicitly show just the trie info. I even
added an extension_exists() call to make sure the
trie info is built. I moved the explanatory header
to above the extension loop to ensure it only prints
once. And it will do this now, whether debug is set
or not.
I removed the trie printing from the 'dialplan show'
command entirely.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@148562 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r148200 | seanbright | 2008-10-09 20:42:13 -0400 (Thu, 09 Oct 2008) | 12 lines
Don't include logger.h in asterisk.h by default as it is causing problems building
app_voicemail. Instead, include it where it is needed. This turned out to be a
relatively minor issue because other headers include logger.h as well.
Need to test -addons before merging this back to 1.6.0.
(closes issue #13605)
Reported by: tomo1657
Patches:
13605_seanbright.diff uploaded by seanbright (license 71)
Tested by: mmichelson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@148240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r148160 | mmichelson | 2008-10-09 18:54:59 -0500 (Thu, 09 Oct 2008) | 14 lines
The priority was unnecessary for the manager atxfer, so it has
been removed. Furthermore, now we actually use the Context argument
passed to set the transfer context and don't error out if no
context is specified.
This addresses the actual problems outlined in issue 12158. Regarding
the other points brought up, regarding the inability to not transfer
to extensions which cannot be represented by DTMF, it is not enough of
a constraint that it is worth attempting to rework the feature.
(closes issue #12158)
Reported by: davidw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@148161 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r148112 | mmichelson | 2008-10-09 18:15:33 -0500 (Thu, 09 Oct 2008) | 26 lines
Merged revisions 146026 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r146026 | murf | 2008-10-03 12:12:54 -0500 (Fri, 03 Oct 2008) | 18 lines
(closes issue #13579)
Reported by: dwagner
(closes issue #13584)
Reported by: dwagner
Tested by: murf, putnopvut
The thought occurred to me that the res= from the extension spawn
was ending up being returned from the bridge.
"Thou shalt not poison the return value". Made the change
and it appears to allow blind xfers to work as normal.
If I'm wrong, reopen the bugs. But it looks good to me!
Many thanks to putnopvut for helping me reproduce this!
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@148115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r147952 | jpeeler | 2008-10-09 14:27:32 -0500 (Thu, 09 Oct 2008) | 6 lines
(closes issue #13139)
Reported by: krisk84
Tested by: krisk84
This change prevents a call that is placed in the parkinglot to be picked up before the PBX is finished. If another extension dials the parking extension before the PBX thread has completed at minimum warnings will occur about the PBX not properly being terminated. At worst, a crash could occur.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@147957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r147807 | murf | 2008-10-09 08:17:33 -0600 (Thu, 09 Oct 2008) | 15 lines
(closes issue #13557)
Reported by: nickpeirson
Patches:
pbx.c.patch uploaded by nickpeirson (license 579)
replace_bzero+bcopy.patch uploaded by nickpeirson (license 579)
Tested by: nickpeirson, murf
1. replaced all refs to bzero and bcopy to memset and memmove instead.
2. added a note to the CODING-GUIDELINES
3. add two macros to asterisk.h to prevent bzero, bcopy from creeping
back into the source
4. removed bzero from configure, configure.ac, autoconfig.h.in
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@147811 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r146883 | jpeeler | 2008-10-06 17:26:25 -0500 (Mon, 06 Oct 2008) | 12 lines
This commit squashes together three commits because the wrong approach was originally used. (One of the commits was only one line.)
1) r143204:
The main change here was to masquerade the channel if the channel that was to be parked was running a PBX on it. The PBX thread can then maintain full control of the channel (the zombie) as it expects to while allowing the parking thread full control of the real (parked) channel.
2) r143270:
Changed park_call_full to hold the parkinglot lock a little longer, which protects the parkeduser struct from being freed out from underneath. Made sure that the parking extension is added to the parking context while holding the lock thereby ensuring that there are no spurious warnings from removal attempts when a hangup occurs while the parking lot is being announced.
3) r143475: (the one liner)
compare peer and chan instead of looking at the parked user (pu), which could have possibly already have been freed by the parking thread
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146886 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r146875 | jpeeler | 2008-10-06 17:03:01 -0500 (Mon, 06 Oct 2008) | 5 lines
Explicitly set args in park_call_exec NULL so in the case of no options being passed in, there
is no garbage attempted to be used. Also, do not set args to unknown value again if there are
no options passed in.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146876 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r146198 | seanbright | 2008-10-03 18:10:18 -0400 (Fri, 03 Oct 2008) | 7 lines
Resolve a subtle bug where we would never successfully be able to get
the first item in the CLI entry list. This was preventing '!' from
showing up in either 'help' or in tab completion.
(closes issue #13578)
Reported by: mvanbaak
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@146200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r145606 | mmichelson | 2008-10-01 17:23:50 -0500 (Wed, 01 Oct 2008) | 11 lines
Okay, this should really do it now. While I did manage
to fix blind transfers with my last commit here, I also
caused an unwanted side-effect. That is, only the first
priority of the 'h' extension would be executed when
a blind transfer occurred instead of all priorities.
Essentially, my last commit corrected the return value
of ast_bridge_call. However, the implementation still
was not 100% correct. Now it is.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@145609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r145553 | mmichelson | 2008-10-01 16:06:26 -0500 (Wed, 01 Oct 2008) | 13 lines
The logic surrounding the return value of ast_spawn_extension
within ast_bridge_call was reversed.
This problem was observed when a blind transfer placed from
the callee channel of a test call failed.
While the problem I am solving here is exactly the same
as what was reported in issue #13584, the difference is
that this fix I am applying is trunk-only. Issue #13584
was reported against the 1.4 branch, and my tests
of 1.4's blind transfers appear to work fine.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@145557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r144949 | kpfleming | 2008-09-27 10:52:56 -0500 (Sat, 27 Sep 2008) | 17 lines
Merged revisions 144924-144925 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144924 | kpfleming | 2008-09-27 10:00:48 -0500 (Sat, 27 Sep 2008) | 6 lines
improve header inclusion process in a few small ways:
- it is no longer necessary to forcibly include asterisk/autoconfig.h; every module already includes asterisk.h as its first header (even before system headers), which serves the same purpose
- astmm.h is now included by asterisk.h when needed, instead of being forced by the Makefile; this means external modules will build properly against installed headers with MALLOC_DEBUG enabled
- simplify the usage of some of these headers in the AEL-related stuff in the utils directory
........
r144925 | kpfleming | 2008-09-27 10:13:30 -0500 (Sat, 27 Sep 2008) | 2 lines
fix some minor issues with rev 144924
........
................
r144950 | kpfleming | 2008-09-27 11:10:33 -0500 (Sat, 27 Sep 2008) | 2 lines
fix bugs caused by r144949 when MALLOC_DEBUG is defined
................
r144951 | kpfleming | 2008-09-27 11:17:43 -0500 (Sat, 27 Sep 2008) | 1 line
remove incorrect comment
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@144993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r144678 | murf | 2008-09-26 11:50:35 -0600 (Fri, 26 Sep 2008) | 20 lines
Merged revisions 144677 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r144677 | murf | 2008-09-26 11:47:13 -0600 (Fri, 26 Sep 2008) | 12 lines
(closes issue #13563)
Reported by: mnicholson
Patches:
found1.diff uploaded by mnicholson (license 96)
This patch was mainly meant to apply to trunk and 1.6.x,
but I'm applying it to 1.4 also, which should be a perfectly
harmless fix to the vast majority of users who are not using
external switches, but the few who might be affected
will not have to go to the pain of filing a bug report.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@144680 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r144569 | murf | 2008-09-25 16:21:28 -0600 (Thu, 25 Sep 2008) | 14 lines
(closes issue #13557)
Reported by: nickpeirson
The user attached a patch, but the license is not yet
recorded. I took the liberty of finding and replacing
ALL index() calls with strchr() calls, and that
involves more than just main/pbx.c;
chan_oss, app_playback, func_cut also had calls
to index(), and I changed them out. 1.4 had no
references to index() at all.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@144578 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.1@144069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
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.1@143349 65c4cc65-6c06-0410-ace0-fbb531ad65f3
