<div dir="ltr">On Tue, Nov 12, 2013 at 3:20 AM, Torrey Searle <span dir="ltr"><<a href="mailto:tsearle@gmail.com" target="_blank">tsearle@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><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><br></div></div></blockquote><div><br></div><div style>Hey Torrey -</div><div style><br></div>
<div style>This sounds a lot like ASTERISK-21242 (<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21242">https://issues.asterisk.org/jira/browse/ASTERISK-21242</a>), which I was looking at this week as well. Ashley's patch is to just always initialize the T38 stack to avoid those kinds of problems. It appears to have resolved the crashes he saw; it may be worthwhile trying that patch to see if it resolves the two scenarios you're seeing as well.</div>
<div style><br></div><div style>The part I wanted to look into still was what impact the initialization has if we do choose to always initialize it. The other option would be to try to handle the various off nominal cases in the T.38 state machine handling; I have a feeling, however, that to do that would be rather difficult.</div>
<div style><br></div><div style>Matt </div></div><div><br></div>-- <br><div dir="ltr"><div>Matthew Jordan<br></div><div>Digium, Inc. | Engineering Manager</div><div>445 Jan Davis Drive NW - Huntsville, AL 35806 - USA</div>
<div>Check us out at: <a href="http://digium.com" target="_blank">http://digium.com</a> & <a href="http://asterisk.org" target="_blank">http://asterisk.org</a></div></div>
</div></div>