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
I wonder if the G.711u vs. T.38 stats change if constrained to long faxes. My experience with faxing was uniquely negative because most of it was in the mortgage industry, where every fax is at least 50 pages. Needless to say, neither method provided us with anything near a 97% success rate. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/
I had similar experience, with G711 in the core I was able to get 98% success, but as the length of the faxes grew, the reliability fell off noticeably. Of course taking that out to CPE we had to go to T.38 since there is too much dirty Internet out there to rely on in-band fax. In the end we just standardized onto T.38 since the amount of times we could keep the fax in the core was minimal. That being said, we are looking at adding the new acme NIU's to catch the 1% of situations where the final gateway and CPE cant agree on a flavor. On 12/12/2011 08:44 PM, Alex Balashov wrote:
I wonder if the G.711u vs. T.38 stats change if constrained to long faxes. My experience with faxing was uniquely negative because most of it was in the mortgage industry, where every fax is at least 50 pages. Needless to say, neither method provided us with anything near a 97% success rate.
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
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.
participants (5)
-
abalashov＠evaristesys.com -
jared＠compuwizz.net -
kris＠kriskinc.com -
nathana＠fsr.com -
ryandelgrosso＠gmail.com