[Home]

Summary:ASTERISK-18641: T.38 Passthrough Broken
Reporter:rsw686 (rsw686)Labels:
Date Opened:2011-09-28 21:05:25Date Closed:2011-11-21 14:15:13.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Channels/chan_sip/T.38
Versions:1.8.7.0 Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) full
Description:I have the following configuration: SPA2102 ATA firmware 5.2.12 => Asterisk 1.8.7.0 => Gafachi. I have successfully sent faxes from the ATA to Asterisk using ReceiveFAX over T.38. The issue I am having is with the T.38 passthrough to Gafachi. Asterisk reads in the UDPTL packets, but only passes through the first packet from each side. The rest are ignored and not passed on.

{code}
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/17034800000): packet from 67.216.37.26:12506 (type 0, seq 0, len 14)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/1002): packet to 10.10.1.142:16412 (type 0, seq 0, len 14)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/1002): packet from 10.10.1.142:16412 (type 0, seq 0, len 6)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/17034800000): packet to 67.216.37.26:12506 (type 0, seq 0, len 8)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/17034800000): packet from 67.216.37.26:12506 (type 0, seq 0, len 14)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/1002): packet from 10.10.1.142:16412 (type 0, seq 0, len 6)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/17034800000): packet from 67.216.37.26:12506 (type 0, seq 0, len 14)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/1002): packet from 10.10.1.142:16412 (type 0, seq 0, len 6)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/17034800000): packet from 67.216.37.26:12506 (type 0, seq 0, len 14)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/1002): packet from 10.10.1.142:16412 (type 0, seq 0, len 6)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/17034800000): packet from 67.216.37.26:12506 (type 0, seq 0, len 14)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/1002): packet from 10.10.1.142:16412 (type 0, seq 0, len 6)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/17034800000): packet from 67.216.37.26:12506 (type 0, seq 0, len 14)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/1002): packet from 10.10.1.142:16412 (type 0, seq 0, len 6)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/17034800000): packet from 67.216.37.26:12506 (type 0, seq 0, len 14)
[Sep 28 21:46:12] VERBOSE[26208] udptl.c:  UDPTL (SIP/1002): packet from 10.10.1.142:16412 (type 0, seq 0, len 6)
{code}
Comments:By: Gregory Hinton Nietsky (irroot) 2011-09-29 00:45:50.812-0500

Please add the output of sip debug the above shows me bi directional T.38 and seems in order we will need additional information.
By: rsw686 (rsw686) 2011-09-29 10:26:14.062-0500

I've attached the debug output. If you look at the UDPTL packets there are two with "packet to x.x.x.x". The rest are "packet from" and they do not get resent out. I'm thinking this is due to the sequence number staying at 0. The ATA keeps sending no-signal to Asterisk. Gafachi is sending various data:v27-2400, data:v29-7200, data:v29-9600 packets to Asterisk. However these packets aren't passed to the other party. What needs to be changed to send the packets back out even if the sequence number doesn't increase?
By: Matthew Nicholson (mnicholson) 2011-10-03 14:13:56.129-0500

In the debug output in your description all of the seq numbers are 0 because of a bug in our UDPTL debug output. To see the real sequence numbers you would need a pcap file with the network traffic in it.

Beyond that, I believe you are correct in assessing that asterisk does not forward packets with duplicate sequence numbers. Without seeing a pcap thought, I can't really say if that is causing the problem you are seeing here.

Please upload a pcap of this fax attempt. You can generate a pcap file using the following command:

{noformat}
tcpdump -s1500 -wASTERISK-18641.pcap -vv
{noformat}
By: Leif Madsen (lmadsen) 2011-11-01 09:08:56.474-0500

Pinging reporter for requested pcap capture prior to closing.
By: Leif Madsen (lmadsen) 2011-11-21 14:15:06.885-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines