Summary: | ASTERISK-23166: T.38 Fax outgoing call via chan_ooh323 breaks after rtptimeout timer | ||
Reporter: | Sergey Tishchenko (starterx) | Labels: | |
Date Opened: | 2014-01-20 10:48:42.000-0600 | Date Closed: | |
Priority: | Major | Regression? | |
Status: | Open/New | Components: | Addons/chan_ooh323 Core/RTP Resources/res_fax_spandsp |
Versions: | 11.2.0 11.7.0 13.18.4 | Frequency of Occurrence | Constant |
Related Issues: | |||
Environment: | CentOS 6.5 2.6.32-431.3.1.el6.x86_64 Asterisk 11.2-cert3 Spandsp FAX Driver: 20110122 075024 | Attachments: | |
Description: | I'm faced with T.38 fax-problem on chan_ooh323. This test maked in local environment with quintum tenor DX2060, but i tried with external h323 provider and got the same result.
When I start SendFAX I gets RTP lack error after rtptimeout(ooh323.conf) time if value of this time less than time of fax sending. And after call clearing Asterisk don't close UDP sockets opened for RTP media before T.38 handshake. If I increase rtptimeout in ooh323.conf greater than time of sending (f.e. 300sec) fax sending finish successfully but udp sockets still remain opened in any case. In both cases Asterisk sends RTCP packets after call finished from suspended UDP-socket to RTP port of remote endpoint. I tried to change different ooh323.conf parameters: directmedia, directrtpsetup, faststart, mediaforconnect, faxtdetect - no result. And tried to change another options in rtp.conf and udptl.conf - no result. Bug is stable in my environment. I tried make it on many Asterisk 11 branches and on last trunk from SVN - in all bulids it working same. In Asterisk 10.9 it working the same, but udp sockets closes properly after RTP-timeout call crash. Voice calls via chan_ooh323 working good on this environment. Please help me. I'm very needs in fax-machine on chan_ooh323. I attach some files with console debug output, tcpdump sniff, h323_log and netstat output with suspended udp sockets. https://www.dropbox.com/s/q3u5wzrjxbrvz2j/console.log https://www.dropbox.com/s/19i15bpfdamubjv/h323_log https://www.dropbox.com/s/jyli6rj6d4dcv32/h323faxcall.cap https://www.dropbox.com/s/j6lz6ms1exm7utz/netstat.log | ||
Comments: | By: Alexander Anikin (may213) 2014-01-22 08:52:43.141-0600 Sergey, looks like there are two problems that can be solved. First. Long time uni directional data transfer is normal for long faxes, this is in your case, many packets from your asterisk without replies from DX, but there is RTCP reports from DX gate. Problem here is asterisk don't count RTCP packets as lastrtprx. This is long ago subject, count or not rtcp for rtp timeouts? May be correct answer is - yes, for t.38 mode. Second. Looks like to asterisk doesn't work properly with RTCP on UDPTL channels. Example from your call below: OpenLC from DX on T.38 mode: mediaControlChannel: unicastAddress (0) unicastAddress: iPAddress (0) iPAddress network: 10.50.67.148 (10.50.67.148) tsapIdentifier: 10661 media port: 10660, ctl port: 10661 OpenLC from Asterisk on T.38: mediaChannel: unicastAddress (0) unicastAddress: iPAddress (0) iPAddress network: 192.168.235.254 (192.168.235.254) tsapIdentifier: 4492 mediaControlChannel: unicastAddress (0) unicastAddress: iPAddress (0) iPAddress network: 192.168.235.254 (192.168.235.254) tsapIdentifier: 4493 media port: 4492, ctl port: 4493 RTCP: from DX: Source: 10.50.67.148 (10.50.67.148) Destination: 192.168.235.254 (192.168.235.254) User Datagram Protocol, Src Port: 10661 (10661), Dst Port: 4493 (4493) port numbers are correct. reply from Asterisk Source: 192.168.235.254 (192.168.235.254) Destination: 10.50.67.148 (10.50.67.148) Internet Control Message Protocol Type: 3 (Destination unreachable) Code: 3 (Port unreachable) so, asterisk don't accept packets on ctl ports. from Asterisk: Source: 192.168.235.254 (192.168.235.254) Destination: 10.50.67.148 (10.50.67.148) User Datagram Protocol, Src Port: 11137 (11137), Dst Port: 10661 (10661) Source port: 11137 (11137) Destination port is correct, source port is wrong. I'll do more research about this. |