Summary:	ASTERISK-17916: First DAHDI line transferred into ConfBridge hung up when second DAHDI line transferred into conference
Reporter:	Stephen A. Brandli (stevebrandli)	Labels:
Date Opened:	2011-05-24 14:53:57	Date Closed:	2016-01-08 09:21:48.000-0600
Priority:	Major	Regression?
Status:	Closed/Complete	Components:	Channels/chan_sip/Transfers
Versions:	1.8.4	Frequency of Occurrence	Constant
Related Issues:
Environment:		Attachments:	( 0) extensions.conf.txt ( 1) full.txt
Description:	(1) Receive DAHDI call on Polycom phone using Dial(t). (Not sure if make of phone is important.) (2) Transfer that call using transfer key (not Asterisk codes) to extension that has ConfBridge(1s).  This is an attended transfer. So far, no problem. (3) Receive second DAHDI call as with #1. (4) Transfer that call to conference extension just as with #2. After receiving the second call (step 3), hitting the tranfer key, and calling the conference extension (step 4, which calls ConfBridge()), the Polycom phone is in the conference with the first call.  (Remember that the transfer is attended.)  But, when the Polycom phone hangs up to complete the transfer, the first call is hung up.
Comments:	By: Stephen A. Brandli (stevebrandli) 2011-05-24 14:55:50 My extensions.conf and a debug/verbose trace (level 5 each) attached.  In the dialplan, incoming DAHDI calls come into [external].  The transfers to ConfBridge are to extension 26 in [internal]. By: Leif Madsen (lmadsen) 2011-05-31 09:49:56 This might be a silly question, but are you completing the transfer after step #2? By: Leif Madsen (lmadsen) 2011-05-31 09:50:40 Additionally, can you only reproduce this when the call coming into the device is DAHDI? Or can the incoming call be from a SIP device? By: Leif Madsen (lmadsen) 2011-05-31 10:09:36 I guess this part (near the bottom of the file after the second transfer) looks suspicious.... although maybe it's normal: [May 24 12:36:05] DEBUG[4310] channel.c: Actually Masquerading DAHDI/3-1(6) into the structure of SIP/61-00000007(6) [May 24 12:36:05] DEBUG[4310] chan_sip.c: SIP Fixup: New owner for dialogue 51b6f385-47abd4a6-d26d1e5f@192.168.77.55: DAHDI/3-1<MASQ> (Old parent: DAHDI/3-1) [May 24 12:36:05] DEBUG[4310] chan_sip.c: Hangup call DAHDI/3-1<MASQ>, SIP callid 51b6f385-47abd4a6-d26d1e5f@192.168.77.55 By: Stephen A. Brandli (stevebrandli) 2011-05-31 20:19:28 Answers to two separate questions above: Yes, completing the transfer after step #2.  The first calling party (through DAHDI) is in the conference at that point. Correct: Only reproducible if originated through DAHDI.  The following worked correctly: (1) SIP extension 1 calls SIP extension 2. (2) SIP extension 2 transfers to the conference (transfer button, dial conference extension, hangup). (3) SIP extension 3 calls SIP extension 2. (4) SIP extension 2 transfer to the conference. In step 4, after hitting the transfer button and dialing the extension conference, extensions 1 and 2 are connected in the conference.  After hanging up extension 2 (completing the transfer), extensions 1 and 3 are in the conference as expected. By: Stephen A. Brandli (stevebrandli) 2011-12-30 19:05:58.036-0600 Still an issue with 1.8.8. By: Stephen A. Brandli (stevebrandli) 2012-06-11 18:50:19.163-0500 This no longer occurs in 10.5.