[Home]

Summary:ASTERISK-17264: [patch] [regression] Call Pickup Hangs Asterisk (deadlock?)
Reporter:Michael Shepelev (docent)Labels:
Date Opened:2011-01-21 01:16:03.000-0600Date Closed:2011-05-27 03:38:00
Priority:BlockerRegression?Yes
Status:Closed/CompleteComponents:Features
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 20110301-backtrace-threads.txt
( 1) 20110301-core-show-locks.txt
( 2) 20110302-backtrace-threads.txt
( 3) 20110302-core-show-locks.txt
( 4) 20110303-backtrace-threads.txt
( 5) 20110303-core-show-locks.txt
( 6) ast_do_pickup_1.8_trunk.diff.txt
( 7) bug18654.diff.txt
( 8) bug18654.diff2.txt
( 9) console.log
(10) core_show_locks.txt
(11) full
(12) install
(13) issue18654_v1.4.patch
(14) issue18654_v1.6.2.patch
(15) pickup_lock_2.diff
(16) pickup_lock.diff
(17) pickup_lock3.diff
(18) pickup_lock4.diff
(19) ps.txt
(20) review1232-1.6.2.diff.txt
(21) review1232-1.8.diff.txt
(22) show_locks.txt
(23) sip-call-pickup-trunk.patch
Description:Asterisk stops to service new calls when someone tries to pickup a call by pressing *8. Some existing calls are also terminated, although others continue to work. I still can run any command in the console, but I can't stop or kill Asterisk. I can kill it only with -9 flag.
I found this trouble in versions 1.8.1, 1.8.2 and SVN.
Comments:By: Leif Madsen (lmadsen) 2011-01-21 12:41:40.000-0600

Please provide some information to reproduce this. As the issue currently stands there isn't anything we can do with this.

We'll need console output showing what is going on, along with the relevant configuration information and the exact version you're using so the issue can be reproduced.
By: Leif Madsen (lmadsen) 2011-01-21 12:42:34.000-0600

