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
-
Mantis ID:16724
-
Regression:No
Description
We are currently again evaluation T.38 via Asterisk. We see the following coredump for every t.38 Session:
#0 ast_udptl_write (s=0xb5d5a300, f=0x9af9f28) at udptl.c:1065
1065 len = udptl_build_packet(s, buf, sizeof(buf), f->data.ptr, len);
bt:
#0 ast_udptl_write (s=0xb5d5a300, f=0x9af9f28) at udptl.c:1065
#1 0xb6b4dfa2 in sip_write (ast=0xb60f0c68, frame=0x9af9f28) at chan_sip.c:6291
#2 0x0809dbb8 in ast_write (chan=0xb60f0c68, fr=0x9af9f28) at channel.c:3487
#3 0x08117492 in bridge_p2p_loop (c0=0xb60f0c68, c1=0x98c5410, p0=0xb5d00018, p1=0x99a10b8, timeoutms=-1, flags=<value optimized out>, fo=0xb5f43e78, rc=0xb5f43e74,
pvt0=0xb5e5ebc8, pvt1=0x99ff440) at rtp.c:4350
#4 0x08120e95 in ast_rtp_bridge (c0=0xb60f0c68, c1=0x98c5410, flags=0, fo=0xb5f43e78, rc=0xb5f43e74, timeoutms=-1) at rtp.c:4554
ASTERISK-1 0x080a20ea in ast_channel_bridge (c0=0xb60f0c68, c1=0x98c5410, config=0xb5f44cfc, fo=0xb5f43e78, rc=0xb5f43e74) at channel.c:5186
ASTERISK-2 0x080c73df in ast_bridge_call (chan=0xb60f0c68, peer=0x98c5410, config=0xb5f44cfc) at features.c:2585
ASTERISK-3 0xb6a6ee6b in dial_exec_full (chan=0xb60f0c68, data=0xb5f46f14, peerflags=0xb5f44e50, continue_exec=0x0) at app_dial.c:2258
ASTERISK-4 0xb6a72bcd in dial_exec (chan=0xb60f0c68, data=0xb5f46f14) at app_dial.c:2342
ASTERISK-5 0x08105457 in pbx_exec (c=0xb60f0c68, app=0xb7b66030, data=0xb5f46f14) at pbx.c:1348
ASTERISK-6 0x08110206 in pbx_extension_helper (c=0xb60f0c68, con=0x0, context=0xb60f0ed8 "local", exten=0xb60f0f28 "<destination>", priority=1, label=0x0, callerid=0xb5e303f0 "<account>",
action=E_SPAWN, found=0xb5f49348, combined_find_spawn=1) at pbx.c:3706
ASTERISK-7 0x0811257d in __ast_pbx_run (c=0xb60f0c68, args=0x0) at pbx.c:4165
ASTERISK-8 0x08113df0 in pbx_thread (data=0xb60f0c68) at pbx.c:4542
ASTERISK-9 0x081538cb in dummy_start (data=0xb60793e0) at utils.c:968
ASTERISK-10 0xb7dbc4c0 in start_thread () from /lib/i686/cmov/libpthread.so.0
ASTERISK-11 0xb7eb46de in clone () from /lib/i686/cmov/libc.so.6
Most likely reason is the same as for bug 0016634, remote end does not send T38FaxMaxDatagram attribute in sdp, asterisk does not initialize far_max_datagram to a reasonable value and tries to allocate buffer with -1 bytes.
Please try hack posted on https://issues.asterisk.org/view.php?id=16634