[asterisk-dev] [Code Review] 2915: Add channel lock protection around translation path setup.

[rmudgett]

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

(Updated Oct. 16, 2013, 11:17 p.m.)


Review request for Asterisk Developers.


Changes
-------

Addressed Mark's finding in res_fax within the bounds of this patch.  The res_fax framehooks have a lot more pre-existing deadlock potential remaining.


Bugs: ASTERISK-22542
    https://issues.asterisk.org/jira/browse/ASTERISK-22542


Repository: Asterisk


Description
-------

Most callers of ast_channel_make_compatible() happen before the channels enter a two party bridge.  With the new bridging framework, two party bridging technologies may also call ast_channel_make_compatible() when there is more than one thread involved with the two channels.

* Added channel lock protection in set_format() and ast_channel_make_compatible_helper() when dealing with the channel's native formats while setting up a translation path.

* Fixed best_src_fmt and best_dst_fmt usage consistency in ast_channel_make_compatible_helper().  The call to ast_translator_best_choice() got them backwards.

* Updated some callers of ast_channel_make_compatible() and the function documentation.  There is actually a difference between the two channels passed in.


Diffs (updated)
-----

  /branches/12/apps/app_dial.c 401115 
  /branches/12/include/asterisk/channel.h 401115 
  /branches/12/main/channel.c 401115 
  /branches/12/res/res_fax.c 401115 

Diff: https://reviewboard.asterisk.org/r/2915/diff/


Testing
-------

Since there is not enough information on ASTERISK-22542 to determine why no translation path could happen, the best that testing can do is show that the change does not cause problems.


Thanks,

rmudgett

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20131016/2a2d051e/attachment.html>