Summary:	ASTERISK-13333: Can't pickup using *8 after updating asterisk to 1.4.23-rc3
Reporter:	Francesco Romano (francesco_r)	Labels:
Date Opened:	2009-01-10 08:53:02.000-0600	Date Closed:	2009-01-23 09:50:38.000-0600
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/PBX
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) 14206.patch ( 1) asteriskcligrouppickup.txt ( 2) full.txt ( 3) ngrep_sip_trace_group_pickup.txt
Description:	I have updated a 1.4.22 installation to 1.4.23-rc3 and now i can't pickup using the default value *8. If 553 call SIP/552 and SIP/551 pickup with *8, 551 hear 553 but 552 keep ringing and 553 continue to listen the ringing. In my case 553 is an ISDN phone but is the same with pure SIP environment. And in the setup there is no NAT or external router. All is in the same lan. I have attached a full debug with sip debug and history enabled.
Comments:	By: Leif Madsen (lmadsen) 2009-01-13 12:29:50.000-0600 Assigning to otherwiseguy to take a look at this. By: Leif Madsen (lmadsen) 2009-01-13 12:32:25.000-0600 Quick question for francesco_r:  can you make sure your 'featuredigittimeout' in features.conf is set to something like 2000? By: Leif Madsen (lmadsen) 2009-01-13 12:33:02.000-0600 Actually after re-reading your description, that would have no effect on your issue. Sorry for the noise. By: Martin Vit (festr) 2009-01-14 18:49:54.000-0600 First I'm very sorry to make my duplicate bug(I missed this). I've problem with pickup on mISDN too (just look at http://bugs.digium.com/view.php?id=14240) It starts with revision 164201 (I've tested it) which comes from this bug http://bugs.digium.com/view.php?id=13747 and it was revised here: http://reviewboard.digium.com/r/90/ I think you should reassign this to rusell because he is creator of patch for bug ASTERISK-12930 By: Francesco Romano (francesco_r) 2009-01-19 15:36:30.000-0600 Any news on this bug? I have retested also the latest 1.4.23-rc4 but the issue is still here. I hope that this basic feature will works again for the final 1.4.23. By: Terry Wilson (twilson) 2009-01-19 15:41:57.000-0600 francesco_r: Sorry, I've been held up working on a parking bug.  This one is next on my list. By: Terry Wilson (twilson) 2009-01-19 16:27:11.000-0600 francesco_r: I just tried with rc4.  SIP/6001 calls SIP/6003.  SIP/6002 dials "*8".  SIP/6002 is bridged with SIP/6001 and I have two-way audio.  hmm... By: Martin Vit (festr) 2009-01-20 05:27:46.000-0600 otherwiseguy: this is not about SIP-SIP pickups but mISDN -> SIP pickup. I've the same issue describe in this duplicate bug: http://bugs.digium.com/view.php?id=14240 and also it was broken by http://bugs.digium.com/view.php?id=13747 By: Francesco Romano (francesco_r) 2009-01-20 05:34:19.000-0600 festr: the attached debug is with one mISDN phone, but i have also tested in a different machine, same asterisk version but totally different setup (pure sip environment) and pickup don't work not even there. By: Terry Wilson (twilson) 2009-01-20 13:58:40.000-0600 francesco_r: Since I can't reproduce this at all on rc4 with a simple: sip.conf: [phone](!) type=friend context=default secret=1234 host=dynamic callgroup=1 pickupgroup=1 [6001](phone) [6002](phone) [6003](phone) extensions.conf: [default] exten => _600X,1,Dial(SIP/${EXTEN}) With 6001 calling 6003 and 6002 dialing *8 to pickup working for me.  It would help if I could get a simplified example dialplan that you are experiencing this issue with so I can reproduce.  The full.txt isn't really showing me anything as far as what is going on...I just see 551 sending a BYE 5 seconds after it's call is connected.  Maybe if you turn verbose/debug up to 5?  Or, if you can test on the all SIP system, a network capture of all the udp traffic (so I can see the SIP and RTP) would also be helpful.  I have no ISDN equipment to test that case. By: Francesco Romano (francesco_r) 2009-01-22 12:35:25.000-0600 Both machines i have tried have FreePBX gui interface (2.3 and 2.5). The dialplans generated by FreePBX are huge and with agi scripts. So if you want you can try with AsteriskNow 1.5beta. However i'll prepare another dedicated machine to make other tests and post here the results. By: David Brillert (aragon) 2009-01-22 14:37:43.000-0600 I can reproduce failure on Asterisk 1.4.23 version released today. Pure SIP I dial from 6007 to 6010 and dial my pickup code *71 from 6002 6010 stops ringing Audio is not bridged between 6007 and 6002 6007 continues to hear ringback there is no audio heard on 6002 6002 ends call 6007 is sent to voicemail box 6010 after hangup I uploaded asterisk cli for call and an ngrep trace By: Terry Wilson (twilson) 2009-01-22 14:46:00.000-0600 If I can't reproduce it on a vanilla dialplan, then I would be tempted to call this an bug in the the dialplan used, agi scripts, etc.  I am still working on some parking issues, so it will certainly be a bit before I can download and install FreePBX/AsteriskNOW to verify that that is the case. By: David Brillert (aragon) 2009-01-22 14:51:08.000-0600 Just my 2 cents since I do not use group pickups in any installations... and I noticed this bug ID is on roadmap for 1.4.24 I was able to reproduce with SIP but I don't use AsteriskNow or FreePBX. But we are using AGI ;) By: Mark Michelson (mmichelson) 2009-01-22 14:53:50.000-0600 I have assigned this issue to myself since I am also having the same problem with *8 not working properly. In my SIP setup, the problem is just as aragon has described it. Looking at the SIP debug, it appears that the problem is that Asterisk never sends an answer to the phone that originally placed the call. I will work on a fix for this. By: Mark Michelson (mmichelson) 2009-01-22 16:53:46.000-0600 I have uploaded 14206.patch. This fixed the issue for me when I was testing. Please let me know if it fixes the problem for you, too. By: Francesco Romano (francesco_r) 2009-01-23 03:03:24.000-0600 Yes, problem fixed. Thank you. By: David Brillert (aragon) 2009-01-23 07:46:48.000-0600 Works for me By: Digium Subversion (svnbot) 2009-01-23 09:40:13.000-0600 Repository: asterisk Revision: 170392 U   branches/1.4/main/channel.c ------------------------------------------------------------------------ r170392 | mmichelson | 2009-01-23 09:40:13 -0600 (Fri, 23 Jan 2009) | 28 lines Fix broken call pickup 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 ASTERISK-13333) Reported by: francesco_r Patches:      14206.patch uploaded by putnopvut (license 60) Tested by: francesco_r, aragon, putnopvut ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=170392 By: Digium Subversion (svnbot) 2009-01-23 09:44:01.000-0600 Repository: asterisk Revision: 170393 _U  trunk/ U   trunk/main/channel.c ------------------------------------------------------------------------ r170393 | mmichelson | 2009-01-23 09:44:01 -0600 (Fri, 23 Jan 2009) | 36 lines Merged revisions 170392 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170392 | mmichelson | 2009-01-23 09:40:39 -0600 (Fri, 23 Jan 2009) | 28 lines Fix broken call pickup 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 ASTERISK-13333) Reported by: francesco_r Patches:      14206.patch uploaded by putnopvut (license 60) Tested by: francesco_r, aragon, putnopvut ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=170393 By: Digium Subversion (svnbot) 2009-01-23 09:49:24.000-0600 Repository: asterisk Revision: 170394 _U  branches/1.6.0/ U   branches/1.6.0/main/channel.c ------------------------------------------------------------------------ r170394 | mmichelson | 2009-01-23 09:49:24 -0600 (Fri, 23 Jan 2009) | 44 lines Merged revisions 170393 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r170393 | mmichelson | 2009-01-23 09:44:27 -0600 (Fri, 23 Jan 2009) | 36 lines Merged revisions 170392 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170392 | mmichelson | 2009-01-23 09:40:39 -0600 (Fri, 23 Jan 2009) | 28 lines Fix broken call pickup 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 ASTERISK-13333) Reported by: francesco_r Patches:      14206.patch uploaded by putnopvut (license 60) Tested by: francesco_r, aragon, putnopvut ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=170394 By: Digium Subversion (svnbot) 2009-01-23 09:50:37.000-0600 Repository: asterisk Revision: 170395 _U  branches/1.6.1/ U   branches/1.6.1/main/channel.c ------------------------------------------------------------------------ r170395 | mmichelson | 2009-01-23 09:50:36 -0600 (Fri, 23 Jan 2009) | 44 lines Merged revisions 170393 via svnmerge from https://origsvn.digium.com/svn/asterisk/trunk ................ r170393 | mmichelson | 2009-01-23 09:44:27 -0600 (Fri, 23 Jan 2009) | 36 lines Merged revisions 170392 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r170392 | mmichelson | 2009-01-23 09:40:39 -0600 (Fri, 23 Jan 2009) | 28 lines Fix broken call pickup 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 ASTERISK-13333) Reported by: francesco_r Patches:      14206.patch uploaded by putnopvut (license 60) Tested by: francesco_r, aragon, putnopvut ........ ................ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=170395