The Commetrex Outlook | November 2014

Finally! Smart FoIP is in BladeWare

Smart FoIP, you may recall, takes care of the top-two causes of FoIP failures-one each for G.711 and T.38 sessions. The big problem for G.711 sessions is that without clock synchronization, as you have on the PSTN, a long-enough fax will cause the gateway’s jitter buffer to either underflow or overflow, and, either way, it’s bye-bye fax session. And for sessions where the off-ramp gateway sends a T.38 reINVITE, the session will fail if the calling gateway accepts the reINVITE after the two endpoints have reached what we call the “point of no return” while still in G.711 mode.

BladeWare has had the G.711 clock-sync fix forever. And now it has the late T.38-reINVITE fix, making BladeWare the only fax server in the industry with this patent-pending technology that makes FoIP capable of PSTN success rates.

Want to learn more? Go here to get a copy of our white paper that gives you the story of this amazing discovery.

Introduction To BladeWare (Past, Present, Near-Term Future)

Twenty-four years ago, we founded Commetrex to develop an advanced value-adding telephony platform. Back then we called it Open Telecommunications Framework®. It had a PCM highway and telephony boards, but today it’s all software (HMP) and we call it BladeWare. It supports fax send-receive and we are well into the addition of voice play-record. We’ll move from there to add a voice browser to take advantage of our excellent BladeWare VXi interpreter and BladeWare Studio VXML app-gen tool. We hope to have all this added in 2015.

As the first HMP fax platform to hit the market (in 2002), BladeWare helped define the product category. By that time, we had invented terminating T.38 (2001), and our fax technologies (T.38, T.30, fax modems, etc.) were being used by major industry OEMs such as Acision, Broadsoft, Convedia/Radisys, Metaswitch, Movius, and others. So all we had to do was invest dozens of developer years in the BladeWare framework, and then integrate our years-in-the-field media and protocol technologies. In 2009 we added T.38 version 3 with V.34, and this month we are adding Smart FoIP®.

Today, BladeWare is the platform of choice for dozens of service providers, equipment and enterprise-fax-server OEMs.

In addition to adding voice play-record, we are enhancing BladeWare’s configuration, maintenance, management, and accounting features to make it an even better choice for the service provider. That project will produce several releases over the next five quarters.

Sometimes, Playing Dumb Helps

Apparently, there are some situations where the user would rather the call fail, than for it to attempt G.711 as the media transport for an FoIP call. In that case, they will either put T.38 only in the initial SIP INVITE (not recommended for carrier networks), or put G.711 and T.38 in the initial INVITE, but only send CNG (calling tone) in G.711 as, essentially, a recorded message while waiting for the T.38 reINVITE. The idea is for the calling terminal to never send the DCS in G.711 mode, least the called terminal stop sending DIS (its capabilities message) and wait on the modem training, which, of course, will never come. Playing dumb like this will force the call to be T.38 or be nothing at all.

So, how long will the calling server wait? Over 35 seconds, which is a long time in networking terms. If the reINVITE comes, the calling server will accept it and switch to T.38. If, for some reason, the off-ramp/called gateway(s) did not or could not send the reINVITE, the call fails.

Want to talk FoIP in SIP networks? Give us a call at 770-449-7775 and press 1.

RFC 6913 Support Now In BladeWare (Release 2.6.0)

As you may know, Smart FoIP’s patent-pending technology corrects the two biggest Fax over IP (FoIP) problems inherent in SIP-based carrier networks: no more late-T.38 reINVITE problems; no more PCM clock-sync problems causing G.711 pass-through failures. But what about the third big problem: less-than-optimum call routing by the carriers?

You may be aware that in carrier networks, nearly always a fax call begins as a voice call, typically G.711. Other than V.34 calls, the called gateway is responsible for detecting that the called endpoint is a fax terminal and to send a T.38 reINVITE to the calling gateway or server. Obviously, all of this happens after the call has been routed. So, if you’re a service provider or carrier, how can you take control of the routing to get beyond that “less-than-optimum call routing”? To do so, you must determine which calls are likely to be a fax call, and route the call over an IP-only route if possible, at least until it arrives in the called terminal’s local area. And that’s not always simple since the access provider is rarely responsible for end-to-end routing.

But a good start is for the service provider to provision the subscriber’s fax number for that special routing. Often, a subscriber is more than happy to pay a little more for a FoIP trunk that performs since his alternative is an even-higher-priced POTS line. Another approach is for the service provider to apply a heuristic algorithm to the originating point of inbound calls. (If it looks like a duck and walks like a duck, it’s a fax call.)

Yet another way is to support RFC 6913, which BladeWare now does. It turns out that there are IETF RFCs, such as RFC 3840 and 3841, that allow a caller to express routing preferences to the routing entities by using IANA-registered media-feature tags in the SIP Invite. But there was a problem: there was no media-feature tag for “fax” that could be used in the SIP-INVITE header that was registered with the IANA. The solution is the IETF’s RFC 6913, which defines the “SIP.fax” media-feature tag and registers it with the IANA, allowing the originating SIP entity to declare that it prefers a “fax-friendly” route for the call.

You should use a combination of these techniques since RFC6913 is not widely deployed. And you can take matters into your own hands and only deploy fax servers that support RFC6913, then route those FoIP calls over proven routes.

We would be glad to discuss this and any other FoIP issue with you, simply call Commetrex at 1-770-449-7775, and press 1.

The MX-8 Is Coming!

You may be aware that NetGen Communications, our sister company that produces and markets Smart ATA to ITSPs and their channel, is partnering with New Rock Technologies (Shanghai) to produce additional products needed by the ITSP. And next to market is the MX product line of access and trunking gateways.

These gateways solve a wide range of enterprise application problems, such as PSTN access for Lync, and include models from four-to-120 ports. But today, they don’t have Smart FoIP, but we’re changing that. First up is the MX8, offering various combinations of station and office interfaces totaling 4 or 8 ports.

But here’s the thing: the 4-port unit lists for only $190 and the 8-port for $295. That means that if you have a BladeWare system that needs PSTN connectivity today but FoIP tomorrow, you can do it without add-in boards. Just drive the MX8 with the FoIP BladeWare. Including Smart ATA in the mix, you have 2-, 4-, 8-port PSTN interfaces for around $50 per port. And you don’t have to give up V.34 because it’s supported by BladeWare, Smart ATA, and the MX8.

When the user is ready, to cut the cord and move to FoIP, just remove the gateway.