workspace. To signal an error (and no change to the workspace), -1 should be
returned instead.
(closes issue #13340)
Reported by: kryptolus
Patches:
20080827__bug13340__2.diff.txt uploaded by Corydon76 (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@146799 65c4cc65-6c06-0410-ace0-fbb531ad65f3
method, because we need to evaluate the callerid (since that data affects
whether an extension exists).
(closes issue #13343)
Reported by: efutch
Patches:
20080915__bug13343.diff.txt uploaded by Corydon76 (license 14)
Tested by: efutch
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@146711 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@146026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
channels/misdn/isdn_lib.c
* Miscellaneous other fixes from trunk to make merging easier later.
........
r145200 | rmudgett | 2008-09-30 16:00:54 -0500 (Tue, 30 Sep 2008) | 7 lines
* Miscellaneous formatting changes to make v1.4 and trunk
more merge compatible in the mISDN area.
channels/chan_misdn.c
* Eliminated redundant code in cb_events() EVENT_SETUP
........
r144257 | crichter | 2008-09-24 03:42:55 -0500 (Wed, 24 Sep 2008) | 9 lines
improved helptext of misdn_set_opt.
........
r142181 | rmudgett | 2008-09-09 12:30:52 -0500 (Tue, 09 Sep 2008) | 1 line
Cleaned up comment
........
r138738 | rmudgett | 2008-08-18 16:07:28 -0500 (Mon, 18 Aug 2008) | 30 lines
channels/chan_misdn.c
* Made bearer2str() use allowed_bearers_array[]
* Made use the causes.h defines instead of hardcoded numbers.
* Made use Asterisk presentation indicator values if either of the
mISDN presentation or screen options are negative.
* Updated the misdn_set_opt application option descriptions.
* Renamed the awkward Caller ID presentation misdn_set_opt
application option value not_screened to restricted.
Deprecated the not_screened option value.
channels/misdn/isdn_lib.c
* Made use the causes.h defines instead of hardcoded numbers.
* Fixed some spelling errors and typos.
* Added all defined facility code strings to fac2str().
channels/misdn/isdn_lib.h
* Added doxygen comments to struct misdn_bchannel.
channels/misdn/isdn_lib_intern.h
* Added doxygen comments to struct misdn_stack.
channels/misdn_config.c
configs/misdn.conf.sample
* Updated the mISDN presentation and screen parameter descriptions.
doc/misdn.txt (doc/tex/misdn.tex)
* Updated the misdn_set_opt application option descriptions.
* Fixed some spelling errors and typos.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@145293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- 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
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@144924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
does not apply since the "found" pointer is not
passed in to this function. If this is going to
be backported, it needs to be done differently or
a deeper backport needs to be done.
Edit: This commit reverts commit number 144677.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@144758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@144677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: MVF
Tested by: neutrino88, urzedo, murf, thiagofernandes
Many thanks to neutrino88 for this patch, which
solves a problem whereby channels get a CANCEL
request, respond to it properly, but end up
in a hung state, infinitely being rescheduled.
This fix is a bit crude, in that catches the
problem at a rather late phase, but it may
prevent infinite rescheduling problems that
might still arise.
It might have been better to find out why,
in the course of protocol handling, the channel
was not destroyed, but we leave that to
future generations.
Many thanks to urzedo and thiagofernandes for
their work in verifying that the patch code
indeed is being executing, and averting the
problem.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@144420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@144066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
was not getting set in the STMT; it was coming out,
usually, as binary garbage to an mssql server.
These changes fixed the problem. The only thing
I can venture forth as a guess, is that the pointer
is being stored in the interface, not a copy of the
string. Because we ripped the build process into a
subroutine, the timestr became a temp. stack variable,
and between the time the STMT got built and the
time it was executed on the server, the string being
pointed to was damaged. At any rate, even if this
theory is false, and some mechanism was at fault,
this fix worked reliably where it didn't before.
Why this bug didn't bite last week, I have no idea.
This change basically defines the timestr buffer
in the calling function, extending the life of the
buffer to cover both the STMT's building and
processing to the server.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@143964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: mdu113
Patches:
bug13493.diff uploaded by jpeeler (license 325)
Tested by: mdu113
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@143270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #13425)
Reported by: mdu113
Patches:
bug13425.diff uploaded by jpeeler (license 325)
Tested by: mdu113
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@143204 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: rlsutton2
Prevents local channels from playing MOH at each other which was causing ast_generic_bridge to loop much faster.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142927 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@142865 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@142575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@142474 65c4cc65-6c06-0410-ace0-fbb531ad65f3
isn't consistent.
(closes issue #13426)
Reported by: bamby
Patches:
detect_openh323.diff uploaded by bamby (license 430)
(Modified by me to use sed instead of tr)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@142416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@142354 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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.4@142079 65c4cc65-6c06-0410-ace0-fbb531ad65f3
