[VoiceOps] T.38 termination provider?

Kristian Kielhofner kris at kriskinc.com
Mon Dec 12 23:34:31 EST 2011


   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.

Getting back on topic, you aren't likely to have good fax results from
anything but a Tier 1 provider like Level(3). There are just too many LCR
shenanigans and who knows what else with anything less.

With that being said we've been doing T.38 on Level(3) Vector (Sonus) for
over a year. I regularly run loopback tests with multiple geographic and
provider diverse PRIs sending/receiving faxes to/from LI and ELS dids on
every Level(3) SBC.

Sending T.38 faxes to Freeswitch with T.38 regularly results in a %97
success rate. Upon complaining to Level(3) their first suggestion was to
switch to ulaw. Keep in mind this is over the public internet. I was
skeptical to say the least. Re-running the same tests regularly results in
a %98 success rate. We're able to dynamically switch between T.38 and ulaw
on a call by call basis. Repeated controlled tests have held with ulaw
consistently being about %1 more reliable.

My only guess is that T.38, while being more reliable in theory, suffers
from implementation bugs like anything else. On a solid connection ulaw is
simpler and thus more reliable. On a shaky connection between known
endpoints T.38 emerges victorious due to features such as packet
redundancy, etc.

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.

Yes, I really thumbed out this entire message from my BlackBerry near
midnight. I've lost way too much sleep from faxing over IP as it is!

--
Kristian Kielhofner
Sent from a mobile device.

------------------------------
 *From*: voiceops-bounces at voiceops.org <voiceops-bounces at voiceops.org>
*To*: Nathan Anderson <nathana at fsr.com>
*Cc*: voiceops at voiceops.org <voiceops at voiceops.org>
*Sent*: Mon Dec 12 21:59:10 2011
*Subject*: Re: [VoiceOps] T.38 termination provider?


 Slightly off topic but from spec sheet the new transcoding NUIs in the
low-end ACME SBCs (3820/4500?) in theory can handle T.38 to T.30(ulaw/alaw)
interop, so you might be able to 'wrangle' it yourself.


 --
 Peter Childs - Voice Engineer
 Internode/Agile
 Ph: 08 8228 2380 Mb: 0406 388 405 Fax: 08 8235 6801

 On 13/12/2011, at 12:26 PM, Nathan Anderson wrote:

 Hello,

New to the list.  I work for a regional broadband ISP who is looking to
also become an ITSP.

We are looking for a good SIP termination provider with reasonable rates to
all of North America that also happens to guarantee T.38 gateway support
for 100% of calls.

Currently, we are using FlowRoute.  We are happy with the service, but the
odds of us hitting a gateway (through one of their upstreams) that will
accept our T.38 re-INVITE are about 50/50...not very good.

We tried Gafachi, but that was not a good experience.  Their rate table is
all kinds of screwed-up.

The only other one I've been able to find in my searches is Alcazar
Networks.  Anybody have any first-hand experience with them who can vouch
for them as well as their T.38 support for the wholesale termination
product?

Other recommendations are also welcome, as well.  Although we may someday
go down the road of loading an LCR table into our SBC, at this point we are
looking for a single solid termination provider that will handle 100% of
our outbound call volume (a mix of voice and fax); we can fall-back to
FlowRoute as a backup solution if the primary provider goes down.

Thanks a million,

-- 
Nathan Anderson
First Step Internet, LLC
nathana at fsr.com
_______________________________________________
VoiceOps mailing list
VoiceOps at voiceops.org
https://puck.nether.net/mailman/listinfo/voiceops
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20111212/6202e466/attachment-0001.html>


More information about the VoiceOps mailing list