[VoiceOps] VoIP T38 Fax reliability

[Alex Balashov]

Been there, done that, got the t-shirt.  Main problem I ran into is that 
(1) Super G3 detection doesn't work on many switches, and (2) even the 
ones on which it does work there is not a vendor-neutral way to pass 
that knowledge through to the terminating gateway, and (3) T.38 support 
at Super G3 speeds is lacking in most implementations at this time.

Between this and the problems you mention, it's just not worth it. 
Seriously, it's one of the least Pareto-optimal propositions in the 
entire business.  Just sell them analog lines.

I've actually managed to convert a few customers - even steadfastly 
traditional, paper-intensive ones - to using fast doc scanners + e-mail. 
  :-)

On 01/07/2010 12:47 PM, Ujjval Karihaloo wrote:

> Correct, I have been able to get around INVITE glare etc…by tweaking ATA
> configs, however the problem mainly lies in UDPTL T3/T38 signaling in
> the RTP, E.g. TAs keep sending no signal msgs to the Provider and they
> don’t sends a DIS back and it then just re-invites for G711
> Pass-though…and that never works…
>
> I have also seen FCS-BAD (HDLC frame signal) coming from the Provider
> when UDPTL data is sent.
>
> *From:* Justin Randall [mailto:jrandall at comwave.net]
> *Sent:* Thursday, January 07, 2010 10:40 AM
> *To:* Ujjval Karihaloo; voiceops at voiceops.org
> *Subject:* RE: [VoiceOps] VoIP T38 Fax reliability
>
> Faxing over T.38 from experience has certainly been a better experience
> than over G711u bypass. Of course there are some implementations of T.38
> that interoperate with each other better than others. My experience with
> AudioCodes, Linksys/Sipura, and Grandstream has been very positive.
>
> One of the common potential problems with either approach is the
> behaviour of the signaling in response to which end (caller, callee, or
> both) of the session is responsible for initiating the re-INVITE for
> T.38. When supporting wholesale customers it is not always possible to
> configure the behaviour of the ATAs/IADs and the only way to ensure fax
> will at least always be “detected” is to have one of endpoint
> gateways/ATAs/IADs detect fax as the caller and the callee. The next fun
> piece to tackle once that’s configured is to ensure that all endpoints
> properly support handling SIP 491 Request Pending response codes to
> avoid a race condition which can cause INVITE “glare” if one endpoint is
> configured to detect faxes and re-INVITE for both caller and callee and
> the other is set to detect faxes and re-INVITE on either.
>
> Regards,
>
> Justin
>
> ------------------------------------------------------------------------
>
> *From:* voiceops-bounces at voiceops.org
> [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Ujjval Karihaloo
> *Sent:* Wednesday, January 06, 2010 7:01 PM
> *To:* voiceops at voiceops.org
> *Subject:* [VoiceOps] VoIP T38 Fax reliability
>
> I know this a thorn in everyones flesh, I would like to know of
> experiences with T38 Voip Faxing. We have had good and bad. Those that
> don’t work just don’t and they don’t even want to troubleshoot and just
> switch over to an Analog line for Fax. We mostly use AudioCodes and
> Sipura T38 ATAs.
>
> Any of you folks do T38 and whats the experience like.
>
>
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops


-- 
Alex Balashov - Principal
Evariste Systems
Web     : http://www.evaristesys.com/
Tel     : (+1) (678) 954-0670
Direct  : (+1) (678) 954-0671