[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/#review3848
-----------------------------------------------------------


It looks like we have a function called ast_rtp_instance_dtmf_mode_get() that can be used to determine if an rtp instance will have DTMF inband or rfc2833.  Can we just use this function instead of checking the rtp DTMF property?  For some reason setting the RTP DTMF property on a rtp instance looks like it is just supposed to tell the underlining rtp technology that rfc 2833 will be used.  I don't know what setting the property when the dtmf is inband will actually do.

- David


On July 8, 2011, 9:01 a.m., opticron wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/1302/
> -----------------------------------------------------------
> 
> (Updated July 8, 2011, 9:01 a.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 
> 
> 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/20110711/477f613c/attachment.htm>