Summary:	ASTERISK-08174: ParkedCall does not native bridge.
Reporter:	Matt King, M.A. Oxon. (kebl0155)	Labels:
Date Opened:	2006-11-22 15:09:35.000-0600	Date Closed:	2006-11-30 13:06:55.000-0600
Priority:	Minor	Regression?	No
Status:	Closed/Complete	Components:	Resources/res_features
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:
Description:	With SIP, if one sip user dials another with the Dial command, and both sip users have canreinvite=yes, Asterisk drops out of the call path on call connection.  The phones are directly connected resulting in bandwidth savings and improved call quality. In asterisk 1.2.5, this behaviour was preserved when calls were connected through Park / ParkedCall.  By 1.2.12 this behaviour has been lost.  Also does not work in 1.4 beta 3. ****** ADDITIONAL INFORMATION ****** In asterisk 1.2.5, if one SIP interfaces dials exten => 2001,1,Park and another dials exten => 2001,1,ParkedCall(701) then the native bridge takes place with the following message being displayed:  -- Attempting native bridge of SIP/12345-4bfe and SIP/12346-21f5 With later versions there is no native bridge attempt. This has serious implications for us, as our callers come in over VoIP through a SIP termination provider.  With 1.2.5, we are able to drop asterisk out of the call path, so call quality is much improved, and our bandwidth is reduced, as the actual call flow goes only through our termination provider's servers.
Comments:	By: Joshua C. Colp (jcolp) 2006-11-28 21:46:22.000-0600 I labbed this up and your statement about the "Attempting" native bridge notice indicating the native bridge occurred is wrong - the native bridge didn't in fact occur. In later versions we just removed the "Attempting" message so that people didn't think as you did. Can you confirm via sip debug that a reinvite did actually occur on 1.2.5? As for the underlying cause it's because the parking stuff listens for DTMF for transfers. I'm going to ask our current parking person if he thinks this is needed. By: Matt King, M.A. Oxon. (kebl0155) 2006-11-29 08:06:56.000-0600 Hello File, Yes I also did some more labbing, and it appears I *was* one of the people confused by the Attempting native bridge notice.  My apologies. We don't actually want/need any of the DTMF stuff that's allowed with parked calls - we disable all this in features.conf.  We use park purely to bridge existing calls (as currently it's the only way to do this in Asterisk).  It is v. important to us that the bridge is native. So far as I can tell, in 1.2.7.1, each of the features are checked in turn to see if they require DTMF.  If they do, then the AST_BRIDGE_DTMF_CHANNEL flag is set, which then prevents rtp.c from doing the native bridge.   Unfortunately these checks seem to take place regardless of whether or not the feature is actually enabled in features.conf.  I would suggest that one should only set the AST_BRIDGE_DTMF_CHANNEL flag if DTMF is required by an *enabled* feature. In 1.4.0 beta 3, we also have the checks - but then AST_FEATURE_REDIRECT is also set on the channels, which further prevents the native bridge. By: Joshua C. Colp (jcolp) 2006-11-30 13:06:54.000-0600 Fixed in 1.2 as of revision 48154, 1.4 as of revision 48155, and trunk as of revision 48156. Peace!