<br><br><div class="gmail_quote">On Tue, Dec 13, 2011 at 3:12 AM, Nathan Anderson <span dir="ltr"><<a href="mailto:nathana@fsr.com">nathana@fsr.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Monday, December 12, 2011 8:35 PM, Kristian Kielhofner <mailto:<a href="mailto:kris@kriskinc.com">kris@kriskinc.com</a>> wrote:<br>
<br>
> Recent versions of Asterisk and Freeswitch are also capable of T.38<br>
> "gatewaying" (T.30 g711/T.30 interop). However, my guess is that the OP<br>
> was interested in a pure T.38 path for its perceived reliability.<br>
<br>
</div>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 (?)...<br>

<div class="im"><br>
> My only guess is that T.38, while being more reliable in theory, suffers<br>
> from implementation bugs like anything else.<br>
<br>
</div>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!<br>

 xBuffer -- to be present that wasn't always), etc.; the list goes on.<br>
<div class="im"><br>
> That's why we still use T.38 down to our ATA devices with great success.<br>
> Our customer's DSL connections probably couldn't get past tone<br>
> detection/modem handshake with ulaw.<br>
<br>
</div>This is exactly what I'm worried about.<br><br></blockquote><div><br>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. <br>
<br>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.<br>
<br>Regards,<br>Jared Geiger<br><br>PS - Watch out for Verizon, they advertise T38 in many of their SIP responses, but don't actually support T38.<br></div></div>