res_fax_spandsp: Always init T.38 session to avoid crashes during state change
authorMatthew Jordan <mjordan@digium.com>
Mon, 9 Dec 2013 03:21:56 +0000 (03:21 +0000)
committerMatthew Jordan <mjordan@digium.com>
Mon, 9 Dec 2013 03:21:56 +0000 (03:21 +0000)
commit8042f4cdd2b650613898f9e7ddff0a052b8627f3
tree0d312031b913416518c048aa0c01b1b466ba5de9
parenteb4aa1f0a8f8111f2607b4e8e207be3b41cf62fe
res_fax_spandsp: Always init T.38 session to avoid crashes during state change

Prior to this patch, res_fax_spandsp was conservative with how it initialized
the spandsp T.38 context. It would only initialize it if the driver thought
the current state was a T.38 fax. While this works fine in nominal situations,
in certain off nominal situations, res_fax_spandsp can believe that a T.38
fax will not occur when in fact one has started. In particular, this was
discovered when res_fax would fall back to audio after timing out on a T.38
upgrade. The SIP channel driver would continue to retry the re-INVITE and -
if the remote end responded after res_fax timed out with a 200 OK - a T.38
frame would be delivered to the res_fax stack when it no longer expected it.

As it turns out, there does not appear to be any downside to always
initializing the T.38 context, other than the actual memory allocation.
Since that avoids this off nominal situation (and others which are equally
likely hard to predict), this is the safest way to avoid this problem.

Much thanks to Torrey as well for providing a scenario that reproduces this
issue.

(closes issue ASTERISK-21242)
Reported by: Ashley Winters
Tested by: Torrey Searle
patches:
  always-init-t38.patch uploaded by awinters (License 6477)
  A_PARTY.xml uploaded by tsearle (License 5334)
........

Merged revisions 403449 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........

Merged revisions 403450 from http://svn.asterisk.org/svn/asterisk/branches/11
........

Merged revisions 403458 from http://svn.asterisk.org/svn/asterisk/branches/12

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res/res_fax_spandsp.c