[Home]

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-0600Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents: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 075024Attachments:
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.