{"id":524,"date":"2011-11-30T20:49:09","date_gmt":"2011-11-30T20:49:09","guid":{"rendered":"http:\/\/192.168.16.235\/?page_id=524"},"modified":"2020-01-03T13:51:18","modified_gmt":"2020-01-03T13:51:18","slug":"ceo-commentary-archives","status":"publish","type":"page","link":"https:\/\/commetrex.com\/?page_id=524","title":{"rendered":"CEO Commentary Archives"},"content":{"rendered":"

[vc_row css_animation=”” row_type=”row” use_row_as_full_screen_section=”no” type=”grid” angled_section=”no” text_align=”left” background_image_as_pattern=”without_pattern” css=”.vc_custom_1578057799368{padding-top: 70px !important;padding-bottom: 70px !important;background-color: #f6f6f6 !important;}” z_index=”” el_id=”ceo_commentary_archives_tabs”][vc_column]

\n\t

\n\n\t \n Telephone Numbers <\/span>\n<\/span>\n\n \n <\/span>\n <\/span>\n <\/span>\n<\/span>\n<\/h3>\n
\n
\n [vc_column_text]Telephone numbers, actually session addressing, is one of the major issues, problems, or opportunities in telecom, depending on your point of view. Along with so-called Net Neutrality, it is one of the critical battles being waged in the quest for a competitive communications market. It is a major concern to many telecom strategists because it partitions session-addressing universes: the traditional telecom universe (10-digit (E.164) numbers), SIP addressing, the Skype universe (your Skype ID), the Google universe (your G-Mail account), and so on (Yahoo!, AOL, MSN, etc.).<\/p>\n

 <\/p>\n

There is an emerging international standard, ENUM, that is modeled on the Internet\u2019s Domain Naming System (DNS). ENUM maps 10-digit telephone numbers to Internet address resources via an ENUM server.<\/p><\/blockquote>\n

 <\/p>\n

In the US, you must be a legal \u201ctelephone company\u201d to get a block of telephone numbers to assign to subscribers, Skype, Google, and AOL chose to develop their own schemes to identify a user. So, except for Google, which uses a protocol, XMPP, that supports addressing-server federation, each of these services is an addressing island, reducing the value of each network compared with its value to the user if all addresses can be reached, regardless of network. Currently, each of these network developers jealously guards their control of addressing on their network.<\/p>\n

 <\/p>\n

Ten-digit telephone numbers that are within the North American numbering plan are administered by NeuStar, Inc, the North American Numbering Plan Administrator (NANPA). Assignments are made based on the central office designated by the carrier, which is hopelessly antiquated for the Internet age. The carriers have an interest is keeping this system in place for as long as possible since it allows them to exert some degree of market control (they own the numbers). (Actually, with number portability, you own the number, but it can only be transferred between telcos.)<\/p>\n

 <\/p>\n

Not only is this system exclusive, it is country-specific, and, it is specifically designed to support the legacy model of the country-specific telecom monopoly. The ITU, an agency of the UN, administers the country codes. However, Skype, for example, wasn\u2019t and isn\u2019t interested in national borders. Except in a few countries, the Internet is a global platform, and Skype needed a global session-addressing scheme. It had one sitting on the shelf from the company\u2019s Kazaa origins, and it used it.<\/p>\n

 <\/p>\n

However, there is an emerging international standard, ENUM, that is modeled on the Internet\u2019s Domain Naming System (DNS). ENUM maps 10-digit telephone numbers to Internet address resources via an ENUM server. The ENUM server provides the requesting client (for example, a SIP proxy) with the stored information, such as the subscriber\u2019s VoIP SIP address, fax address, e-mail address, or other resources, such as secondary addresses, to services to which the number\u2019s owner has subscribed. The network operated by Telecom Austria (which uses Commetrex\u2019 BladeWare), has had ENUM in commercial operation since December 2004.<\/p>\n

 <\/p>\n

Although ENUM, especially carrier-owned private ENUM, still pays its respects to the established order, the extensible nature of the information (Internet resources) provided by ENUM servers can effectively decouple the location of value-adding services from the provision of transport. So don\u2019t expect carriers to warmly embrace ENUM, as it makes service invocation seamless.<\/p>\n

 <\/p>\n

There\u2019s been plenty of discussion lately in the US about how to foster innovation. All the US Congress needs to do to insure that market forces in telecom will continue to support innovation is to ensure an open, national ENUM system similar to the one in Austria.<\/p>\n

If you want to know more about what Commetrex is doing to \u201cMake FoIP Work,\u201d give us a call.[\/vc_column_text] <\/div>\n<\/div>

\n\n\t \n We Make FoIP Work! <\/span>\n<\/span>\n\n \n <\/span>\n <\/span>\n <\/span>\n<\/span>\n<\/h3>\n
\n
\n [vc_column_text]I recently spoke with a vice president of engineering at a large enterprise-fax vendor. Our customer wanted to know if we had a program to establish interop certifications with IP carriers. Prior to that I had spoken with a product-management director at another large enterprise-fax server vendor (actually, our largest customer), and he wanted to know if we had a certification lab for various gateways. I didn\u2019t have good answers to either question. We just don\u2019t have the resources and scale to make a reasonable dent in the massive numbers of carriers and gateway vendors.<\/p>\n

 <\/p>\n

Now that enterprises are extending the reach of their IP networks by connecting directly with IP carriers and SIP trunking, we are confronted with challenges of a different sort. The front lines of the FoIP wars have moved.<\/p><\/blockquote>\n

\"\"<\/p>\n

 <\/p>\n

I imagine that with all the OEMs we have out there, nearly all of the carriers and gateways have been covered by now. And, on a practical basis, most of the carriers use Commetrex\u2019 T.38 technology in their gateways. Moreover, most of the value-adding service networks use Commetrex-based fax media servers. And then there was our hugely successful T.38 Interoperability Test Lab, which, in 2002-2004, made Commetrex\u2019 T.38 the industry\u2019s T.38 interoperability benchmark. But if you\u2019re looking for certifications, other than our own, we don\u2019t have them.<\/p>\n

 <\/p>\n

Now don\u2019t get me wrong, I understand the marketing value of these certifications, especially when the \u201cother guy\u201d has them, and he does. But with BladeWare\u2019s six years of field experience, we have found that, on a practical basis, their importance is secondary to the question of performance and transaction success in carrier networks. This is because certifications are done in near-lab-like environments, but the challenges come in real-life networks.<\/p>\n

 <\/p>\n

In previous letters I\u2019ve noted that the industry\u2019s deployment of FoIP is proceeding in phases. Phase I, which extended from T.38\u2019s publication in October 1998 to just a few years ago, was characterized by the need for interoperability between intra-enterprise network elements, such as between an ATA and a gateway. These problems were relatively easy to solve since both manufacturers were usually eager to solve these problems.<\/p>\n

 <\/p>\n

But now that enterprises are extending the reach of their IP networks by connecting directly with IP carriers and SIP trunking, we are confronted with challenges of a different sort. The front lines of the FoIP wars have moved. Yes, sometimes we encounter rear-guard harassment of registration, authentication, and configuration problems, but they are usually dispatched with a good read of a Wireshark capture. Today\u2019s real battles go way beyond simple interop and equipment configuration to getting a call from an ATA or an IP-based fax server to a PSTN-connected fax terminal after transiting multiple IP-carrier networks.<\/p>\n

 <\/p>\n

We are fully engaged in \u201cmaking FoIP work.\u201d Today, we are working with carriers to correct the problems within their networks that are keeping FoIP from achieving the transaction success rates of PSTN fax. If IP is going to replace TDM, it has to happen, and Commetrex is leading the way.<\/p>\n

 <\/p>\n

If you want to know more about what Commetrex is doing to \u201cMake FoIP Work,\u201d give us a call.[\/vc_column_text] <\/div>\n<\/div>

\n\n\t \n Innovation Grows The Industry <\/span>\n<\/span>\n\n \n <\/span>\n <\/span>\n <\/span>\n<\/span>\n<\/h3>\n
\n
\n [vc_column_text]We like to think of Commetrex as the leading innovator of fax technology without qualification. We\u2019re not the biggest, but when it comes to innovation, we\u2019re the best. Consider: In the mid-90s we produced the industry\u2019s first software fax add-in product, by adding fax to the NMS voice boards. In 2000, we invented TerminatingT38. Then, there was Multi-Modal Terminating Fax, which supported both T.38 and G.711 IP-fax termination. In 2002, it was the T.38 Interop Lab. And now, we believe we\u2019ve solved a huge problem that\u2019s been plaguing the industry ever since enterprises began to use SIP trunking and direct SIP peering for their IP-fax servers, gateways, and ATAs. We believe this to be a breakthrough in IP-based fax reliability.<\/p>\n

 <\/p>\n

Phase II, the use of FoIP for carrier-based calls, got underway a few years ago as some of the major IP carriers, such as XO Communications and Global Crossing, began to offer T.38 service agreements to enterprise customers. The VoIP service providers began to offer SIP trunking and direct SIP peering, obviating the need for enterprise gateways. And suddenly, FoIP became a big problem for the fax-server vendors and their enterprise customers.<\/p><\/blockquote>\n

 <\/p>\n

In partnership with Copia International, a noted vendor of mission-critical fax-broadcast servers and BladeWare user, Commetrex was able to achieve broadcast success rates on a par with those obtained with a multi-line intelligent fax board. We\u2019ve even applied for a patent. The new technology works entirely within the framework of the SIP and T.38 standards. We have done extensive A-B testing with VoIP service providers and IP carriers and have found that servers that only support T.38 have an outbound fax-call completion rate that is five-percent lower than BladeWare equipped with G.711 pass-through support and Smart FoIP.<\/p>\n

 <\/p>\n

The ITU\u2019s T.38 recommendation was released in 1998, and, for 10 years, what we call T.38 Phase I, the use of T.38 was relegated to intra-enterprise applications, so interop and transaction reliability were fairly easy to achieve since the user controlled all the equipment. The problem has to do with enterprise user\u2019s recent push to use FoIP (fax over IP) beyond the confines of enterprise gateways and analog telephone adapters (ATAs). There was little choice in the matter since almost no carriers supported T.38, and what we call \u201cG.711 pass-through fax\u201d, where the fax call is, essentially, treated as a voice call, was found to be too error-prone over the public Internet. But now we\u2019re finally entering \u201cPhase II\u201d of T.38 deployment Phase II, the use of FoIP for carrier-based calls, got underway a few years ago as some of the major IP carriers, such as XO Communications and Global Crossing, began to offer T.38 service agreements to enterprise customers. The VoIP service providers began to offer SIP trunking and direct SIP peering, obviating the need for enterprise gateways. And suddenly, FoIP became a big problem for the fax-server vendors and their enterprise customers.<\/p>\n

 <\/p>\n

Instead of working with the more-accessible gateway manufacturer, the business user had to try to work with the less-accessible service provider and IP carrier when he found that, for some reason, the reliability of making a fax call was well below the standards established by old reliable TDM fax over the PSTN. The problem has become so bad that many businesses still use the PSTN for all faxing, even though the enterprise has moved to 100-percent VoIP for voice. The reasons for this state of affairs were many. Some vendors even blamed the T.38 recommendation for the problem. But the industry has responded with improvements in T.38 interoperability and broader deployments of T.38-capable networks. Even so, problems placing calls from ATA-connected fax terminals and T.38-based fax servers persist.<\/p>\n

 <\/p>\n

According to Steve Hersee, CEO of Copia International, \u201cOur broadcast-fax customers, looking for the promised saving of FoIP, have been asking for FoIP-based fax broadcast for the last few years. So, we ran some trials with our CopiaFacts server running on Commetrex\u2019 BladeWare FoIP platform. Our first tests were with BladeWare supporting both T.38 and G.711. We were disappointed as the completion rates were 15-percent below that of our PSTN fax boards. Then, the Commetrex engineers dug into the problem and found that many of the fax sessions failed when BladeWare accepted the network\u2019s SIP re-invite to go from G.711 to T.38. After several weeks of testing, retesting, and head scratching, they found that the re-invites from our carrier partners were often arriving so late that the server and the PSTN-connected fax terminal were well into the G.711-based T.30 fax transaction, with the switchover to T.38 effectively killing the session. This was proven when we disabled G.711 support in BladeWare and, suddenly, the success rate shot up 10-percent.\u201d<\/p>\n

 <\/p>\n

But we still weren\u2019t satisfied. We want BladeWare to not just be nearly as good, but as good as the traditional fax server for connection rates. And in T.38-only mode, we still had five-percent of the sessions failing when the re-invite was so late in arriving that the called terminal would just give up waiting for a response in G.711 mode. So, we went to work and developed our patent-applied-for T.38 fax-server technology that solves that problem by allowing the fax to complete in G.711 mode if the T.38 re-invite arrives too late.<\/p>\n

 <\/p>\n

And our users don\u2019t need to be concerned with the G.711 pass-through session. In much of the world our carrier friends have virtually eliminated packet loss, leaving PCM-clock synchronization as the chief concern. But even that works because of Commetrex\u2019 proprietary \u201csmart buffering\u201d technology for G.711 mode. It eliminates PCM clock synchronization as a source of error in G.711 pass-through calls, which is the reason for longer faxes failing.<\/p>\n

 <\/p>\n

With this latest improvement in the state of the art, we believe our innovation creds remain intact.[\/vc_column_text] <\/div>\n<\/div>

\n\n\t \n Pardon The Expression: \u2018A New Paradigm?\u2019 <\/span>\n<\/span>\n\n \n <\/span>\n <\/span>\n <\/span>\n<\/span>\n<\/h3>\n
\n
\n [vc_column_text]If you read our Commetrex Outlook newsletter, you know that BladeWare now supports the entire Sangoma product line of PCI and PCI Express PSTN-interface boards. Suddenly, Commetrex has the industry\u2019s broadest line of products for the enterprise-fax OEM. \u201cBut how can that be?\u201d you say. \u201cThe incumbents have spent decades developing their boards and HMP fax platforms.\u201d Well, yes, but they were unable to take advantage of the industry\u2019s evolution, which is proceeding along the same path blazed by the PC industry.<\/p>\n

 <\/p>\n

So why is this happening now? One answer is HMP. Because Sangoma developed its hardware product line to meet the need for PSTN interfaces created by HMP IP-PBXs, such as Asterisk, there was no need for DSPs or media processing except for, possibly, echo cancellers. This had the effect of partitioning Sangoma\u2019s product-development investment onto PCM-interface boards, while Commetrex was investing in telephony middleware and media-processing (BladeWare).<\/p><\/blockquote>\n

 <\/p>\n

Imagine, for a moment, how inefficient it would be if Dell, Toshiba, and HP had to develop hard drives and micro-processors in order to come out with a new laptop. That would be ridiculous given today\u2019s margins, time-to-market, and ROI pressures. But when I was a young engineer, that\u2019s exactly what IBM had to do, and it\u2019s what the incumbent fax players had to do back in the \u201890s. But it\u2019s not what Commetrex has to do today\u2013perhaps yesterday, but not today.<\/p>\n

 <\/p>\n

When we began developing our fax technologies back in the mid-\u201890s, there were no open-architecture DSP boards to run our modems. And forget about HMP, the MIPS just weren\u2019t there. As a cash-strapped start-up we needed to get to market fast. What to do? The answer we came up with was to prevail upon our good friends at NMS (where I had been VP, Marketing and Sales) to give us access to their embedded code (Remember the VBX boards? Probably not.) so we could turn their voice boards into voice-fax boards by adding our newly developed fax-modem software. This produced our first product, MultiFax for VBX, which, in 1993, was the industry\u2019s first third-party software add-in product. NMS later licensed the software, which is where NaturalFax came from. We went on from there to become a major licensor of fax technologies to carrier, test-equipment, and semi-conductor OEMs, while we were busy developing BladeWare, our HMP telephony platform.<\/p>\n

 <\/p>\n

But we never forgot the lesson of how powerful a market force technical specialization could be.<\/p>\n

 <\/p>\n

So, in early 2009, following some major design wins for BladeWare in the enterprise-fax OEM market, it became obvious that our OEM customers wanted more. They were enjoying the benefits of BladeWare\u2019s high function and performance at an unbeatable price, and wanted the same in applications where PSTN connectivity was required. BladeWare had been designed to readily support hardware as both PSTN interfaces and media-processing resources, so we knew if we could find a product line that met our requirements it would be simple to add it to BladeWare.<\/p>\n

 <\/p>\n

So, what were those requirements?<\/p>\n