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

[opticron]

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

(Updated July 13, 2011, 4:50 p.m.)


Review request for Asterisk Developers.


Changes
-------

This version of the patch uses ast_rtp_instance_dtmf_mode_get as suggested and fixes the code behind it and its set counterpart by finishing the move of dtmf_mode from the ast_rtp_instance struct to the ast_rtp struct and correcting code where it always evalutated to a single value.  Tested with DTMF features enabled and disabled with inband, rfc2833, and info dtmf modes.


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 (updated)
-----

  trunk/channels/chan_sip.c 327949 
  trunk/include/asterisk/rtp_engine.h 327949 
  trunk/main/rtp_engine.c 327949 
  trunk/res/res_rtp_asterisk.c 327949 

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/20110713/3000cbd3/attachment.htm>