Summary:	ASTERISK-05578: Blind transfer between two Asterisk 1.2rc2 with IAX native bridging fails after 2nd blind transfer
Reporter:	Kristopher Lalletti (kris2k)	Labels:
Date Opened:	2005-11-12 13:29:07.000-0600	Date Closed:	2006-03-10 01:55:44.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	Okay, here's the detailed scenario of the call process that done. 1.Inbound from PSTN handled by external SIP gateway 2.External Sip gateway calls AsteriskA 3.Diaplan calls AsteriskB via IAX2 4.AsteriskB diaplan calls SIP PhoneB (Cisco 7960) 5.SIP PhoneB Answers, talks for a few seconds, then blind transfers to SIP PhoneA extension that is on AsteriskA 6.AsteriskB calls AsteriskA via IAX2 7.AsteriskA calls SIP Phone A 8.SIP Phone A answers call, and IAX2 native briding is accomplished (and confirmed) 9.SIP Phone A talks for a few secondes, then blind transfers back to SIP Phone B. 10. AsteriskA calls AsteriskB via IAX2 11. AsteriskB calls SIP Phone B 12. SIP Phone B answers, hears garbled voice frames after, and when native briding is accomplished, call drops on the originating Leg (from step 1), but call stays open on SIP Phone B. In summary, the PSTN caller initially gets transfered to SIP PhoneB from AsteriskA, then SIP PhoneB sends it to SIP PhoneA (from AsteriskA), then sends it back to SIP PhoneB (on AsteriskB). This is quite intricate; I suggest setting-up Two asterisk 1.2rc2 boxes, and simply blind transfering an inbound call from one of the Asterisk Boxes between two extensions on the two asterisk boxes.  With SIP, this works flawlessly (I've transfered the call over 10 times). ****** ADDITIONAL INFORMATION ****** I can reproduce this scenario at every call, and I simplified the iax.conf to its simplest form to avoid parameter problems. AsteriskA iax.conf [general] disallow=all allow=ulaw [asteriskB] type=friend context=asteriskAusers host=asteriskB secret=myscret transfer=yes auth=md5 disallow=all allow=ulaw qualify=yes accountcode=AAA amaflags=DOCUMENTATION AsteriskB iax.conf [general] disallow=all allow=ulaw [asteriskA] type=friend context=asteriskBusers host=asteriskA secret=myscret transfer=yes auth=md5 disallow=all allow=ulaw qualify=yes accountcode=BBB amaflags=DOCUMENTATION And finally, the Output of AsteriskA's console that is problematic, since AsteriskB's console does not display anything related to the issue    -- Executing Dial("IAX2/asteriskB-2", "IAX2/asteriskB/sipPhoneB|120") in new stack    -- Called asteriskB/sipPhoneB    -- Call accepted by asteriskBIPaddress (format ulaw)    -- Format for call is ulaw    -- IAX2/asteriskB-3 is ringing    -- IAX2/asteriskB-3 stopped sounds    -- IAX2/asteriskB-3 answered IAX2/asteriskB-2    -- Attempting native bridge of IAX2/asteriskB-2 and IAX2/asteriskB-3    -- Channel 'IAX2/asteriskB-2' ready to transfer    -- Channel 'IAX2/asteriskB-3' ready to transfer    -- Releasing IAX2/asteriskB-3 and IAX2/asteriskB-2 Nov 12 14:20:36 WARNING[16837]: chan_iax2.c:7532 socket_read: Received mini frame before first full voice frame Nov 12 14:20:36 WARNING[16837]: chan_iax2.c:7532 socket_read: Received mini frame before first full voice frame Nov 12 14:20:36 WARNING[16837]: chan_iax2.c:7532 socket_read: Received mini frame before first full voice frame Nov 12 14:20:36 WARNING[16837]: chan_iax2.c:7532 socket_read: Received mini frame before first full voice frame Nov 12 14:20:36 WARNING[16837]: chan_iax2.c:7532 socket_read: Received mini frame before first full voice frame Nov 12 14:20:38 WARNING[16837]: chan_iax2.c:7532 socket_read: Received mini frame before first full voice frame    -- Hungup 'IAX2/asteriskB-1'    -- Hungup 'IAX2/asteriskB-3'    -- Hungup 'IAX2/asteriskB-2'
Comments:	By: Mark Spencer (markster) 2005-11-12 20:04:19.000-0600 This output looks more or less accurate for a native IAX2 transfer.  Can you please find me on IRC so I can login and look at the issue?  kram on irc.freenode.net mark By: Kristopher Lalletti (kris2k) 2005-11-14 12:17:30.000-0600 Tried finding Mark online Sunday night from 8pm to 10pm EST without any success (away for the weekend it seems), will keep trying during the week. In the meanwhile, please avise of a test procedure + formal IAX configuration so I can test and post some logs here. By: BJ Weschke (bweschke) 2005-11-16 15:13:26.000-0600 we were able to reproduce this to some extent. the core reason seems to be because even though the calls are ending up back on the same server at the time, the native bridging still isn't removing IAX2 channels out of the mix which is causing a lengthy chain of channels by the time you're done with all the transfers. there's no real good resolution/solution that we have right now. By: Mark Spencer (markster) 2006-01-29 20:26:45.000-0600 We made a fix to try to repair this.  Is this still a problem? By: Olle Johansson (oej) 2006-03-10 01:55:44.000-0600 --no reply from reporter. Supposedly fixed. Closing this bug report.