[VoiceOps] T.38 termination provider?

[Jared Geiger]

On Tue, Dec 13, 2011 at 3:12 AM, Nathan Anderson <nathana at fsr.com> wrote:

> 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 -- t38FaxMa!
>  xBuffer -- 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.
>
>
If you want to get access to carriers such as Level3, Global Crossing,
Earthlink, Paetec, Intelepeer, and Peerless easily for T38, I would suggest
looking at SIPRoutes. With them you can build your own LCR with carriers
that fully support T38. We have had great success with this approach.

This increases our cost a bit, so what we sometimes do is offer the
customer a prefix to dial if they want T38 carriers and dial normally for
everything else. We also use ATAs that can add the prefix on the "second
line" but dial normally through the first line. That way the end user
experience is still the same of dialing 1+NPA-NXX-XXXX.

Regards,
Jared Geiger

PS - Watch out for Verizon, they advertise T38 in many of their SIP
responses, but don't actually support T38.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20111213/4fb240ed/attachment-0001.html>