Summary:ASTERISK-20670: Wrong error correction in T38 INVITE when multiple Asterisk servers are involved.
Reporter:Mike Walker (mwalker420)Labels:
Date Opened:2012-11-09 16:27:31.000-0600Date Closed:2013-02-04 13:59:13.000-0600
Status:Closed/CompleteComponents:Channels/chan_sip/T.38 Core/UDPTL
Versions: 10.8.0 10.9.0 10.10.0 Frequency of
Environment:Debian 6 x86_64 8-Way 16GB RAM.Attachments:( 0) sip_show.txt
( 1) sip.conf
Description:When Asterisk is sending a T38 INVITE to an ATA when faxing though more than one Asterisk server, the final Asterisk server in the chain always sends FEC error correction regardless of the initial INVITE sent to Asterisk from the originating ATA, or what the error correction is set to any of the sip.conf files.

ATA > Asterisk > ATA works

ATA > Asterisk > Asterisk > ATA fails

The initial INVITE from the originating ATA has T38FaxUdpEC:t38UDPRedundancy set, the INVITE from first Asterisk server to second Asterisk server contains T38FaxUdpEC:t38UDPRedundancy, but the INVITE from second Asterisk server to terminating ATA has T38FaxUdpEC:t38UDPFEC instead of T38FaxUdpEC:t38UDPRedundancy.  This happens regardless of directmedia setting, and even when t38pt_udptl=yes,redundancy,maxdatagram=400 is set in all sip.conf files.

No matter what we try, we can never get the final T38 INVITE to T38FaxUdpEC:t38UDPRedundancy when attempting to fax through more then one Asterisk server.

We are using two Grandstream HT502 ATA's with the latest firmware and have tried several versions of Asterisk 1.8 and 10 to no avail.
Comments:By: Joshua C. Colp (jcolp) 2012-11-09 18:51:52.816-0600

What is the output of "sip show peer" for the peer entry of the ATA on the second Asterisk server?

By: i2045 (i2045) 2012-11-21 06:30:49.985-0600

I experience the same bug.
The output of sip show user/peer and the configuration is attached.

By: Rusty Newton (rnewton) 2012-12-31 16:52:09.660-0600

Can one of the reporters please provide further debug for this scenario.

SIP and UDPTL packet captures from each system involved, for all interfaces that traffic is traveling across. Verify you can see everything from the origin to destination endpoints.

For that same call, capture VERBOSE and DEBUG messages in an Asterisk full log (logger.conf) set to at least level 5.


Please attach all the debug in a compressed file, including your SIP.conf and other relevant fax configuration, such as res_fax.conf. Please sanitize the files for any passwords or information you don't want revealed.

By: Rusty Newton (rnewton) 2013-01-17 17:23:31.667-0600

Mike, are you able to provide the requested data?

By: Rusty Newton (rnewton) 2013-02-04 13:59:13.602-0600

We can't look into this without the data requested. If someone experiencing this can provide the debug, then please request a re-open via JIRA or #asterisk-bugs.