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 <car...@race.com> Date: Oct 1, 2016, 2:49 PM To: Mark Lindsey <lind...@e-c-group.com>,Greg Lipschitz <g...@thesummitgroup.com.au>,voiceops@voiceops.org,Nelson Hicks <nels...@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 / car...@race.com / http://www.race.com ________________________________________ From: VoiceOps <voiceops-boun...@voiceops.org> on behalf of Mark Lindsey <lind...@e-c-group.com> Sent: Friday, September 30, 2016 4:54:10 PM To: Greg Lipschitz; voiceops@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 m...@ecg.co<mailto:m...@ecg.co> +1-229-316-0013<tel:+1-229-316-0013> http://ecg.co/lindsey On Sep 30, 2016 at 18:18, Greg Lipschitz <g...@thesummitgroup.com.au<mailto:g...@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 g...@thesummitgroup.com.au<mailto:g...@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@2354090] [cid:QVQ3MWQ5ZTE3MzAyY2QxMDgwZjkzNjkxMTEwZDI4OGEyNjIyNTYzNTNlNzFkOWUxNzMwMmNkMTA4MGY5MzY5MTExMGQyODhhMjY@2354091] [The Summit Group]<http://thesummitgroup.com.au> [cid:QVQ3NDc1OTk2NzVjNDBhN2NiZDc4NGJiYmVmZjJhNjc1OWViMTEwMzUyNzQ3NTk5Njc1YzQwYTdjYmQ3ODRiYmJlZmYyYTY3NTk@2354093] ________________________________ From: VoiceOps <voiceops-boun...@voiceops.org<mailto:voiceops-boun...@voiceops.org>> on behalf of Nelson Hicks <nels...@socket.net<mailto:nels...@socket.net>> Sent: Saturday, October 1, 2016 4:47:30 AM To: voiceops@voiceops.org<mailto:voiceops@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 nels...@socket.net<mailto:nels...@socket.net> _______________________________________________ VoiceOps mailing list VoiceOps@voiceops.org<mailto:VoiceOps@voiceops.org> https://puck.nether.net/mailman/listinfo/voiceops ---------------------------------------------------------------------- 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.
_______________________________________________ VoiceOps mailing list VoiceOps@voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
