[VoiceOps] T.38 termination provider?

[Nathan Anderson]

On Monday, December 12, 2011 8:35 PM, Kristian Kielhofner <mailto:kris at kriskinc.com> wrote:

> Recent versions of Asterisk and Freeswitch are also capable of T.38
> "gatewaying" (T.30 g711/T.30 interop). However, my guess is that the OP
> was interested in a pure T.38 path for its perceived reliability.  

Actually, I'm mostly worried about the last-mile, between our SBC and the end-user/ATA, where jitter and packet loss both have the most chance to creep in and wreak havoc.  We are using Asterisk, and I think up until recently, it has only supported T.38 passthrough, so end-to-end T.38 was pretty much the only option if I wanted T.38 at all on the leg of the call that exists between the ATA and the SBC.  I've had pretty good success (shockingly) in my tests with G.711u, though, so maybe gatewaying is the way to go now that it's available (?)...

> My only guess is that T.38, while being more reliable in theory, suffers
> from implementation bugs like anything else.

I can attest to this first-hand, although my impression is that most of the interop issues have more to deal with ambiguity in the spec that leads to differences of interpretation and thus to differences in implementation.  Nearly every provider with any T.38 support at all has its own set of quirks (as do the ATAs): most of them (as well as some ATAs) compute the T.38 SDP field T38FaxMaxDatagram the "wrong" way, some omit obvious parameters that should be present (FlowRoute, when it does accept the re-INVITE, often comes back with no T38MaxBitRate, which Asterisk assumes means 2400 -- can you spell S-L-O-W -- unless you reverse the order of the allowed bitrates in a particular enum in one of the source header files), I've had to develop custom patches on the Asterisk side to deal with some of these (e.g., when a firmware upgrade on an ATA introduced a "feature" that broke T.38 for us because, as a packet capture revealed, all of a sudden it "needed" an SDP field -- t38FaxMaxBuffer -- to be present that wasn't always), etc.; the list goes on.

> That's why we still use T.38 down to our ATA devices with great success.
> Our customer's DSL connections probably couldn't get past tone
> detection/modem handshake with ulaw.

This is exactly what I'm worried about.

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com