[VoiceOps] Problems with T.38 fax with Grandstream GXW-4248

[Mark Lindsey]

I've also had mixed luck with t.38, but the t.30 fax standard allows only 3
errors; after the third error is detected, the fax is to be cancelled.

But working to make t.38 work is worth the effort. The networks have to be
phenomenally clean to have a reliable faxing service that works all the
time:

If you're doing 10 pages at 28800 bps, that'll take 350 seconds, and
tolerate no more than 0.017% packet loss. That's an unusually clean
network.

If the fax is slower, e.g. 9600 bps, the fax is longer (600 seconds at 9600
bps), so the exposure to errors is greater and the network reliability
requirement is higher -- <=0.01% loss allowed.

This assumes errors are randomly distributed; if they come in clusters the
requirements are much stricter.




---
Mark R Lindsey
mark at ecg.co
+1-229-316-0013
http://ecg.co/lindsey


On Sep 30, 2016 at 18:18, Greg Lipschitz <Greg at thesummitgroup.com.au> wrote:

Have you tried the opposite, disable T.38 and use G711a/u for the payload.

We have had far greater success with the G711a/u RTP. T.38 still seems to
be very hit and miss cross devices be it ATA or even a real fax machine.

Cheers
Greg





Greg Lipschitz  |  Founder & CEO  |  The Summit Group
*Greg at thesummitgroup.com.au* <Greg at thesummitgroup.com.au>
*thesummitgroup.com.au* <http://thesummitgroup.com.au>
*1300 049 749* <1300%20049%20749>
*Level 1, 39 Railway Road, Blackburn VIC 3130*
<https://www.google.com.au/maps/place/The+Summit+Group+(Australia)+Pty+Ltd/@-37.8195827,145.1485403,17z/data=!3m1!4b1!4m7!1m4!3m3!1s0x6ad638b2d1d03e19:0xfb75608e0ae9e67e!2sThe+Summit+Group+(Australia)+Pty+Ltd!3b1!3m1!1s0x6ad638b2d1d03e19:0xfb75608e0ae9e67e>
[image: The Summit Group] <http://thesummitgroup.com.au>
------------------------------
*From:* VoiceOps <voiceops-bounces at voiceops.org> on behalf of Nelson Hicks <
nelsonh at socket.net>
*Sent:* Saturday, October 1, 2016 4:47:30 AM
*To:* voiceops at voiceops.org
*Subject:* [VoiceOps] Problems with T.38 fax with Grandstream GXW-4248

We have a customer with multiple Grandstream GXW-4248 voice gateways
that wants to use T.38 for sending and receiving faxes. They are running
the most recent release (1.0.5.16). We have tested this successfully
with other devices, including a Grandstream HT-702 and a Grandstream
GXW-4004, but when configuring the Grandstream GXW-4248 the same way,
the audio from the Grandstream to the fax machine cuts out at the
renegotiation to T.38 and does not resume. When looking at a packet
capture of the fax call, the Re-INVITE appears successful, but the first
and only UDPTL packet sent by the Grandstream is reported as malformed
by Wireshark:

ITU-T Recommendation T.38
     [Stream setup by SDP (frame 510)]
         [Stream frame: 510]
         [Stream Method: SDP]
     UDPTLPacket
         seq-number: 32768
         primary-ifp-packet
             type-of-msg: t30-indicator (0)
                 something unknown here [too long
integer(per_normally_small_nonnegative_whole_number)]
                     [Expert Info (Warn/Undecoded): something unknown
here [too long integer(per_normally_small_nonnegative_whole_number)]]
                         [something unknown here [too long
integer(per_normally_small_nonnegative_whole_number)]]
                         [Severity level: Warn]
                         [Group: Undecoded]
[Malformed Packet: T.38]
     [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
         [Malformed Packet (Exception occurred)]
         [Severity level: Error]
         [Group: Malformed]

Does anyone have any experience with trying to use T.38 with a
Grandstream GXW-4248?

Thanks,


-- 
Nelson Hicks
Network Operations
SOCKET
(573) 817-0000 ext. 210
nelsonh at socket.net

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160930/20bee7ee/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AT8e21fccf5490f057ef720b8603089edf417c622d8e21fccf5490f057ef720b8603089edf
Type: image/png
Size: 984 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160930/20bee7ee/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AT71d9e17302cd1080f93691110d288a262256353e71d9e17302cd1080f93691110d288a26
Type: image/png
Size: 10728 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160930/20bee7ee/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AT1a43d45583bd2abaa152f094b78855fb184af0db1a43d45583bd2abaa152f094b78855fb
Type: image/png
Size: 1930 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160930/20bee7ee/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AT747599675c40a7cbd784bbbeff2a6759eb110352747599675c40a7cbd784bbbeff2a6759
Type: image/png
Size: 3004 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20160930/20bee7ee/attachment-0007.png>