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

Sat Oct 1 17:49:15 EDT 2016

I feel fax / modems is always going to be a send and pray type of situation.  We have had great success with modems /fax in our access network using h.248/mgcp where we control QOS a-z and forcing things out TDM ISUP trunks.  What we are starting to see more of now tho is passed our network even down the TDM ISUP trunks people are starting to convert it into voip down the line.  Modems and faxes are partly why I don't have much hair now.  Just my 2 cents.

Carlos Alcantar
Race Communications / Race Team Member
1325 Howard Ave. #604, Burlingame, CA. 94010
Phone: +1 415 376 3314 / carlos at race.com / http://www.race.com

________________________________________
From: VoiceOps <voiceops-bounces at voiceops.org> on behalf of Mark Lindsey <lindsey at e-c-group.com>
Sent: Friday, September 30, 2016 4:54:10 PM
To: Greg Lipschitz; voiceops at voiceops.org; Nelson Hicks
Subject: Re: [VoiceOps] Problems with T.38 fax with Grandstream GXW-4248

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<mailto:mark at ecg.co>
+1-229-316-0013<tel:+1-229-316-0013>
http://ecg.co/lindsey

On Sep 30, 2016 at 18:18, Greg Lipschitz <Greg at thesummitgroup.com.au<mailto: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<mailto:Greg at thesummitgroup.com.au>
thesummitgroup.com.au<http://thesummitgroup.com.au>
1300 049 749<tel: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>

[cid:QVQ4ZTIxZmNjZjU0OTBmMDU3ZWY3MjBiODYwMzA4OWVkZjQxN2M2MjJkOGUyMWZjY2Y1NDkwZjA1N2VmNzIwYjg2MDMwODllZGY at 2354090]
[cid:QVQ3MWQ5ZTE3MzAyY2QxMDgwZjkzNjkxMTEwZDI4OGEyNjIyNTYzNTNlNzFkOWUxNzMwMmNkMTA4MGY5MzY5MTExMGQyODhhMjY at 2354091]
[The Summit Group]<http://thesummitgroup.com.au>        [cid:QVQ3NDc1OTk2NzVjNDBhN2NiZDc4NGJiYmVmZjJhNjc1OWViMTEwMzUyNzQ3NTk5Njc1YzQwYTdjYmQ3ODRiYmJlZmYyYTY3NTk at 2354093]

________________________________
From: VoiceOps <voiceops-bounces at voiceops.org<mailto:voiceops-bounces at voiceops.org>> on behalf of Nelson Hicks <nelsonh at socket.net<mailto:nelsonh at socket.net>>
Sent: Saturday, October 1, 2016 4:47:30 AM
To: voiceops at voiceops.org<mailto: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<mailto:nelsonh at socket.net>

_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org<mailto:VoiceOps at voiceops.org>
https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AT8e21fccf5490f057ef720b8603089edf417c622d8e21fccf5490f057ef720b8603089edf
Type: image/png
Size: 984 bytes
Desc: AT8e21fccf5490f057ef720b8603089edf417c622d8e21fccf5490f057ef720b8603089edf
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20161001/41940db7/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AT71d9e17302cd1080f93691110d288a262256353e71d9e17302cd1080f93691110d288a26
Type: image/png
Size: 10728 bytes
Desc: AT71d9e17302cd1080f93691110d288a262256353e71d9e17302cd1080f93691110d288a26
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20161001/41940db7/attachment-0005.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AT1a43d45583bd2abaa152f094b78855fb184af0db1a43d45583bd2abaa152f094b78855fb
Type: image/png
Size: 1930 bytes
Desc: AT1a43d45583bd2abaa152f094b78855fb184af0db1a43d45583bd2abaa152f094b78855fb
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20161001/41940db7/attachment-0006.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: AT747599675c40a7cbd784bbbeff2a6759eb110352747599675c40a7cbd784bbbeff2a6759
Type: image/png
Size: 3004 bytes
Desc: AT747599675c40a7cbd784bbbeff2a6759eb110352747599675c40a7cbd784bbbeff2a6759
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20161001/41940db7/attachment-0007.png>