|Summary:||ASTERISK-15116: T.38 passthrough issue in 126.96.36.199|
|Date Opened:||2009-11-10 17:51:20.000-0600||Date Closed:||2010-01-07 10:46:13.000-0600|
|Environment:||Attachments:||( 0) sbc01-interop.TSI.FFAvsSR140.pcap|
|Description:||I'd select Category Core/udptl if it was in a drop-down list|
I'd also select Product version 188.8.131.52 (also not in the list)
Asterisk server is in between 'fax server' (184.108.40.206) and 'provider' (220.127.116.11 for signaling, .236 for RTP and .238 for udptl). Asterisk server communicates via 18.104.22.168 with provider and via .77 with fax server.
Asterisk server is supposed to work in T.38 pass-through mode.
.pcap file should be attached. It contains 2 fax sessions, sending the same fax from fax server to provider. Session 1 is for FFA based fax server, there are no issues. Session 2 is for Dialogic SR140 based fax server, session fails consistently.
In both sessions SIP negotiation with T.38 re-INVITE and start of T.30 is fine. Provider sends DIS, fax server replies with '66 TSI' and '65 DCS'. The issue is with training. Session 1 training info goes through asterisk server OK and provider sends '33, RTP'. Session 2 training info gets stuck within asterisk server, provider repeats DIS, fax server re-sends TSI and DCS and training fails again.
Please, look at packets 732-822 (session 1), they go through. Packets 2228-2390 (session 2) don't go through. Packet 2369 (seq. 8) is the only one that makes it, seq. 9-25 are gotten from a fax server but are not sent to provider.
****** ADDITIONAL INFORMATION ******
Will try to attach .pcap once issue is created.
|Comments:||By: Joshua C. Colp (jcolp) 2009-11-16 09:03:47.000-0600|
Please retest this using the latest version. There have been substantial changes to the way that fax works and is communicated through the core. If the problem still exists then a new pcap and an Asterisk log would be needed.
By: zalex (zalex) 2009-11-16 12:27:40.000-0600
Could you please, provide the 'latest' version number. The issue is reported for 22.214.171.124, all the changes you are referring to are part of this release.
AFAIK 126.96.36.199 is a security release based on 188.8.131.52, diff shows there are no sip channel (except 5 security related lines) or udptl changes. 184.108.40.206rc release?
By: Joshua C. Colp (jcolp) 2009-11-16 13:22:07.000-0600
Yes, the release candidate is what you should test.
By: Leif Madsen (lmadsen) 2010-01-07 10:46:12.000-0600
I'm going to close this now as a LOT of T.38 issues were fixed in the latest release. Please retest with that, and if you still have issues, please open a new report. Thanks!