|Summary:||ASTERISK-05048: [request] RFC3389 Support requested. (workaround)|
|Reporter:||Brian West (bkw918)||Labels:|
|Date Opened:||2005-09-10 23:16:04||Date Closed:||2011-06-07 14:03:18|
|Description:||Over the past day I have done some research that might help some people that have to interact with providers that force you to use VAD. |
1. Disable .bridge = ast_rtp_bridge in chan_sip.c on the box that is directly interacting with the provider.
2. You must have zaptel clocking for this to work.
3. Your music on hold will work properly from then on with the provider that forces VAD.
Now post anything that might help bring RFC3389 to asterisk faster.
|Comments:||By: Olle Johansson (oej) 2005-09-12 10:19:05|
Bad shorttime fix: Should we create a config option to disable rtpbridging instead of letting people patch the source?
By: Brian West (bkw918) 2005-09-12 19:27:57
That was my thinking also. A config option or a dial option... You can use Local/ to keep that from taking place but that seems to be ugly and causes issues. Maybe a global way to disable all native bridges?
By: Kevin P. Fleming (kpfleming) 2005-09-13 21:19:55
There are other sneaky ways you can do it now... define a feature-mapped application that doesn't actually do anything, which will cause Asterisk to listen for DTMF, which will stop the native bridge :-)
Otherwise the only thing I can think of that might be appropriate is a peer-level config option in chan_sip (and other channel drivers). I don't think this belongs in the dialplan (or global), since it would be hard to handle calls being placed through other means (app_queue, manager, AGI, etc.)
By: Kevin P. Fleming (kpfleming) 2005-09-13 21:20:23
And before you ask... yes, I would accept this minor new feature into 1.2, since there has been increasing demand for it for some time.
By: Russell Bryant (russell) 2005-10-04 15:34:07
See ASTERISK-5230 for a related patch
By: Olle Johansson (oej) 2005-10-25 04:12:53
Ping. What to do with this issue report?
By: Kevin P. Fleming (kpfleming) 2005-12-12 19:42:13.000-0600
There are no code changes involved with this report... suspended until something more concrete is needed.