BladeWare Studio Server

Commetrex is known for providing fax-related products to the telecom OEM, reducing development cost and time to market. But our OEMs would like to derive the same benefits for voice applications, and now they do.

It’s not well known, but we’ve been shipping BladeWare VXi, a commercial edition of OpenVXi, the industry’s most popular VXML interpreter, for the last few years. BladeWare VXi delivers 3-5 times greater port density than the open-source version.

And then there’s BladeWare Studio Client, a drag-and-drop VXML script-generation tool developed for the OEM. It’s white-label ready, extensible, and produces server-agnostic VXML scripts, so it can be used with the OEM’s preferred server. However, not all OEMs have a VXML server. But now, with the announcement of BladeWare Studio Server, they do.

BladeWare Studio ServerCommetrex BladeWare Studio Server works in conjunction with Studio Client to provide:

  • One-click publishing from the App Center Client
  • Access and open previously published applications from the server
  • Application versioning
  • Zero-downtime publishing; in-progress calls are not affected
  • Pre-packaged interfaces to back-end sources
    • SQL databases
    • POP/IMAP email servers
    • HTTP-based XML communication
    • Web pages
    • Flat text files

Studio Server does not require that you know VXML, SRGS, SSML, or any of the other standard languages that are generated from the client. With BladeWare Studio, you need not keep up with subsequent versions of each of the generated standard languages and compatibility between each of the languages. As the specifications expand and evolve, the support is added in Studio and applications will be automatically upgraded.

BladeWare Studio does not tie the application to the runtime server; Studio Client can generate open, standard VoiceXML code that can be run independently of the run-time server.

And Studio Client and Server will work with any standards-compliant voice browser. BladeWare VXML products provide more robust features out-of-the box if used together; however, they are not dependent on each other and can be used independently. That’s what we mean by “Built for OEM.”

If you’d like more info on BladeWare Studio, shoot us an email or call us at 770-449-7775 and press 1.

FaxTap for SIP … the Ins and Outs

FaxTap for SIP is an indispensable tool for OEMs and ITSPs that offer FoIP. And if you’re wondering what inputs it can handle, read on.

FaxTap operates in three modes: SIP, T38, and PCM. In PCM mode, FaxTap takes one or two input files (two simplex or one full-duplex). If two files are supplied, FaxTap first assigns each recording to either the called or calling terminal mode. It then processes each recording, producing an event list and an image file if a complete or usable partial image were transferred. A single event list contains all of the events from both recordings. Each event is time-stamped in milliseconds. In T.38 mode, the supplied PCAP is assumed to contain only T.38 packets. The packets are extracted to two lists: events and image data. In SIP mode, FaxTap will parse a PCAP to locate and extract all FoIP calls, regardless of media type.

FaxTap for SIP handles PCM audio streams that are sampled at 8-Khz. The samples may be one of:

  • G.711 A-law 8-bit samples.
  • G.711 µ-law 8-bit samples
  • 16-bit linear samples that utilize only the low 13 bits.
  • 16-bit linear samples utilizing all 16-bits.

A-law and µ-law streams extracted from RTP sessions within PCAP files are supported.

A high-pass filter option allows you to remove 60Hz artifacts that may have been added by the recording equipment.

PCAP IP capture files are supported for both IP-V4 and IP-V6. PCAPNG formatted files are not currently supported.

FaxTap for SIP outputs images to TIFF-F format.

In the next Outlook, we’ll describe FaxTap’s output, so if you’re interested, stay tuned. Better yet,  order your no-charge evaluation copy today.

We’re Heading to Vegas!

Visit Commetrex at ITEXPO!Commetrex and NetGen are exhibiting together at ITEXPO Vegas, August 26-29, 2013. This is the first time in recent years that ITEXPO will be held in Vegas, so we’re looking forward to it. If you haven’t yet made plans to attend, there’s still time to register. While there, you’ll definitely want to come by our booth, #327, and talk to us about your FoIP concerns. If you’re having troubles with FoIP, we have a solution that can resolve your problems.

If you’ll be at the show and you’d like to schedule time to meet with us, just email If you can’t make it to the show this time but are still interested in obtaining a FoIP solution, just contact us and we’ll work with you.

WebRTC: Is It Google’s Turn?

Thirty-one years ago, IBM redefined the computer industry with its erector-set approach to the PC. This innovation released the creative force of thousands of developers — both hardware and software — that could and did take a tsunami of products to market. And Microsoft, as the supplier of the operating environment for this open platform, began its meteoric rise to corporate-legend status. But has Microsoft’s “moment” passed? Now, comes Apple’s iPhone, enabling tens-of-thousands of startups by opening the Apple App Store to third-party developers.

Is it now Google’s turn? Ever heard of WebRTC?

Although the development of WebRTC products is now underway at hundreds — perhaps thousands — of companies, Google is leading the charge. Their thinking seems to be that they (and humanity) benefit the more applications become Web based…the Web is the application platform, rather than Windows, or even Linux. And typically, Web-based applications are browser-based applications. Good for Google.

Today, if a computer application is interactive, it will typically involve the Web, with an HTML browser being the usual interface. But, aside from a limited number of built-in functions, extensions to the browser involve requiring that the user add the function to the browser by installing a plug-in. But if the extension involved interaction with another browser, such as real-time communications, it would fail unless that browser had the same plug-in. This problem would vanish if the communications functions were standardized and made available in browsers as independent applications through Javascript APIs, precisely the idea behind HTML 5, for which WebRTC is a major part.

Although the genesis of HTML 5 and WebRTC can be traced back to 2004, it wasn’t until 2011 that the IETF and the W3C became involved in a big way. The W3C Web Real-time Communications Working Group (WEBRTC) was created in May 2011; the IETF RTCWEB Working Group goes back to April 2011. The W3C is specifying the APIs used by applications to get access to media from devices, such as a microphone or camera; the IETF is specifying the communications protocols. Here’s the reference architecture for the browser:

But note from the diagram that the application is responsible for everything else, and that includes setting up the session with the other device through a server. Signaling is not included in the WebRTC specs. That doesn’t mean they are not being worked on, they just aren’t part of the WebRTC specs. The server can be an enterprise PBX, a computer on your household LAN, or a huge sever farm that supports a massive-scale deployment.

You’re going to be hearing much more about WebRTC.