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
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.4@141809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
masquerade. This can happen when chan_local is trying to optimize itself out.
If this happens, fail the async goto instead of bursting into flames.
(closes issue #13435)
Reported by: geoff2010
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This has never worked in 1.4, and we decided that it makes no sense to be done here.
There are many distros out there that already have "proper" spec files that can be (re)used.
Closes issue #13113
Closes issue #10950
Closes issue #10952
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141741 65c4cc65-6c06-0410-ace0-fbb531ad65f3
not be DISPOSE'ing of them the same way we do with
other messages.
(closes issue #13414)
Reported by: mthomasslo
Patches:
13414v2.patch uploaded by putnopvut (license 60)
Tested by: mthomasslo
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141267 65c4cc65-6c06-0410-ace0-fbb531ad65f3
caused port 5060 to always be used when dialing
a peer if no explicit port was specified. This
broke the behavior of implicitly using the port
from which the peer registered if no port is
specified. This commit fixes the logic flaw.
(closes issue #13424)
Reported by: mdu113
Patches:
13424.patch uploaded by putnopvut (license 60)
Tested by: mdu113
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: pj
Tested by: murf
(closes issue #13416)
Reported by: yarns
Tested by: murf
If you find this message overly verbose, relax, it's probably
not meant for you. This message is meant for probably only
two people in the whole world: me, or the poor schnook that
has to maintain this code because I'm either dead or unavailable
at the moment.
This fix solves two reports, both having to do with embedding
a function call in a ${} construct. It was tricky because the
funccall syntax has parenthesis () in it. And up till now,
the 'word' token in the flex stuff didn't allow that, because
it would tend to steal the LP and RP tokens. To be truthful,
the "word" token was the trickiest, most unstable thing in
the whole lexer. I was lucky it made this long without complaints.
I had to choose every character in the pattern with extreme
care, and I knew that someday I'd have to revisit it. Well,
the day has come.
So, my brilliant idea (and I'm being modest), was to use the
surrounding ${} construct to make a state machine and capture
everything in it, no matter what it contains. But, I have to now
treat the word token like I did with comments, in that I turn
the whole thing into a state-machine sort of spec, with new
contexts "curlystate", "wordstate", and "brackstate".
Wait a minute, "brackstate"? Yes, well, it didn't take very many
regression tests to point out if I do this for ${} constructs,
I also have to do it with the $[] constructs, too.
I had to create a separate pcbstack2 and pcbstack3 because
these constructs can occur inside macro argument lists, and
when we have two state machines operating on the same structures
we'd get problems otherwise. I guess I could have stopped at
pcbstack2 and had the brackstate stuff share it, but it doesn't
hurt to be safe. So, the pcbpush and pcbpop routines also now
have versions for "2" and "3".
I had to add the {KEYWORD} construct to the initial pattern for
"word", because previously word would match stuff like "default7",
because it was a longer match than the keyword "default". But,
not any more, because the word pattern only matches only one or
two characters now, and it will always lose. So, I made it the
winner again by making an optional match on any of the keywords
before it's normal pattern.
I added another regression test to make sure we don't
lose this in future edits, and had to fix just one regression,
where it no longer reports a 'cascaded' error, which I guess
is a plus.
I've given some thought as to whether to apply these fixes to
1.4 and the 1.6.x releases, vs trunk; I decided to put it in
1.4 because one of the bug reports was against 1.4; and it
is unexpected that AEL cannot handle this situation. It actually
reduced the amount of useless "cascade" error messages that
appeared in the regressions (by one line, ehhem). There is
a possible side-effect in that it does now do more careful
checking of what's in those ${} constructs, as far as matching
parens, and brackets are concerned. Some users may find a an
insidious problem and correct it this way. This should be
exceedingly rare, I hope.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes multiple parking problems:
Crash when executing a park on an extension dialed by AGI due to not returning the proper return code.
Crash when using a builtin feature that was a subset of a enabled dynamic feature.
Crash due to always hanging up the peer despite the fact that the peer was supposed to be parked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@141028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tomaso
Patches:
asterisk-1.6.0-rc2-cdrmemleak.patch uploaded by tomaso (license 564)
I basically spent the day, verifying that this patch
solves the problem, and doesn't hurt in non-problem
cases. Why valgrind did not plainly reveal this leak
absolutely mystifies and stuns me.
Many, many thanks to tomaso for finding and providing the fix.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
something a bit strange. In all cases where we provide
a callback function to ao2_container_alloc, the callback
function would only return 0 or CMP_MATCH. After inspecting
the ao2_callback() code carefully, I found that if you're
only looking for one specific item, then you should return
CMP_MATCH | CMP_STOP. Otherwise, astobj2 will continue
traversing the current bucket until the end searching for
more matches.
In cases like chan_iax2 where in 1.4, all the peers are
shoved into a single bucket, this makes for potentially
terrible performance since the entire bucket will be
traversed even if the peer is one of the first ones come
across in the bucket.
All the changes I have made were for cases where the
callback function defined was passed to ao2_container_alloc
so that calls to ao2_find could find a unique instance
of whatever object was being stored in the container.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140488 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was causing a problem for people who had identically
named mailboxes in separate voicemail contexts.
This commit affects IMAP storage only.
(closes issue #13194)
Reported by: moliveras
Patches:
13194.patch uploaded by putnopvut (license 60)
Tested by: putnopvut, moliveras
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140421 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in a string to Dial(), it is not ignored.
(closes issue #13355)
Reported by: acunningham
Patches:
13355v2.patch uploaded by putnopvut (license 60)
Tested by: acunningham
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in pedantic mode. The problem was that the wrong
tags would be compared depending on the direction
of the call.
(closes issue #13353)
Reported by: flefoll
Patches:
chan_sip.c.br14.139015.patch-refer-pedantic uploaded by flefoll (license 244)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140299 65c4cc65-6c06-0410-ace0-fbb531ad65f3
of a completely unrelated function to determine whether the scheduler should
be run or not. This would have caused the scheduler to not run in cases where
it should have. Also, leave a note about another scheduler issue that needs
to be addressed at some point.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tzafrir
Patches:
dahdi_close.diff uploaded by tzafrir (license 46)
Tested by: tzafrir, jpeeler
This patch fixes closing open file descriptors in the case of an error.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140056 65c4cc65-6c06-0410-ace0-fbb531ad65f3
used here to allow newly scheduled tasks to wake up the scheduler just in case
the new task needs to run sooner than the current wakeup time when the thread
is sleeping. However, there was a race condition such that a newly scheduled
task would not properly wake up the scheduler or affect the wake up period.
The order of execution would have been:
1) Scheduler thread determines wake up time of N ms.
2) Another thread schedules a task and signals the condition, with an
execution time of < N ms.
3) Scheduler thread locks and goes to sleep for N ms.
By moving the sleep time determination to inside the critical section, this
possibility is avoided.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@140051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
