Details
-
Type:
Bug
-
Status: Closed
-
Severity:
Critical
-
Resolution: Fixed
-
Affects Version/s: None
-
Target Release Version/s: None
-
Component/s: Channels/chan_sip/T.38
-
Labels:None
-
Source Revision Number:236360
-
Mantis ID:16517
-
Regression:No
Description
I have been experimenting with T.38 fax reception via SIP. This results in an immediate crash. While I am able to capture a coredump, for whatever reason GDB and MDB do not appear to be able to give me a usable backtrace. However, Asterisk logs these message immediately before crashing:
[Dec 26 21:06:25] – Executing [fax@standard-fax:2] ReceiveFAX("SIP/broadriver-00000000", "/var/spool/fax/1261861580.0.fax,debug") in new stack
[Dec 26 21:06:25] NOTICE[23097]: channel.c:2933 __ast_read: Dropping incompatible voice frame on SIP/broadriver-00000000 of format slin since our native format has changed to 0x4 (ulaw)
grant*CLI> [Dec 26 21:06:25] WARNING[23097]: udptl.c:766 calculate_far_max_ifp: (no tag): Cannot calculate far_max_ifp before far_max_datagram has been set.
[Dec 26 21:06:25] WARNING[23097]: udptl.c:766 calculate_far_max_ifp: (no tag): Cannot calculate far_max_ifp before far_max_datagram has been set.
Next I tried forcing the max datagram in sip.conf like this:
[general]
t38pt_udptl=yes,maxdatagram=400
However, Asterisk still crashes with the same message.
Out of curiosity, I modified main/udptl.c at line 764 in the function calculate_far_max_ifp() to force the far_max_datagram to 400:
udptl->far_max_datagram = 400;
Doing this prevents Asterisk from segfaulting.
I wish I could share a backtrace, but so far I can't produce anything useful. I am willing to post the entire core dump if that would be helpful.
The core file is only useful on the machine it was run on. Perhaps you can provide the backtrace of what you have, and maybe a developer will find something useful in it?
Otherwise, it is possible this is a memory corruption issue, in which case valgrind output is what will be needed to move this forward.
I think seeing the sip trace and console output just prior to the crash may be useful as well.