Does Asterisk actually crash (as you've indicated)? If so, please provide the backtrace per the documentation at https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace
By: Michael Shepelev (docent) 2011-01-21 16:19:33.000-0600

I attached a few files.
With Asterisk 1.8.1 and 1.8.2 I had the same result.
By: Leif Madsen (lmadsen) 2011-01-24 14:00:21.000-0600

OK after reviewing this a couple of times now, it looks like this may be a deadlock.

You're going to need to enable DEBUG_THREADS in the Compiler Flags menu of menuselect, recompile and reinstall Asterisk, then reproduce the issue. After reproducing, then execute 'core show locks' and provide the output of that here.
By: Michael Shepelev (docent) 2011-02-10 12:15:23.000-0600

What about my issue?
By: Stefan Schmidt (schmidts) 2011-02-11 03:36:31.000-0600

hello docent,

Your issue is acknowledged and in queue, please be patient, and we will get to it as time permits and developer resources become available.

regards

stefan
By: carlopires2 (carlopires2) 2011-02-16 14:36:07.000-0600

I confirmed this bug with Asterisk 1.8.2.3. Is there any workaround to make pickup to work ?
By: Francesco Romano (francesco_r) 2011-02-17 09:29:05.000-0600

I have upgraded today from 1.6.2.16 to 1.8.3-rc3 released yesterday and i bump into the same bug. This is a basic feature and for me is a big regression, in this manner Asterisk is unusable.
Downgraded to 1.6.2.
By: carlopires2 (carlopires2) 2011-02-18 04:40:37.000-0600

As workaround I had to create my own pickup extension using PickupChan to use 1.8.2.3 because I want gtalk_chan.
By: Leif Madsen (lmadsen) 2011-03-03 14:35:17.000-0600

For anyone who may look at this, the duplicate issue associated with this one also contains good debug information.
By: Amilcar S Silvestre (amilcar) 2011-03-03 21:19:09.000-0600

Since issue 0018906 was closed as duplicate, i'm reposting here debug information for this bug.

I get a deadlock everytime we use *8 to pickup a call, always reproducible. The deadlock freezes asterisk until restart. Attached are the debug info. (Debug info attached are to distincts deadlocks of this same problem.)
By: Amilcar S Silvestre (amilcar) 2011-03-03 21:32:43.000-0600

The deadlock only occurs using *8 from res_features. If you use Pickup() dialplan application, everything works fine.

So, setting "pickupexten = *8" on general session of features.conf, when you pickup a call, asterisk deadlocks. Commenting out "pickupexten = *8" from features.conf and using "exten => *8,1,Pickup()" on the dialplan, pickup works fine.
By: A. Iglesias (arcanos) 2011-03-04 07:08:07.000-0600

We have 1.8.4-rc2 installed, and pickup works fine. I've tried features.conf code (in our case is 72) and PickUpChan, and it works.
By: SplatNIX (uxbod) 2011-03-08 09:49:52.000-0600

We upgraded the other day to 1.8.2.3 and are seeing the same issue. When the client attempts a call pick up we see in messages:

[Mar  8 09:20:40] NOTICE[28904] app_directed_pickup.c: No target channel found for 613

at that point Asterisk segfaults and restarts.

I have checked features.conf and pickupexten is already commented out and we use in the dialplan:

; Enable call pickup for hinted stations from any possible source contexts
exten => _*8XXX,1,Pickup(${EXTEN:2}@a1pub&${EXTEN:2}@a1a&${EXTEN:2}@a1b)

Very hesitate to upgrade to 1.8.4-rc2 and if we downgrade we hit another issue that causes a restart :( Its looking like we may need to drop back to 1.6 branch; double :(
By: Francesco Romano (francesco_r) 2011-03-11 15:37:03.000-0600

Another person reported today issues with pickup on ASTERISK-1870955.
I hope that someone of Digium staff is working on this...
Pickup is such a basic feature and this bug is 100% reproducible with one simple step: *8!
By: Amilcar S Silvestre (amilcar) 2011-03-11 16:02:57.000-0600

I'm available to provide any other informations needed.
By: Isis Fnord (isis242) 2011-04-05 19:50:19

This affects me on 1.8.1.1, seems like a very serious bug.
By: Leif Madsen (lmadsen) 2011-04-07 11:01:37

I can confirm this issue as I ran into it the other day at a customers site.
By: Leif Madsen (lmadsen) 2011-04-07 11:04:01

BTW: I was using 1.8.3.2, and not 1.8.4-rc2 which some other reporter states works. Can someone who had this issue on 1.8.3 or earlier test it on 1.8.4-rc2 and let me know if it fails on that version as well?
By: Francesco Romano (francesco_r) 2011-04-07 12:29:39

I have now compiled the latest SVN-branch-1.8-r313048, tested the pickup but asterisk deadlocked immediately...
By: Alec Davis (alecdavis) 2011-04-08 04:47:31

bug18654.diff.txt

fix 2 problems in ast_pickup_call
1). don't try to play the pickupsound to the ringing channel, playit to the channel trying to pickup the call.
2). play the pickupsound before masquerade, not after.

<u>Or to work around the issue</u>
inital findings with SVN-trunk-r313049M the deadlock between masquerade and stopstream

disable pickup sounds in features.conf

;pickupsound = beep             ; to indicate a successful pickup (default: no sound)
;pickupfailsound = beeperr


By: Francesco Romano (francesco_r) 2011-04-08 05:32:54

I tried the attached patch and now asterisk works well. Thank you.
By: Isis Fnord (isis242) 2011-04-08 11:06:02

"disable pickup sounds in features.conf

;pickupsound = beep ; to indicate a successful pickup (default: no sound)
;pickupfailsound = beeper"

I disabled pickupsound and pickupfailsound in features.conf and I can now pickup a call with *8 without crashing asterisk.
By: Gregory Hinton Nietsky (irroot) 2011-04-10 10:47:58

First i must confess the locks i posted is for my patchset app_directed_pickup where i run a macro once bridged this is a lock nightmare but im getting there.

effectivly i have copied [unashamedly] code from features.c to app_directed_pickup.

that disclaimer out the way the problem im having is the same as above ive posted a patch the moves the race condition locking and checking order.

rather check the channel for need to masquerade [race] before locking the channels container and deadlocking the competing thread ...

the race condition avoidence seems borked IMHO ...
By: Gregory Hinton Nietsky (irroot) 2011-04-11 02:43:38

here is a new approach that should be more correct escape if i am  locked this will be run again ... or most likely im already here "race"
By: A.Rymkus (rymkus) 2011-04-11 09:14:51

Got this trouble too. My configuration is FreeBSD 8.1-STABLE, asterisk 1.8.3.2 from ports, as well as 1.8.0 (from ports also).
In my configuration peers are allowed to use only g711a and g711u codecs.
The only noticeable messages on console was bunch of messages like can't convert beep.gsm to existing codec.
There was no deadlocks or system locks, asterisk just were ending with message "Asterisk ended (0)"
I fixed this trouble initially by disabling call pickup in group and allowing only directed pickup from queue. But after all, I tried to convert beep.gsm to alaw and ulaw format, and enabled group pickup back - it worked.
Quote from my dialplan regarding pickups:
exten => *,1,PickUP(queue-number)
exten => *,2,PickUP()

UPD: no, sorry, convertation doesn't fixed it. Disabling that sounds in features.conf fixed the problem.


By: Amilcar S Silvestre (amilcar) 2011-04-11 14:00:16

alecdavis: confirmed in all my tests that bug18654.diff.txt fixes the problem (using pickupsound).
By: Leif Madsen (lmadsen) 2011-04-11 14:53:14

irroot: how is 19091 related here?
By: Gregory Hinton Nietsky (irroot) 2011-04-12 00:11:48

@lmadsen deadlock avoidance in ao2_callback ASTERISK-17666 the reviewboard link https://reviewboard.asterisk.org/r/1166/ has both proposed patches in one patch set its linked on RB.
By: Alec Davis (alecdavis) 2011-04-12 06:01:27

irroot: The patch I provided in ~133534 bug18654.diff.txt specfically adresses Docent's core-show-locks.txt uploaded on 24 Jan 2011.

I can reproduce the same deadlock as Docent 100% of the time, as I'm sure any user that enables pickupsounds can.

The common problem here is when features.conf has pickupsounds enabled see ~133534, <u>DISABLED is the default, so many would not see this bug</u>.
Of the reports where ast_stopstream was involved in the deadlock, bug18654.diff.txt seems to be the fix, or they disabled the pickupsounds thus avoided the bug.


irroot: Do you have pickupsounds enabled in features.conf?
Your patch seems to fix another issue when using the *8 pickup feature code.


By: Gregory Hinton Nietsky (irroot) 2011-04-13 10:02:30

@alecdavis indeed and the patch i proposed fixes the "other" lockup ... im putting up a fix to your problem that should be applied alongside the pickup sound patch as it does not address the underlying problem.

the lock path is probable under other cercumstances
By: Gregory Hinton Nietsky (irroot) 2011-04-13 10:02:39

@alecdavis indeed and the patch i proposed fixes the "other" lockup ... im putting up a fix to your problem that should be applied alongside the pickup sound patch as it does not address the underlying problem.

the lock path is probable under other cercumstances
By: Alec Davis (alecdavis) 2011-04-14 06:23:12

All the above notes are with SIP-A to SIP-B, with SIP-C sucessfully pickup SIP-B.
with patch bug18654.diff.txt applied.

But using with DAHDI FXS ports, mixed results.
Works: SIP-A to SIP-B, with DAHDI-C sucessfully pickup SIP-B
Works: DAHDI-A to SIP-B, with SIP-C sucessfully pickup SIP-B
Works: DAHDI-A to DAHDI-B, with SIP-A sucessfully pickup DAHDI-B
Works: DAHDI-A to DAHDI-B, with DAHDI-C sucessfully pickup DAHDI-B

Fails: SIP-A to DAHDI-B, with DAHDI-C attempt to pickup DAHDI-B.
 DAHDI-B stops ringing, the pickup beep plays to DAHDI-C but SIP-A keeps ringing.
 When SIP-A hangs up, DAHDI-C then gets diconnected beeps.


By: Brett Bryant (bbryant) 2011-04-14 13:15:03

This issue was reported to us by a customer as well, so I've been working on a seperate patch before being aware of this thread. If you could, test my patch (sip-call-pickup-trunk.patch) and let me know if your results are better or worse.
By: Alec Davis (alecdavis) 2011-04-14 15:07:03

bbryant: make sure you test with the pickupsounds enabled.

I saw your review, and applied the unlock parts in chan_sip.c, buit missed the INV-COMPLETE move.

But it still the same, fails sip-a to dahdi-b with dahdi-c attempt to pickup dahdi-b
By: Alec Davis (alecdavis) 2011-04-15 04:34:20

testing with SVN-trunk-r313822M checked out tonight.

bbryant:
applied only sip-call-pickup-trunk.patch.
No lockups, beep is heard. BUT can still only pickup from the same places as in ~133751. IE. Still fails sip-a to dahdi-b with dahdi-c attempt to pickup dahdi-b


reverted to no patch and lockup still exists.
=== ---> Waiting for Lock #2 (file.c): MUTEX 127 ast_stopstream tmp 0xaf8573c8 (1)
By: Gregory Hinton Nietsky (irroot) 2011-04-15 04:48:01

@alecdavis @bbryant's patch is sip specific and eliminates the root of the problem in SIP the patch i put in will cure the symptom and not the cause thx for testing ....
By: Alec Davis (alecdavis) 2011-04-15 04:55:16

irroot: 4 of patches are from you, which one are you referring to?
By: Gregory Hinton Nietsky (irroot) 2011-04-15 05:46:13

the last one does some deadlock avoidance to side step the problem on masq.
By: Alec Davis (alecdavis) 2011-04-17 04:19:49

bug18654.diff2.txt
fixes the sip-a to dahdi-b with dahdi-c attempt to pickup dahdi-b

taking inspiration from app_directed_pickup.c where all of the pickup routines keep the target locked until just before the unref<pre>
 if ((target = ast_channel_callback(find_by_mark, NULL, (char *) mark, 0))) {
   ast_channel_lock(target);
   res = pickup_do(chan, target);
   ast_channel_unlock(target);
   target = ast_channel_unref(target);
 }
 return res;
</pre>


By: Alec Davis (alecdavis) 2011-04-18 20:36:24

big bold move: https://reviewboard.asterisk.org/r/1185/

move pickup_do() from app_directed_pickup to the core.
create ast_do_pickup() in core.

Then all pickup methods pickup_by_mark pickup_by_exten etc call the common core ast_do_pickup().

ast_pickup_call also refactored in the same format as the other pickup methods from app_directed_pickup.c

Note: fixes every thing I have tested.
By: Alec Davis (alecdavis) 2011-04-18 22:53:25

In ast_pickup_call() from 1.4 res/res_features.c and in 1.6.2 main/features.c, the unlock(cur) is after the ast_channel_masquerade and ast_stream_and_wait.

In 1.8 and trunk the unlock is before everything, allowing masquerading to cause havoc!

After extensive testing, I'm convinced bug18654.diff2.txt and sip-call-pickup-trunk.patch are the correct fixes for this bug.


By: A.Rymkus (rymkus) 2011-04-22 01:21:50

was resolution of this issue added into 1.8.3.3?
By: Alec Davis (alecdavis) 2011-04-22 01:33:43

rymkus: sip-call-pickup-trunk.patch is still required, it hasn't yet been reviewed.
By: A.Rymkus (rymkus) 2011-04-22 02:57:18

alecdavis: thanks
By: Leif Madsen (lmadsen) 2011-04-26 07:53:56

rymkus: you can help yourself by looking at the ChangeLogs and summary files supplied with every release.

(Asterisk 1.8.3.3 was a security release and would have contained no additional bug fixes.)
By: Alec Davis (alecdavis) 2011-04-26 13:40:28

added reviewboardlink.

Which cleans up most issues regarding a pickup.
By: Alec Davis (alecdavis) 2011-04-29 15:24:48

ast_do_pickup_diff7.txt a copy of the latest from reviewboard link.
https://reviewboard.asterisk.org/r/1185/

I have exhaustivly tested this, but need testers and the review needs revewing and a SHIP-IT.

It has debug messages in it for confidence checking. They will be removed when commited.

affects: 1.8svn, trunk and any 1.8tag release.
By: Ronald Chan (loloski) 2011-05-01 11:42:43

I have test this and this appears to work correctly! thanks alec
By: Alec Davis (alecdavis) 2011-05-04 05:48:08

ast_do_pickup.diff8.txt

Additional fine tuning, in the situation where 2 callers try to pickup the same call, previously the failed pickup you hear the errorbeep after the winner had heard the success beep. Had the pickupsound been tt-weasels, the pickupfailsound would take some 2-3 seconds before it was played.

Example below is using the *8 pickup feature code.
Now they play in parallel, well < 1mS apart.<pre>[2011-05-04 22:30:36.059702] DEBUG[2689] features.c: pickup attempt by SIP/gxp824-00000013
[2011-05-04 22:30:36.059945] DEBUG[2689] features.c: Call pickup on 'SIP/gxp823-00000012' by 'SIP/gxp824-00000013'

[2011-05-04 22:30:36.120047] DEBUG[2800] features.c: pickup attempt by DAHDI/33-1
[2011-05-04 22:30:36.141294] DEBUG[2689] channel.c: Planning to masquerade channel SIP/gxp824-00000013 into the structure of SIP/gxp823-00000012
[2011-05-04 22:30:36.141438] DEBUG[2689] channel.c: Done planning to masquerade channel SIP/gxp824-00000013 into the structure of SIP/gxp823-00000012
[2011-05-04 22:30:36.141607] DEBUG[2799] channel.c: Actually Masquerading SIP/gxp824-00000013(6) into the structure of SIP/gxp823-00000012(5)

[2011-05-04 22:30:36.144401] DEBUG[2799] channel.c: Done Masquerading SIP/gxp824-00000013 (6)
[2011-05-04 22:30:36.144668] VERBOSE[2799] app_dial.c:     -- SIP/gxp824-00000013 answered SIP/gxp822-00000011
[2011-05-04 22:30:36.145129] DEBUG[2800] features.c: No call pickup possible... for DAHDI/33-1

[2011-05-04 22:30:36.148954] DEBUG[2800] channel.c: Scheduling timer at (50 requested / 50 actual) timer ticks per second
[2011-05-04 22:30:36.149069] DEBUG[2799] chan_sip.c: ** Our prefcodec: (nothing)
<b><u>[2011-05-04 22:30:36.149323]</u></b> VERBOSE[2800] file.c:     -- <DAHDI/33-1> Playing 'beeperr.gsm' (language 'en')
[2011-05-04 22:30:36.149125] DEBUG[2689] channel.c: Scheduling timer at (50 requested / 50 actual) timer ticks per second
<b><u>[2011-05-04 22:30:36.150070]</u></b> VERBOSE[2689] file.c:     -- <SIP/gxp824-00000013> Playing 'beep.gsm' (language 'en')</pre>


By: Alec Davis (alecdavis) 2011-05-04 06:16:05

Has all of this been worth it.
Just for fun, had to remind myself what happens if only the chan_sip.c code is implemented (which avoids deadlock).
When 2 keen office workers both try to pickup the ringing phone across the office using *8 with Asterisk SVN-trunk-r316584M  ----  SEGFAULT!

Worth it! Check the debug log below, masquerading into a channel thats a ZOMBIE ????

[2011-05-04 23:07:06.500837] DEBUG[4460] features.c: Call pickup on chan 'SIP/gxp823-00000009<ZOMBIE>' by 'DAHDI/33-1'
[2011-05-04 23:07:06.501024] DEBUG[4460] chan_dahdi.c: Requested indication 22 on channel DAHDI/33-1
[2011-05-04 23:07:06.501310] DEBUG[4460] chan_dahdi.c: Requested indication -1 on channel DAHDI/33-1
[2011-05-04 23:07:06.501450] DEBUG[4460] channel.c: Planning to masquerade channel DAHDI/33-1 into the structure of SIP/gxp823-00000009<ZOMBIE>
[2011-05-04 23:07:06.501587] DEBUG[4460] channel.c: Done planning to masquerade channel DAHDI/33-1 into the structure of SIP/gxp823-00000009<ZOMBIE>

end of debug log, phone all dead. asterisk died.


By: Leif Madsen (lmadsen) 2011-05-10 15:34:49

This is probably a blocker for 1.6.2 as well since I just saw an open issue about it opened against 1.6.2.17.2. Please confirm.
By: A.Rymkus (rymkus) 2011-05-11 01:49:19

I applied patch from reviewboard and it fixed problem!
Thanks!

*CLI> core show uptime
System uptime: 4 days, 19 hours, 59 minutes, 14 seconds
Last reload: 1 day, 1 minute, 4 seconds


By: Alec Davis (alecdavis) 2011-05-11 06:55:15

ast_do_pickup.diff12.txt

applies clean to 1.8svn and trunk. 1.6.2 may take some effort.

latest from reviewboard, after a couple of peer reviews.
By: Leif Madsen (lmadsen) 2011-05-11 10:12:43

Before we close this, we should double this issue: https://issues.asterisk.org/view.php?id=19125
By: Alec Davis (alecdavis) 2011-05-12 04:09:43

yuck: all the channels may need the same treatment as has worked for CHAN_SIP.

Block/Stall verifed with 3 DAHDI FXS extensions.
SIP dials DAHDI A, DAHDI B and DAHDI C both try to pickup DAHDI A.

To highlight the issue, set in features.conf
pickupexten = *8
pickupsound = tt-somethingwrong
pickupfailsound = beeperr

Not necessarily a deadlock, but a block while the winning pickupsound is played out, only when that is finished, does the pickupfailsound play out.

channels/chan_dahdi.c:   if (ast_pickup_call(chan)) {
channels/chan_vpb.cc:    if (ast_pickup_call(c)) {
channels/chan_sip.c:     if (ast_pickup_call(chan)) {
channels/chan_misdn.c:   if (ast_pickup_call(ch->ast)) {
channels/chan_misdn.c:   if (ast_pickup_call(chan)) {
channels/chan_mgcp.c:    if (ast_pickup_call(chan)) {
channels/sig_analog.c:   if (ast_pickup_call(chan)) {
By: Richard Mudgett (rmudgett) 2011-05-12 10:16:18

alec:
I don't think that is something to really worry about.  Who needs to listen to a long file to pickup every call?  Try tt-monkeys for a longer file and the deadlock detection debug code will holler every 5 seconds about a possible deadlock.
By: Richard Mudgett (rmudgett) 2011-05-12 16:20:54

The issue18654_v1.6.2.patch is a backport to v1.6.2 of the current patch on reviewboard.
By: Alec Davis (alecdavis) 2011-05-12 17:31:58

ast_do_pickup_1.8_trunk.diff.txt

Last changes before commit from reviewboard link
By: Digium Subversion (svnbot) 2011-05-12 17:52:10

Repository: asterisk
Revision: 318671

U   branches/1.8/apps/app_directed_pickup.c
U   branches/1.8/channels/chan_sip.c
U   branches/1.8/include/asterisk/features.h
U   branches/1.8/main/features.c

------------------------------------------------------------------------
r318671 | alecdavis | 2011-05-12 17:52:10 -0500 (Thu, 12 May 2011) | 30 lines

Fix directed group pickup feature code *8 with pickupsounds enabled

Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.

1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.

Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.

Moved app_directed:pickup_do() to features:ast_do_pickup().

Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
  pickup_by_channel()
  pickup_by_exten()
  pickup_by_mark()
  pickup_by_part()
features.c:
  ast_pickup_call()

(closes issue ASTERISK-17264)
Reported by: Docent
Patches:
     ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett

Review: https://reviewboard.asterisk.org/r/1185/


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=318671
By: Digium Subversion (svnbot) 2011-05-12 17:56:45

Repository: asterisk
Revision: 318672

_U  trunk/
U   trunk/apps/app_directed_pickup.c
U   trunk/channels/chan_sip.c
U   trunk/include/asterisk/features.h
U   trunk/main/features.c

------------------------------------------------------------------------
r318672 | alecdavis | 2011-05-12 17:56:45 -0500 (Thu, 12 May 2011) | 36 lines

Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
 
 Fix directed group pickup feature code *8 with pickupsounds enabled
 
 Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
 
 1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
 2). dialplan applications for directed_pickups shouldn't beep.
 3). feature code for directed pickup should beep on success/failure if configured.
 
 Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
 
 Moved app_directed:pickup_do() to features:ast_do_pickup().
 
 Functions below, all now use the new ast_do_pickup()
 app_directed_pickup.c:
    pickup_by_channel()
    pickup_by_exten()
    pickup_by_mark()
    pickup_by_part()
 features.c:
    ast_pickup_call()
 
 (closes issue ASTERISK-17264)
 Reported by: Docent
 Patches:
       ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
 Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
 
 Review: https://reviewboard.asterisk.org/r/1185/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=318672
By: Alec Davis (alecdavis) 2011-05-12 18:00:57

oops, didn't mean to close, 1.6.2 and 1.4 backports yet to be commited.

By: Richard Mudgett (rmudgett) 2011-05-12 19:06:03

The issue18654_v1.4.patch is a backport to v1.4 of the current patch on reviewboard.

The applicable fixes for v1.4 is the deadlock and the in progress masquerade check for multiple parties trying to pickup the same call.
By: Digium Subversion (svnbot) 2011-05-12 20:09:41

Repository: asterisk
Revision: 318734

U   branches/1.4/apps/app_directed_pickup.c
U   branches/1.4/channels/chan_sip.c
U   branches/1.4/res/res_features.c

------------------------------------------------------------------------
r318734 | rmudgett | 2011-05-12 20:09:41 -0500 (Thu, 12 May 2011) | 43 lines

Merged revisions 318671 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

* The applicable fixes for v1.4 are the SIP deadlock and the in progress
masquerade check for multiple parties trying to pickup the same call.
     issue18654_v1.4.patch uploaded by rmudgett (license 664)

* Backported to v1.6.2.
     issue18654_v1.6.2.patch uploaded by rmudgett (license 664)

........
 r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines

 Fix directed group pickup feature code *8 with pickupsounds enabled

 Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.

 1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
 2). dialplan applications for directed_pickups shouldn't beep.
 3). feature code for directed pickup should beep on success/failure if configured.

 Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.

 Moved app_directed:pickup_do() to features:ast_do_pickup().

 Functions below, all now use the new ast_do_pickup()
 app_directed_pickup.c:
    pickup_by_channel()
    pickup_by_exten()
    pickup_by_mark()
    pickup_by_part()
 features.c:
    ast_pickup_call()

 (closes issue ASTERISK-17264)
 Reported by: Docent
 Patches:
       ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
 Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett

 Review: https://reviewboard.asterisk.org/r/1185/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=318734
By: Digium Subversion (svnbot) 2011-05-12 20:14:29

Repository: asterisk
Revision: 318735

_U  branches/1.6.2/
U   branches/1.6.2/apps/app_directed_pickup.c
U   branches/1.6.2/channels/chan_sip.c
U   branches/1.6.2/include/asterisk/features.h
U   branches/1.6.2/main/features.c

------------------------------------------------------------------------
r318735 | rmudgett | 2011-05-12 20:14:29 -0500 (Thu, 12 May 2011) | 50 lines

Merged revisions 318734 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4

................
 r318734 | rmudgett | 2011-05-12 20:09:40 -0500 (Thu, 12 May 2011) | 43 lines
 
 Merged revisions 318671 via svnmerge from
 https://origsvn.digium.com/svn/asterisk/branches/1.8
 
 * The applicable fixes for v1.4 are the SIP deadlock and the in progress
 masquerade check for multiple parties trying to pickup the same call.
       issue18654_v1.4.patch uploaded by rmudgett (license 664)
 
 * Backported to v1.6.2.
       issue18654_v1.6.2.patch uploaded by rmudgett (license 664)
 
 ........
   r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
 
   Fix directed group pickup feature code *8 with pickupsounds enabled
 
   Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
 
   1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
   2). dialplan applications for directed_pickups shouldn't beep.
   3). feature code for directed pickup should beep on success/failure if configured.
 
   Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
 
   Moved app_directed:pickup_do() to features:ast_do_pickup().
 
   Functions below, all now use the new ast_do_pickup()
   app_directed_pickup.c:
      pickup_by_channel()
      pickup_by_exten()
      pickup_by_mark()
      pickup_by_part()
   features.c:
      ast_pickup_call()
 
   (closes issue ASTERISK-17264)
   Reported by: Docent
   Patches:
         ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
   Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
 
   Review: https://reviewboard.asterisk.org/r/1185/
 ........
................

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=318735
By: Alec Davis (alecdavis) 2011-05-27 02:59:40

additional fixes from https://reviewboard.asterisk.org/r/1232/
review1232-1.6.2.diff.txt
review1232-1.8.diff.txt

If pickupsounds were enabled, asterisk locked during the period of time that the pickup sound played, although short for a beep. just shouldn't have been that way.

The 'target' channel lock around the ast_stream_and_wait(target, pickupsound, ""); causes the lock.

The reason for the lock was 2 threads were trying to write to the caller chan and were choppy and other issues.

The fix, to move the playout of the successful pickupsound from the sip_pickup_thread into the bridge, using the BRIDGE_PLAY_SOUND option, as used by attended transfer.


By: Digium Subversion (svnbot) 2011-05-27 03:24:33

Repository: asterisk
Revision: 321210

U   branches/1.6.2/main/features.c

------------------------------------------------------------------------
r321210 | alecdavis | 2011-05-27 03:24:33 -0500 (Fri, 27 May 2011) | 16 lines

Fix *8 directed pickup locks system during pickupsound play out

move playout from sip_pickup_thread to bridge using BRIDGE_PLAY_SOUND method,
This stop the clash of 2 threads trying to write audio to same channel.
In addition fixes choppy audio beep in issue 19177.

(issue ASTERISK-17264)
(issue ASTERISK-17748)
Reported by: Docent
Patches:
     review1232-1.6.2.diff.txt uploaded by alecdavis (license 585)
Tested by: alecdavis

Review: https://reviewboard.asterisk.org/r/1232/


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=321210
By: Digium Subversion (svnbot) 2011-05-27 03:31:16

Repository: asterisk
Revision: 321211

U   branches/1.8/main/features.c

------------------------------------------------------------------------
r321211 | alecdavis | 2011-05-27 03:31:15 -0500 (Fri, 27 May 2011) | 16 lines

Fix *8 directed pickup locks system during pickupsound play out

move playout from sip_pickup_thread to bridge using BRIDGE_PLAY_SOUND method,
This stop the clash of 2 threads trying to write audio to same channel.
In addition fixes choppy audio beep in issue 19177.

(issue ASTERISK-17264)
(issue ASTERISK-17748)
Reported by: Docent
Patches:
     review1232-1.88888888 alecdavis (license 585)
Tested by: alecdavis

Review: https://reviewboard.asterisk.org/r/1232/


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=321211
By: Digium Subversion (svnbot) 2011-05-27 03:38:00

Repository: asterisk
Revision: 321212

_U  trunk/
U   trunk/main/features.c

------------------------------------------------------------------------
r321212 | alecdavis | 2011-05-27 03:38:00 -0500 (Fri, 27 May 2011) | 22 lines

Merged revisions 321211 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r321211 | alecdavis | 2011-05-27 20:31:15 +1200 (Fri, 27 May 2011) | 16 lines
 
 Fix *8 directed pickup locks system during pickupsound play out
 
 move playout from sip_pickup_thread to bridge using BRIDGE_PLAY_SOUND method,
 This stop the clash of 2 threads trying to write audio to same channel.
 In addition fixes choppy audio beep in issue 19177.
 
  (issue ASTERISK-17264)
  (issue ASTERISK-17748)
  Reported by: Docent
  Patches:
       review1232-1.8.diff.txt alecdavis (license 585)
  Tested by: alecdavis
 
 Review: https://reviewboard.asterisk.org/r/1232/
........

------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=321212