|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|
|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
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 220.127.116.11, 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!