| Summary: | ASTERISK-19468: Crash seems to be related to sip fax calls | ||||
| Reporter: | Benjamin Lawetz (benthos) | Labels: | |||
| Date Opened: | 2012-03-02 12:18:04.000-0600 | Date Closed: | 2012-04-17 14:28:05 | ||
| Priority: | Critical | Regression? | |||
| Status: | Closed/Complete | Components: | Channels/chan_sip/T.38 | ||
| Versions: | 1.8.8.2 1.8.9.3 1.8.10.0 | Frequency of Occurrence | Frequent | ||
| Related Issues: |
| ||||
| Environment: | CentOS release 5.5 (Final) 2.6.18-194.8.1.el5 #1 SMP Thu Jul 1 19:04:48 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux | Attachments: | ( 0) ASTERISK-19468-fix.patch ( 1) bt_full.txt ( 2) bt.txt | ||
| Description: | Our live system started crashing once a week, then it was once a day, now it's multiple times a day (we are adding more clients on it, which could explain the frequency increase). I can't seem to pin-point what when this happens | ||||
| Comments: | By: Benjamin Lawetz (benthos) 2012-03-02 12:20:41.378-0600 bt full By: Benjamin Lawetz (benthos) 2012-03-05 09:30:53.197-0600 Tried upgrading to Asterisk 1.8.9.3 and problem occured also. By: Benjamin Lawetz (benthos) 2012-03-05 10:14:00.863-0600 The issue might be the same as ASTERISK-19373 Just spotted the T38FaxMaxDatagram errors at the same time as a couple of the crashes. By: Matt Jordan (mjordan) 2012-03-05 15:47:41.435-0600 Benjamin - can you attach the warnings if they're similar to ASTERISK-19373? By: Benjamin Lawetz (benthos) 2012-03-05 15:59:31.050-0600 Today's crash on 1.8.9.3: [2012-03-05 10:26:21] WARNING[18649] udptl.c: UDPTL (SIP/CMSulaw-0000261f): UDPTL asked to send 715100 bytes of IFP when far end only prepared to accept 375 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. Friday's crashes on 1.8.8.2: [2012-03-01 08:24:37] WARNING[27991] udptl.c: (SIP/): UDPTL asked to send 942700 bytes of IFP when far end only prepared to accept 375 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. [2012-03-01 11:03:19] WARNING[697] udptl.c: (SIP/): UDPTL asked to send 336800 bytes of IFP when far end only prepared to accept 375 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. [2012-03-01 11:14:40] WARNING[1235] udptl.c: (SIP/): UDPTL asked to send 185800 bytes of IFP when far end only prepared to accept 375 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. [2012-03-01 12:30:15] WARNING[3901] udptl.c: (SIP/): UDPTL asked to send 32300 bytes of IFP when far end only prepared to accept 375 bytes; data loss will occur.You may need to override the T38FaxMaxDatagram value for this endpoint in the channel driver configuration. I had two other crashes at 13:33 and 14:30, but the error message was not logged. By: Benjamin Lawetz (benthos) 2012-03-06 09:39:55.584-0600 We where able to narrow it down to one of our clients that was causing these error messages (and therefore the crash). The client's T38 endpoint is a Quintum switch. Our T38 endpoint is also a Quintum. On the client's side, the Quintum had the Max Datagram set to '3'. We've modified it to '0' and so far (24h) we haven't had any more of those messages (or crashes) By: Benjamin Lawetz (benthos) 2012-03-13 09:10:57.707-0500 Ignore the Max Datagram set to '3' causing the problem and setting to '0' fixing it. (Setting to '0' actually prevented the faxes from working on the Quintum). Also reproduced problem on 1.8.10.0 By: Benjamin Lawetz (benthos) 2012-03-29 13:22:11.288-0500 With this, we've managed to have gone a week without a crash (and 3 logs indicate that it should have crashed). So this seems to fix the issue By: Damjan Jovanovic (damjan-ecn) 2012-04-11 06:31:15.885-0500 Instead of checking for (frame->datalen && frame->data.ptr == NULL) in channel.c and frame.c, you should ensure udptl_rx_packet() doesn't generate that bad frame in the first place. See [the full description on #19373|https://issues.asterisk.org/jira/browse/ASTERISK-19373?focusedCommentId=191357&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-191357], which this bug is a duplicate of. By: Benjamin Lawetz (benthos) 2012-04-17 14:28:05.459-0500 Duplicate of 19373 | ||||