[asterisk-dev] [Code Review] inband DTMF cannot be detected and trigger service execute when A and B both use u-law

[David Vossel]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/1302/#review3838
-----------------------------------------------------------


It looks to me like this sort of logic belongs in the ast_rtp_instance_bridge() code.  We check the AST_BRIDGE_DTMF_CHANNEL flags there to determine if we need to watch for DTMF or not.  If dtmf is within the stream using RFC2833 and we are watching for DTMF, then we refuse to do the local bridge.  Something similar to this should be done for inband dtmf.  Regardless, we shouldn't have to build any new logic to determine if we are needing to watch for DTMF or not.


trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/1302/#comment7658>

    This will cause a deadlock.  The tech pvt lock is held here.  ast_test_dial_features() attempts to lock the channel to get the datastore while the pvt is locked.


- David


On June 29, 2011, 4:34 p.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1302/
> -----------------------------------------------------------
> 
> (Updated June 29, 2011, 4:34 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Summary
> -------
> 
> When deciding whether Asterisk was allowed to bridge the call away from the core, chan_sip did not take into account the usage of features on dialed channels that require monitoring of DTMF on channels utilizing inband DTMF.  This would cause Asterisk to allow the call to be locally or remotely bridged, preventing access to the data required to detect activations of such features.  chan_sip now checks this and disallows bridging away from the core when using inband DTMF and certain dialed features simultaneously.
> 
> 
> This addresses bug ASTERISK-17237.
>     https://issues.asterisk.org/jira/browse/ASTERISK-17237
> 
> 
> Diffs
> -----
> 
>   trunk/channels/chan_sip.c 325090 
>   trunk/include/asterisk/features.h 325090 
>   trunk/main/features.c 325090 
> 
> Diff: https://reviewboard.asterisk.org/r/1302/diff
> 
> 
> Testing
> -------
> 
> The scenario described in the bug report now works as expected.
> 
> 
> Thanks,
> 
> opticron
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20110707/47699761/attachment.htm>