<div dir="ltr">Hello all,<div><br></div><div>I have a scenario which can cause asterisk to crash in SpanDSP to crash.</div><div><br></div><div>Basically res_fax.c has a 5 second timeout that, if triggered disables AST_FAX_TECH_T38.   This causes the T.38 stack not to be initialized and the asterisk will crash if any UDPTL packet arrives after that point.</div>
<div><br></div><div>I have already identified two similar call flows that can trigger this.</div><div><br></div><div>1.  We are slow to receive the ACK message from the calling party.  The T.38 switchover attempt of ReceiveFax will instead just set the NEEDREINVITE flag.  In this case, a T.38 RE-invite can be sent (and succeed!) after res_fax has timed out and disabled T.38 => crash</div>
<div><br></div><div><br></div><div>2. We have sent the T.38 re-invite, but are slow to get the 200 OK from the carrier, we time out, disable T.38, and the 200ok arrives after we give up => crash</div><div><br></div><div>
<br></div><div>Problem is, I'm not sure whats the best way of resolving this.  I have been able to resolve case 1 by not setting the NEEDREINVITE flag, and directly failing to g711 if the ACK hasn't arrived yet, but that still leaves me crashing in case 2.</div>
<div><br></div><div>Other ideas I had were to remove the timeout (trust the channel driver to report failure on re-invite transaction timeout)</div><div><br></div><div>Alternatively I thought it might be good to always initialize the T.38 stack of span dsp just in case we find out later that we actually need to use it.</div>
<div><br></div><div>I would like to get your feed back on what's the best solution for this issue </div><div><br></div><div>Regards,</div><div>Torrey</div></div>