The Results are In! Smart FoIP® Does the Job
How Does GrandStream Handle Late T.38 reINVITEs?
We’ve Tried to Explain the Technology Behind Smart FoIP®
Channel Portal
In A-B testing against industry-leading ATAs, Smart ATA®, with Smart FoIP, shows why it sets the standard for FoIP performance.
Who cares about fax…or, ATAs for that matter? We do! So much so, that we developed full-function voice-and-fax ATAs that include our patented technology that eliminates the top-two problems with FoIP, allowing you to get rid of your subscriber’s POTS for fax.
But now, rather than continue to talk about the technology behind Smart FoIP, we decided to put Smart ATA to the test in a bake-off with industry-leading ATAs from Cisco and GrandStream. The tests show that Smart ATA’s exclusive technology puts it way ahead of the competition. Want the details? Click here for the Cisco SPA112 report; click here for the GrandStream HT-701.
By partnering with New Rock Technologies for the development of the Smart ATA and the MX series of gateways, we are able to provide cost-effective answers to the industry’s FoIP problems. Your customers still have their legacy devices, and this can be your ace in the hole to close that VoIP sale.
If you are interested in learning how to bundle your service offerings with quality ATAs and gateways that increase customer satisfaction, increase your revenues, and decrease costs, then you should click here.
We have a partner program that is your answer.
By way of review, Smart FoIP® eliminates the top-two problems with FoIP—one with the SIP-to-T.38 transition and the other with G.711 pass-through. We found that the Cisco SPA112 mutes the RTP stream from the fax terminal when the ATA places a SIP fax call. This is done to allow the ATA to keep the two machines from advancing the T.30 protocol as it waits for a T.38 reINVITE. If it doesn’t arrive, the fax fails.
The T.38-related problem (it’s not a T.38 problem) has to do with the transition from a G.711voice call to a T.38 fax call. All too often, the switchover (SIP reINVITE) is delayed by the carriers so much that if it’s undertaken (or accepted) by the gateways or servers it will actually kill the fax session. In some networks this will happen on up to 10% of the fax calls. Some in the industry call it “T.30 bleed-through”. We discovered all this in extensive testing performed in 2009. We recently ran some A-B tests to compare Smart ATA’s performance with Cisco and GrandStream ATAs so you can see the difference—actual performance versus theory.
We compared Smart ATA®, equipped with Smart FoIP, with the HT701. It’s pretty easy for us to do since our BladeWare server has a parameter that controls the delay from the initial G.711 200 OK to its reINVITE to T.38 when it’s the receiver. See below.
The results were as expected. We caused BladeWare to delay its reINVITE to T.38 to between 1-and-45 seconds. Smart ATA succeeded 100% of the time by refusing T.38 reINVITEs beyond the caller’s DCS, thereby continuing in G.711 mode.
Unlike the Cisco SPA112, GrandStream implements T.38 as recommended by the SIP Forum’s FoIP Task Group. That means the caller’s initial INVITE lists G.711 as its first media (m=). The transition to T.38 is dependent on the off-ramp/called gateway issuing the T.38 reINVITE. As with nearly every other ATA/gateway in the industry, this means the HT701 is exposed to the late-T.38-reINVITE problem.
All calls were successful with delays of two and four seconds. Nine out of 10 failed at 6 seconds; all succeeded at 8-11 seconds; all failed at 12 seconds. So, what does this mean? Why did it fail at 6 seconds and then begin to work for longer delays, only to fail again at 12 seconds?
It’s a little complicated, but the failures at 6 and 12 seconds were predicted by Smart FoIP. The successes between 6 and 11 seconds are due to there being a chance that the transition from G.711 to T.38 can occur at a time when shutting down the RTP stream and making the next event T.38 based can work out and the call continues. This will vary in the field. Of course, the unit failed for all delays beyond 12 seconds.
Want to talk about these results? Give us a call at 770-449-7704 and press 1.
But in order to understand the technology of the Smart FoIP® patent you need to know a fair amount about SIP signaling, T.38, andT.30. But this detailed knowledge is not required to understand the effects of the technology in eliminating the top-two problems with FoIP—one with the SIP-to-T.38 transition and the other with G.711 pass-through.
The T.38-related problem (it’s not a T.38 problem) has to do with the transition from a G.711voice call to a T.38 fax call. All too often, the switchover (SIP reINVITE) is delayed by the carriers so much that if it’s undertaken (or accepted) by the gateways or servers it will actually kill the fax session. In some networks this will happen on up to 10% of the fax calls. Some in the industry call it “T.30 bleed-through”. We discovered all this in extensive testing performed in 2009. We recently ran some A-B tests to compare the performance of our Smart ATA® equipped with Smart FoIP with Cisco and GrandStream ATAs so you can see the difference—actual performance versus theory.
The first test was to compare Smart ATA with a Cisco SPA 112’s late-reINVITE handling with that of Smart ATA’s. It’s pretty easy for us to do since our BladeWare server has a parameter that controls the delay from the initial G.711 200 OK to its reINVITE to T.38 when it’s the receiver. See below.
The results were as expected. We caused BladeWare to delay its reINVITE to T.38 to between 1-and-45 seconds. Smart ATA succeeded 100% of the time by refusing T.38 reINVITEs beyond the caller’s DCS thereby continuing in G.711 mode.
But we were surprised when Cisco succeeded up to 40 seconds or so. “How could that be!” we exclaimed. It turns out the Cisco SPA112 with April 2015 firmware was using what we call “T.38 or die.” This means that if a T.38 reINVITE never arrives, the session fails. If it’s going to arrive, it will nearly always do so within 45 seconds, which is the usual T.30 timeout (T-1) to establish a fax session between the two endpoint terminals. But not all networks support T.38, and some that do, don’t do so for every call. So those calls would fail 100% of the time.
Here’s the way they implement T.38 or die as the caller: First of all, Cisco mutes The RTP/G.711 stream from the calling endpoint in order to keep the two terminals from moving from initial T.30 negotiations to image-transfer. The called terminal will continue to transmit its capabilities (DIS) until T-1 timeout. It then disconnects. But if the T38 reINVITE does arrive prior to that, the call will usually succeed. So, when the reINVITE never arrived, the call still took 50 seconds or so even though the entire image would be transferred in 30 seconds if the reINVITE arrived in a timely manner.
Now, we did try our best to see if there was a way to configure the SPA112 to operate in a more traditional mode. To NetGen, that means the caller’s initial INVITE lists G.711 as its first media (m=). The transition to T.38 is dependent on the off-ramp/called gateway issuing the T.38 reINVITE. (If you know how to configure the unit for this, please let us know.) Also, you can configure the unit to issue the T.38 reINVITE as the caller or to simply put only m=T.38 in the initial INVITE, these will result in success provided the network will accept this…many do not, especially those that don’t support T.38 at all.
And what about the GrandStream HT-701? Stay tuned. We’ll tell you about that in our next NetGen Channel newsletter as it would have made this issue too long to include it. Can’t wait? We’ve already written the article, so shoot us a request and we’ll send it to you.
NetGen Communications, in partnership with Commetrex Corporation and New Rock Technologies, has launched the Channel Portal for NetGen channel partners to facilitate sales and support of the entire NetGen product line. The Web portal allows ITSPs, resellers, agents, and distributors to have convenient access to the resources required to address the needs of the SOHO and small-medium business (SME).
This password-protected portal allows our partners access to quality resources and tools designed to help implement new programs and extend product and service offerings to customers and prospects. Within this portal are tools that will allow NetGen channel partners to generate and receive leads and increase revenue.
In a commodity market, such as ATAs and gateways, it is essential to provide the resources that enable NetGen channel partners to differentiate the NetGen products from others. These resources explain how Smart FoIP® provides an advantage over other products on the market, including those of the current market leaders.
In addition to all product documentation, the NetGen Channel Portal contains sales presentations, special pricing requests, quick access to commission updates, and order status.
Smart FoIP is one technological component of the NetGen product line that defines the next generation in voice-fax gateways, and offers full-function voice-fax ATAs and gateways with FXS and FXO capability. This patent-approved technology finally makes FoIP calls as reliable as PSTN fax calls.
The line of ATAs and gateways offered by NetGen combines Smart FoIP technology, and NetGen channel partners can use the information contained in the NetGen Channel Portal to explain how these products can solve the problems of carrier routing, and offer a complete IP solution to their customers.
Carrier routing has been identified as the source of many of the FoIP failures customers experience. The number-one problem solved by Smart FoIP is late-T.38 reINVITEs, which only happens with carrier-routed calls. If providers avoid carrier routing, Smart FoIP’s primary benefit goes from solving the late-T.38 reINVITE problem to making G.711 pass-through calls work as well.
Smart FoIP is a big step in the right direction, and carriers must adopt the reality that fax calls must be routed as fax calls…no IP-TDM/PSTN-IP…only IP routes that have been tested for FoIP “friendliness.” The definitive way to make that happen is for service providers to pitch in and insist on the adoption of RFC6913.
Request More Information HERE