https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183386 | dvossel | 2009-03-19 14:40:07 -0500 (Thu, 19 Mar 2009) | 6 lines
Cleaning up a few things in detect disconnect patch
Initialized ast_call_feature in detect_disconnect to avoid accessing uninitialized memory. Cleaned up /param tags in features.h. No longer send dynamic features in ast_feature_detect.
issue #11583
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183436 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183126 | dvossel | 2009-03-19 11:15:16 -0500 (Thu, 19 Mar 2009) | 17 lines
Allow disconnect feature before a call is bridged
feature.conf has a disconnect option. By default this option is set to '*', but it could be anything. If a user wishes to disconnect a call before the other side answers, only '*' will work, regardless if the disconnect option is set to something else. This is because features are unavailable until bridging takes place. The default disconnect option, '*', was hardcoded in app_dial, which doesn't make any sense from a user perspective since they may expect it to be something different. This patch allows features to be detected from outside of the bridge, but not operated on. In this case, the disconnect feature can be detected before briding and handled outside of features.c.
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
detect_disconnect.diff uploaded by dvossel (license 671)
Tested by: sobomax, dvossel
Review: http://reviewboard.digium.com/r/195/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@183172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r173211 | jpeeler | 2009-02-03 15:57:01 -0600 (Tue, 03 Feb 2009) | 17 lines
Parking attempts made to one end of a bridge no longer will hang up due to a
parking failure.
Parking attempts made using either one-touch, or doing either a blind or
assisted transfer to the parking extension now keep up the bridge instead of
hanging up the attempted parked party. Normal causes for the parking attempt
to fail includes the specific specified extension (via PARKINGEXTEN) not being
available or if all the parking spaces are currently in use. To avoid having
to reverse a masquerade park_space_reserve was made to provide foresight if
a parking attempt will succeed and if so reserve the parking space.
(closes issue #13494)
Reported by: mdu113
Reviewed by Russell: http://reviewboard.digium.com/r/133/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to be used within the dial app, before a call is bridged.
Many thanks to sobomax for submitting this patch.
Quoting from bug 11582:
"So the goal of the patch was to use the user configured feature code during the
call setup phase. The original ast_feature_interpret() function is not well suited
for this purpose as it uses much call bridge specific data and doesn't separate a
detection of feature from a feature handler call. So a new function ast_feature_detect()
has been extracted off the ast_feature_interpret() function but keeping the original
logic intact except some insignificant changes to locking.
"Having created the ast_feature_detect() function the possibility to use feature detection
in almost any place of the asterisk code. So a call to this function has been added to
wait_for_answer() function of app_dial.so module. This code doesn't call the feature handler
however and uses old call leg disconnect logic to make the changes as small and simple as
possible to prevent unexpected problems. A disconnect feature currently is the only one
supported during call setup as other features as call parking and call transfer don't make much
sense during call setup. However if need in some of the features would arise it is much easier to
implement as the infrastructure changes are already in place with this patch."
I have cleaned up the patch somewhat, and verified that the existing functionality is not
harmed, and that the new functionality works. Terry has committed his stuff, and there were
no conflicts (see 14274).
(closes issue #11583)
Reported by: sobomax
Patches:
patch-apps__app_dial.c uploaded by sobomax (license 359)
patch-include__asterisk__features.h uploaded by sobomax (license 359)
patch-res__res_features.c uploaded by sobomax (license 359)
enable-features-during-call-setup.diff uploaded by sobomax (license 359)
11583.newdiff uploaded by murf (license 17)
enable-features-during-call-setup-1.diff uploaded by sobomax (license 359)
11583.latest-patch uploaded by murf (license 17)
Tested by: sobomax, murf
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
In order to merge this 1.4 patch into trunk,
I had to resolve some conflicts and wait for
Russell to make some changes to res_agi.
I re-ran all the tests; 39 calls in all, and
made fairly careful notes and comparisons: I
don't want this to blow up some aspect of
asterisk; I completely removed the KEEPALIVE
from the pbx.h decls. The first 3 scenarios
involving feature park; feature xfer to 700;
hookflash park to Park() app call all behave
the same, don't appear to leave hung channels,
and no crashes.
........
r166093 | murf | 2008-12-19 15:30:32 -0700 (Fri, 19 Dec 2008) | 131 lines
This merges the masqpark branch into 1.4
These changes eliminate the need for (and use of)
the KEEPALIVE return code in res_features.c;
There are other places that use this result code
for similar purposes at a higher level, these appear
to be left alone in 1.4, but attacked in trunk.
The reason these changes are being made in 1.4, is
that parking ends a channel's life, in some situations,
and the code in the bridge (and some other places),
was not checking the result code properly, and dereferencing
the channel pointer, which could lead to memory corruption
and crashes.
Calling the masq_park function eliminates this danger
in higher levels.
A series of previous commits have replaced some parking calls
with masq_park, but this patch puts them ALL to rest,
(except one, purposely left alone because a masquerade
is done anyway), and gets rid of the code that tests
the KEEPALIVE result, and the NOHANGUP_PEER result codes.
While bug 13820 inspired this work, this patch does
not solve all the problems mentioned there.
I have tested this patch (again) to make sure I have
not introduced regressions.
Crashes that occurred when a parked party hung up
while the parking party was listening to the numbers
of the parking stall being assigned, is eliminated.
These are the cases where parking code may be activated:
1. Feature one touch (eg. *3)
2. Feature blind xfer to parking lot (eg ##700)
3. Run Park() app from dialplan (eg sip xfer to 700)
(eg. dahdi hookflash xfer to 700)
4. Run Park via manager.
The interesting testing cases for parking are:
I. A calls B, A parks B
a. B hangs up while A is getting the numbers announced.
b. B hangs up after A gets the announcement, but
before the parking time expires
c. B waits, time expires, A is redialed,
A answers, B and A are connected, after
which, B hangs up.
d. C picks up B while still in parking lot.
II. A calls B, B parks A
a. A hangs up while B is getting the numbers announced.
b. A hangs up after B gets the announcement, but
before the parking time expires
c. A waits, time expires, B is redialed,
B answers, A and B are connected, after
which, A hangs up.
d. C picks up A while still in parking lot.
Testing this throroughly involves acting all the permutations
of I and II, in situations 1,2,3, and 4.
Since I added a few more changes (ALL references to KEEPALIVE in the bridge
code eliimated (I missed one earlier), I retested
most of the above cases, and no crashes.
H-extension weirdness.
Current h-extension execution is not completely
correct for several of the cases.
For the case where A calls B, and A parks B, the
'h' exten is run on A's channel as soon as the park
is accomplished. This is expected behavior.
But when A calls B, and B parks A, this will be
current behavior:
After B parks A, B is hung up by the system, and
the 'h' (hangup) exten gets run, but the channel
mentioned will be a derivative of A's...
Thus, if A is DAHDI/1, and B is DAHDI/2,
the h-extension will be run on channel
Parked/DAHDI/1-1<ZOMBIE>, and the
start/answer/end info will be those
relating to Channel A.
And, in the case where A is reconnected to
B after the park time expires, when both parties
hang up after the joyful reunion, no h-exten
will be run at all.
In the case where C picks up A from the
parking lot, when either A or C hang up,
the h-exten will be run for the C channel.
CDR's are a separate issue, and not addressed
here.
As to WHY this strange behavior occurs,
the answer lies in the procedure followed
to accomplish handing over the channel
to the parking manager thread. This procedure
is called masquerading. In the process,
a duplicate copy of the channel is created,
and most of the active data is given to the
new copy. The original channel gets its name
changed to XXX<ZOMBIE> and keeps the PBX
information for the sake of the original
thread (preserving its role as a call
originator, if it had this role to begin
with), while the new channel is without
this info and becomes a call target (a
"peer").
In this case, the parking lot manager
thread is handed the new (masqueraded)
channel. It will not run an h-exten
on the channel if it hangs up while
in the parking lot. The h exten will
be run on the original channel instead,
in the original thread, after the bridge
completes.
See bug 13820 for our intentions as
to how to clean up the h exten behavior.
Review: http://reviewboard.digium.com/r/29/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@166665 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@152536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r80573 | russell | 2007-08-23 15:16:41 -0500 (Thu, 23 Aug 2007) | 5 lines
When executing a dynamic feature, don't look it up a second time by digit pattern
after we already looked it up by name. This causes broken behavior if there is
more than one feature defined with the same digit pattern.
(closes issue #10539, reported by bungalow, patch by me)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@80574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
