The New Rock Cloud is one of our major development projects. However, item 1, below, is now deployed and being used by Smart ATA® and the MX8A, if enabled when provisioned. Item 2 will follow in Q3.The New Rock Cloud will:
Feedback from our users gives us consistently high marks for features, reliability, value, and aggressive support. Now, with our cloud services, our goal is to add ease-of-installation, provisioning, and maintenance to that list. But what about number 4?
Our OM IP PBXs and WROC wireless PBXs give our channel partners the opportunity to provide a unique value contribution to their customers with the REST API included with these products. Please see the article “Introduction: The Telephony Channel and the Long Tail” in the July 2014 issue of the NetGen Channel. The fourth item listed above supports the provision of the Web Services utilized by the channel partner’s solution. Of course, there are many Web Services currently available, but this allows our channel partner to be the provider of Web Services for his solution and even for other channel partners to leverage, if so desired.
As you may know, HD voice requires higher-bandwidth codecs than the antiquated 4,000 bps sample rate used in POTS. So HD voice usually requires a call route without PCM segments. This means that HD voice service providers and carriers must be deliberate in route selection, probably requiring that legacy carriers using least-cost routing be excluded from the route, instead using so-called “over the top” routes. Well, if you thought that this would get around to FoIP, you’d be correct. You see, FoIP and HD voice share many of the same routing requirements.
The SIP Forum’s FoIP Task Group spent three years testing FoIP in international calls and determined that for FoIP success rates to approach those of the PSTN something must be done about the routing problem. The usual approach involves trying to find fax-friendly call routes.
One of the results of the SIP Forum’s testing is RFC6913, which supports the addition of a fax media-feature tag to the SIP INVITE’s header, allowing the on-ramp routing entity to select an appropriate initial route and hope that the downstream carriers do the same.
However, the introduction in the RFC misses the point. It states that the purpose of the recommendation is to help prevent routing the call “inadvertently to SIP user agents (UAs) that are not fax capable.” But the real value of RFC6913 is to allow the provider to actively select FoIP-capable call routes. We’ve added support for RFC6913 to Smart ATA® and the MX8A gateways. But, aside from NetGen’s efforts, there has been little attempt by the SIP Forum or the rest of the industry to market the use of the recommendation, so don’t count on it being used in routing decisions.
Although there is little uptake of RFC6913, some carriers are aggressively going after the HD voice-routing problem in various ways. One of these is to use HD voice route brokers that federate HD voice qualified routes. Another approach is for large carriers to agree on interop standards and bi-laterally federate. But these approaches rely on the foreknowledge that the originating terminal is an HD-voice terminal, and this is not always possible with fax without the adoption of RFC6913.
There is another approach to improving fax success rates beyond what is available with NetGen’s Smart FoIP®. It involves using various techniques to eliminate any carrier routing until the PSTN is reached. This can be effective until the PSTN goes away.
One approach is to use the open Internet to get the call to the provider’s gateway. The call is then sent directly to the incumbent PSTN provider, virtually eliminating any chance that carrier routing is going to mess things up. But it is real-time fax (no store-and-forward) and it is FoIP, at least initially.
Another approach (which is the choice of our service provider) is essentially the same as the one above, but instead of the open Internet, they build private metro IP networks, each with gateways that usually send the call to the PSTN incumbent, avoiding uncontrolled IP routing.
If you’ve read previous issues of the NetGen Channel, you know that Smart FoIP eliminates the top-two problems with FoIP, but this article has been about the number-three problem—the carrier-routing problem, and it accounts for the bulk of our costs since we don’t charge for our support. But we hope that this article will expose you to some of the considerations.
Want to talk about it? Give us a call at 770-449-7704.
The vendors behind all three of these products claim that their products can get an image file from a sending fax terminal to a receiving fax terminal with a high degree of reliability. And we should point out that all three products work well; they just perform entirely different functions. They are totally different. If you’ve ever wondered how they are similar and different, read on.
First, let’s look at what each of the three products (Smart ATA, FAXXBOCHS, and FaxBack’s HTTPS) are designed to do. What are these different products, and what is their basic function?
Smart ATA is a classic full-function voice-fax ATA that is designed to perform the same basic real-time voice-to-voice and fax-to-fax functions as ATAs from Cisco and Grandstream, for example. So, Smart ATA enables legacy voice stations and fax terminals to be directly connected to SIP trunks and routed over IP networks by ITSPs and carriers. The other products do not. And, you might have noticed, we claim that Smart FoIP eliminates the top-two reasons that FoIP transactions all too often fail, but we do so all within the fax standards.
FaxBack HTTPS is not real-time fax. According to a Markman ruling (which defines terms used in IP cases), the US District Court of Central California ruled, essentially, that a fax is an image exchange between two terminals governed by the T.30 fax protocol. (T.30 is the ITU standard that defines how the sending and receiving computers operate in a fax transaction.) This means that with FaxBack’s approach, a fax is exchanged between the fax terminal (CPE) and the AudioCodes “ATA” (typically, a distance of two feet). Using HTTPS—not a fax protocol–the image data collected by the AudioCodes device are sent to a hosted server, which assembles the image file (a TIFF-F) and sends it to the intended recipient (that part is a second fax between the server and the destination terminal).
So, FaxBack is a proprietary store-and-forward fax service that requires a proprietary on-premises device produced by AudioCodes and a hosted server by FaxBack (or a third party) to send the image file onward.
Key considerations are that this is a fully proprietary (patented) non-standard architecture with higher costs than industry-standard approaches mainly due to the hosted server. In addition to the proprietary equipment, there is a monthly fee for the service. No SIP trunks are involved.
FAXXBOCHS is also not real-time fax. It requires a PC-based on-premises fax sever that communicates with hosted systems that are required to complete the transaction by sending the image file onward to the recipient. This is similar to the FaxBack system, but no HTTPS is involved. No SIP trunks are involved. And, as with FaxBack, there is a monthly service fee that essentially eliminates the price advantage real-time SIP-trunk-based fax has over POTS.
Conclusion: While Smart ATA is a standards-based mainstream ATA that just happens to make FoIP work due to its Smart FoIP special sauce (patent-pending), FaxBack and FAXXBOCHS are specialized higher-priced store-and-forward systems.