<div dir="ltr">Thanks! I have pcaps that can reproduce this crash faithfully that can be contributed to the test suite (requires the additional dependency of rtpplay though) (been on this issue for a few weeks already). If the consensus is always init, I think the only thing to do is make sure no memory leaks happen as a result.<div>
<br></div><div>In the mean time I'll add the sipp script to this jira reference.</div><div><br></div><div>Thanks again for the pointer!</div><div>Torrey</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 12 November 2013 13:44, Matthew Jordan <span dir="ltr"><<a href="mailto:mjordan@digium.com" target="_blank">mjordan@digium.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div><div class="h5">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></div><div class="gmail_extra">
<div class="gmail_quote"><div><div class="h5">
<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></div><div>Hey Torrey -</div><div><br></div>
<div>This sounds a lot like ASTERISK-21242 (<a href="https://issues.asterisk.org/jira/browse/ASTERISK-21242" target="_blank">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><br></div><div>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><br></div><div>Matt </div></div><span class="HOEnZb"><font color="#888888"><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>
</font></span></div></div>
<br>--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" target="_blank">http://www.api-digital.com</a> --<br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br></div>