Summary:	ASTERISK-03938: When specifying T or t in Dial cmd, Asterisk still attempts native bridge
Reporter:	pauls (pauls)	Labels:
Date Opened:	2005-04-14 08:22:37	Date Closed:	2011-06-07 14:10:12
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	IAX native bridging occurs regardless of the t or T directive in the dial command, disabling blind transfers with the # key. Undefining BRIDGE_OPTIMIZATION in chan_iax2.c disables native bridging and allows calls to be transferred.
Comments:	By: Brian West (bkw918) 2005-04-14 12:27:27 This is normal.  When a dtmf frame comes thru it kicks out of a native bridge and processes the DTMF and drops back into a native bridge. /b By: Brian West (bkw918) 2005-04-14 12:27:54 also check features.conf /b By: pauls (pauls) 2005-04-15 07:42:55 So you are saying that it should be able to process the # key blind transfer even in native bridge?  This won't work for me.  If I compile without BRIDGE_OPTIMIZATION then transfers work, otherwise it appears to ignore them.  I have tried this with both release and CVS Head. edited on: 04-15-05 07:43 By: Kevin P. Fleming (kpfleming) 2005-04-20 11:35:10 Yes, bkw is right, DTMF is supposed to stop the native bridge and handle the DTMF. What is the call path involved here (phones, servers, etc) and configuration? By: pauls (pauls) 2005-04-20 19:12:48 I have an IAX connection to my VOIP provider.  A call comes in, is answered by my asterisk and rings either a local IP phone (snom 190) or is directed back out over the same IAX connection to a POTS phone number.  For testing I have "Tt" in the Dial command.  If the call goes to my IP Phone # can be used to transfer the call from either end.  If the call goes back out over the IAX connection # won't work from either end unless compilied without BRIDGE_OPTIMIZATION. Are there any parts of my conf files that would be helpful? By: Kevin P. Fleming (kpfleming) 2005-04-21 00:05:31 Yes, let's see the part(s) of iax.conf related to your provider. Do you have notransfer=yes set for the provider's entries? By: petersv (petersv) 2005-04-21 00:36:32 We have a similar problem with zap->zap channels since at least two months. The 't' option does not work but the 'T' option does. We tried placing a lot of debugging code in Asterisk but we had to give up the search due to time limitations. We may have a chance to debug it further tonight. By: pauls (pauls) 2005-04-21 00:47:35 [general] port=5036 bandwidth=low jitterbuffer=no tos=lowdelay ;dropcount=3 ;maxjitterbuffer=500 ;maxexcessbuffer=100 disallow=all allow=g729 allow=ilbc allow=ulaw allow=gsm allow=alaw notransfer=yes trunk=no register => nnnnnnnn:xxxxxxxx@iax.faktortel.com.au [faktortel] type=friend username= nnnnnnnn secret= xxxxxxxx host=iax.faktortel.com.au auth=md5 context=fakdid qualify=5000 By: pauls (pauls) 2005-04-21 00:51:27 I have tried both notransfer=yes and notransfer=no.  My Asterisk stays in the call with both. By: Kevin P. Fleming (kpfleming) 2005-04-27 01:08:19 I'm not disputing your report, but I can't see how BRIDGE_OPTIMIZATION affects the iax2_bridge function at all, at least in terms of determing _when_ it will native bridge and when it won't. I don't have adequate systems here to test it out locally, either. Can you start by giving us a console debug capture with a call that demonstrates this problem? By: Michael Jerris (mikej) 2005-05-23 22:52:55 Almost 30 days with no response.  If we can not reproduce the issue and get no response we will have to close this bug report out. By: Russell Bryant (russell) 2005-05-24 05:00:16 I am closing this due to loss of interest of the original bug placer and no reports from anyone else confirming this issue. Feel free to re-open this bug if you feel it is still an issue and are willing to help provide debugging information.