When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@172517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk runs as a non-root user and the administrator does a 'restart now',
Asterisk loses the ability to set QOS on packets.
(closes issue #14004)
Reported by: nemo
Patches:
20090105__bug14004.diff.txt uploaded by Corydon76 (license 14)
Tested by: Corydon76
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@172438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
situations.
What it does:
1. A new Flag value is defined in include/asterisk/channel.h,
AST_FLAG_BRIDGE_HANGUP_DONT, which used as a messenge to the
bridge hangup exten code not to run the h-exten there (nor
publish the bridge cdr there). It will done at the pbx-loop
level instead.
2. In the manager Redirect code, I set this flag on the channel
if the channel has a non-null pbx pointer. I did the same for the
second (chan2) channel, which gets run if name2 is set...
and the first succeeds.
3. I restored the ending of the cdr for the pbx loop h-exten
running code. Don't know why it was removed in the first place.
4. The first attempt at the fix for this bug was to place code
directly in the async_goto routine, which was called from a
large number of places, and could affect a large number of
cases, so I tested that fix against a fair number of transfer
scenarios, both with and without the patch. In the process,
I saw that putting the fix in async_goto seemed not to affect
any of the blind or attended scenarios, but still, I was
was highly concerned that some other scenarios I had not tested
might be negatively impacted, so I refined the patch to
its current scope, and jmls tested both. In the process, tho,
I saw that blind xfers in one situation, when the one-touch
blind-xfer feature is used by the peer, we got strange
h-exten behavior. So, I inserted code to swap CDRs and
to set the HANGUP_DONT field, to get uniform behavior.
5. I added code to the bridge to obey the HANGUP_DONT flag,
skipping both publishing the bridge CDR, and running
the h-exten; they will be done at the pbx-loop (higher)
level instead.
6. I removed all the debug logs from the patch before committing.
7. I moved the AUTOLOOP set/reset in the h-exten code in res_features
so it's only done if the h-exten is going to be run. A very
minor performance improvement, but technically correct.
(closes issue #14241)
Reported by: jmls
Patches:
14241_redirect_no_bridgeCDR_or_h_exten_via_transfer uploaded by murf (license 17)
Tested by: murf, jmls
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@172030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
removed from a slinfactory
slinfactory used the "samples" field of an ast_frame in order to determine
the amount of data contained within the frame. In certain cases, such as
jitter buffer interpolated frames, the frame would have a non-zero value for
"samples" but have NULL "data"
This caused a problem when a memcpy call in ast_slinfactory_read would attempt
to access invalid memory. The solution in use here is to never feed frames into
the slinfactory if they have NULL "data"
(closes issue #13116)
Reported by: aragon
Patches:
13116.diff uploaded by putnopvut (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@171621 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There was a subtle change in ast_do_masquerade which
resulted in failed attempts to pickup calls. The problem
was that the value of the AST_FLAG_OUTGOING flag was
copied from the clone to the original channel. In the case
of call pickup, this meant that the AST_FLAG_OUTGOING flag
ended up being cleared on the channel that was attempting
to execute the pickup.
Because this flag was not set, when ast_read came across
an answer frame, it ignored it. The result of this was that
the calling channel was never properly answered.
This fix changes the behavior in ast_do_masquerade to set
the flags on the original channel to the union of the flags
on the clone channel. This way, if the AST_FLAG_OUTGOING
flag is set on either of the two channels involved in the
masquerade, the resulting channel will have the flag set
as well.
(closes issue #14206)
Reported by: francesco_r
Patches:
14206.patch uploaded by putnopvut (license 60)
Tested by: francesco_r, aragon, putnopvut
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@170392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The fix for this is to simply set the newly created datastore's data pointer
to NULL if it is inherited but has no duplicate callback.
(closes issue #14113)
Reported by: francesco_r
Patches:
14113.patch uploaded by putnopvut (license 60)
Tested by: francesco_r
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@166568 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: tzafrir
Replace a bunch of if defined checks for Zaptel/DAHDI through several new defines in dahdi_compat.h. This removes a lot of code duplication. Example from bug:
#ifdef HAVE_ZAPTEL
fd = open("/dev/zap/pseudo", O_RDWR);
#else
fd = open("/dev/dahdi/pseudo", O_RDWR);
#endif
is replaced with:
fd = open(DAHDI_FILE_PSEUDO, O_RDRW);
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@165991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch handles some additional cases that could result in partial writes
to the file description. This was done to address complaints about partial
writes on AMI.
(issue #13546) (more changes needed to address potential problems in 1.6)
Reported by: srt
Tested by: russell
Review: http://reviewboard.digium.com/r/99/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@165796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is exiting while holding a lock.
If the last lock attempt was a trylock, and it failed, it will still be in the
list of locks so that it can be reported.
(closes issue #13219)
Reported by: pj
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"module unload" was already identified as a command that can not be used
from the AMI. "restart gracefully" effectively unloads all modules, and will
run in to the same problems.
(closes issue #13894)
Reported by: kernelsensei
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164806 65c4cc65-6c06-0410-ace0-fbb531ad65f3
One issue was that the ast_mutex_* API was being used within the context of the
thread local data destructors. We would go off and allocate more thread local data
while the pthread lib was in the middle of destroying it all. This led to a memory
leak.
Another issue was an invalid argument being provided to the the object_add
API call.
(closes issue #13678)
Reported by: ys
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164736 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue that was reported was about a case where a RINGING channel got
redirected to an extension to pick up a call from parking. Once the parked
call got taken out of parking, it heard silence until the other side answered.
Ideally, the caller that was parked would get a ringing indication. This patch
fixes this case so that the caller receives ringback once it comes out of
parking until the other side answers.
The fixes are:
- Make sure we remember that a channel was an outgoing channel when doing
a masquerade. This prevents an erroneous ast_answer() call on the channel,
which causes a bogus 200 OK to be sent in the case of SIP.
- Add some additional comments to explain related parts of code.
- Update the handling of the ast_channel visible_indication field. Storing
values that are not stateful is pointless. Control frames that are events
or commands should be ignored.
- When a bridge first starts, check to see if the peer channel needs to be
given ringing indication because the calling side is still ringing.
- Rework ast_indicate_data() a bit for the sake of readability.
(closes issue #13747)
Reported by: davidw
Tested by: russell
Review: http://reviewboard.digium.com/r/90/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@164201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pointer inside editline to look back to asterisk.c, so others don't spend
as much time as I did looking (in the wrong place) for the appropriate
function.
Reported by: ZX81, via the #asterisk-users channel
Fixed by: me (license 14)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@163761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These changes come from team/russell/issue_12658
1) Change autoservice to put digits on the head of the channel's frame readq
instead of the tail. If there were frames on the readq that autoservice
had not yet read, the previous code would have resulted in out of order
processing. This required a new API call to queue a frame to the head
of the queue instead of the tail.
2) Change up the processing of DTMF in ast_read(). Some of the problems
were the result of having two sources of pending DTMF frames. There
was the dtmfq and the more generic readq. Both were used for pending
DTMF in various scenarios. Simplifying things to only use the frame
readq avoids some of the problems.
3) Fix a bug where a DTMF END frame could get passed through when it
shouldn't have. If code set END_DTMF_ONLY in the middle of digit emulation,
and a digit arrived before emulation was complete, digits would get
processed out of order.
(closes issue #12658)
Reported by: dimas
Tested by: russell, file
Review: http://reviewboard.digium.com/r/85/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@163448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
is messed up. By intercepting those events with a signal handler in the remote
console, we can avoid those issues.
(closes issue #13464)
Reported by: tzafrir
Patches:
20081110__bug13464.diff.txt uploaded by Corydon76 (license 14)
Tested by: blitzrage
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@163383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The test is not valid. Besides, if we actually suspected that recursive
mutexes were not working, we would get a ton of LOG_ERROR messages when
DEBUG_THREADS is turned on.
(inspired by a discussion on the asterisk-dev list)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@162413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous code carried over group settings from the old channel to the new
one. However, it did nothing with the group settings that were already on the
new channel. This patch removes all group settings that already existed on the
new channel.
I have a more complicated version of this patch which addresses only the most
blatant problem with this, which is that a channel can end up with multiple
group settings in the same category. However, I could not think of a use case
for keeping any of the group settings from the old channel, so I went this route
for now.
(closes AST-152)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@161948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Reported by: matt_b
Tested by: jpeeler
This mirrors a check that was present in ast_rtp_read to also be in ast_rtp_raw_write to not schedule sending the receiver report if the remote RTCP endpoint address isn't present in the RTCP structure.
Closes AST-142.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@161013 65c4cc65-6c06-0410-ace0-fbb531ad65f3
following: "name <number>" (including the quotation marks), then the parts
would be parsed as
name: "name
number: number
This is because the closing quotation mark was not discovered since the number
and everything after was parsed out of the string earlier. Now, there is a check
to see if the closing quote occurs after the number, so that we can know if we
should strip off the opening quote on the name.
Closes AST-158
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@160943 65c4cc65-6c06-0410-ace0-fbb531ad65f3
