| 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-0600 | Date Closed: | 2013-02-04 13:59:13.000-0600 |
| Priority: | Major | Regression? | No |
| Status: | Closed/Complete | Components: | Channels/chan_sip/T.38 Core/UDPTL |
| Versions: | 1.8.18.0 10.8.0 10.9.0 10.10.0 | Frequency of Occurrence | Constant |
| Related Issues: | |||
| 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. https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information 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. | ||