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

Ball, Jared Jared.Ball at cdk.com
Sat Oct 1 20:48:35 EDT 2016

I have been pretty happy with the faxback ata solution using the mp202b. Our company tried cisco atas, vg224, quintums, and cisco spa atas. The faxback solution is just more reliable. Here are two reasons. One vendor controls the T.38 stack on both the ata and the fax server. They can optimize T.38 over http using tcp to match their hardware and server. The second reason is that using store and forward bypasses the various network issues from CPE to our SIP trunks. I just have to worry about T.38 to our carriers (level 3 & Verizon).

-------- Original Message --------

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

From: Carlos Alcantar <carlos at race.com>

Date: Oct 1, 2016, 2:49 PM

To: Mark Lindsey <lindsey at e-c-group.com>,Greg Lipschitz <Greg at thesummitgroup.com.au>,voiceops at voiceops.org,Nelson Hicks <nelsonh at socket.net>

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>

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.


Greg Lipschitz   |      Founder & CEO    |      The Summit Group

Greg at thesummitgroup.com.au<mailto:Greg at 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>

[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 ( 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]
         seq-number: 32768
             type-of-msg: t30-indicator (0)
                 something unknown here [too long
                     [Expert Info (Warn/Undecoded): something unknown
here [too long integer(per_normally_small_nonnegative_whole_number)]]
                         [something unknown here [too long
                         [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?


Nelson Hicks
Network Operations
(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>

This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, notify the sender immediately by return email and delete the message and any attachments from your system.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20161002/087922af/attachment.html>

More information about the VoiceOps mailing list