[VoiceOps] T.38 termination provider?

Thu Dec 15 11:41:12 EST 2011

> What we ended up doing was capturing all faxes in our cluster with a
> hylafax server and then passing it on to the recipient.

So you are doing a store and forward on the hylafax and essentially splitting the legs of the call . . . interesting and it works with a standard ATA as well.

Robert Dawson
Voice Systems Engineer
202-349-0477(o) | 571-234-2621 (c) | 202-541-9050 (f)
rdawson at alliedtelecom.net~ www.alliedtelecom.com
1120 20th St NW Suite 500-S Washington, DC 20036

> -----Original Message-----
> From: voiceops-bounces at voiceops.org [mailto:voiceops-
> bounces at voiceops.org] On Behalf Of Brandon Lehmann
> Sent: Tuesday, December 13, 2011 11:15 AM
> To: David Hiers; Nathan Anderson
> Cc: voiceops at voiceops.org
> Subject: Re: [VoiceOps] T.38 termination provider?
> 
> We have encountered many of the problems expressed in this thread. We
> had no problem (close to 100% success rate) sending and receiving faxes
> using uLaw in and out of our server cluster; however, passing those
> calls to the customer ATA devices resulted in a large number of
> problems (25% success rate if we were lucky). No matter what we did,
> the latency and packet loss killed the handshake or dropped the fax
> part way through the transmission. After months of testing, we were
> able to blame the "last-mile" network connections.
> 
> What we ended up doing was capturing all faxes in our cluster with a
> hylafax server and then passing it on to the recipient. In the case of
> inbound, the call comes in uLaw to our cluster, is passed to the
> hylafax server which queues the fax, and then forwards it to the end-
> user ATA via uLaw. Outbound works the same way but in the opposite
> direction. Call routing for the ATA forces all calls (we tell our
> customers that they are Fax only extensions) to hylafax iaxmodems,
> hylafax queues up the fax, and then forwards it out to the unknown.
> Yes, this took a bit of scripting and playing with dialplans; however,
> the result is amazing. We are now seeing a success rate close to 99%
> (from what we can tell, the only failures are the result of network
> congestion on the user end). As such, we have ignored T.38 all together
> as we experienced more problems on the ATA side than we cared to
> handle.
> 
> We have found that our customers also love the email2fax & fax2email
> gateway we added when we implemented this service. Furthermore, they
> enjoy the fact that they can log into the web site and pull up copies
> of every fax they have sent or received. Needless to say, by fixing one
> problem, we have created an additional revenue stream in the process.
> 
> Some food for thought...
> 
> ---
> 
> Brandon Lehmann  CCNA, CCAI, CFOT, Net+, A+, Security+
> BitRadius, LLC
> 510 Court Street
> Fremont, Ohio 43420
> Email: brandon at bitradius.com
> Web: http://www.bitradius.com
> Phone: 567-255-3610 x9500
> Toll-Free: 888-608-7253 x9500
> Fax: 567-255-3611
> 
> -----Original Message-----
> From: voiceops-bounces at voiceops.org [mailto:voiceops-
> bounces at voiceops.org] On Behalf Of David Hiers
> Sent: Tuesday, December 13, 2011 1:32 AM
> To: Nathan Anderson
> Cc: voiceops at voiceops.org
> Subject: Re: [VoiceOps] T.38 termination provider?
> 
> We terminate our T38 in-house and send t30/711 to our upstream
> carriers.  It works pretty well, but it's not a panacea.
> 
> In general, we find that T38 fixes some problems, moves some problems
> from the far end to the fax/ata interface, and invents entirely new
> ones.
> 
> ++ on Alex's long fax experience.
> 
> 
> David
> 
> 
> 
> On Mon, Dec 12, 2011 at 8:53 PM, Nathan Anderson <nathana at fsr.com>
> wrote:
> > So, do T.38 only last-mile to the ATA, then dump it back into the
> audible
> > domain at our own SBC and pass it to our termination provider as a
> G.711u
> > call?  Interesting idea...I'll chew on that for a bit.  Thanks.
> >
> > -- Nathan
> >
> > ________________________________
> > From: Peter Childs [mailto:PChilds at internode.com.au]
> > Sent: Monday, December 12, 2011 6:59 PM
> > To: Nathan Anderson
> > Cc: voiceops at voiceops.org
> >
> > 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
> >
> >
> >
> > _______________________________________________
> > VoiceOps mailing list
> > VoiceOps at voiceops.org
> > https://puck.nether.net/mailman/listinfo/voiceops
> >
> 
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
> 
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops