NetGen Channel Newsletter September 2014

Where Does the MX Series Fit Into the Industry?

What Does Extreme Support Look Like?

RFC 6913 Support Now in Smart ATA

FaxTap NG’s NSF/NSS Support

Where Does the MX Series Fit Into the Industry?

The NetGen product line has undergone a major expansion over the summer. Although NetGen is now reselling the BladeWare hosted email products from Commetrex, the big news is the addition of the MX access gateways from our partner, New Rock Technologies. But why add another gateway to the industry’s already-bulging portfolio of access gateways?

Well, the key answer is the MX series provides a feature set focused on supporting the channel in enterprise applications

• Microsoft Lync
• Cisco Call Manger
• IP PBXs with PSTN-WAN connectivity
• Legacy PBXs with-WAN connectivity

So, the next time you need to solve an application problem that requires an access gateway, check out the features of the MX gateways. You won’t find richer call-control functionality. And the prices are just amazing.
Bottom line: unbeatable value.

What Does Extreme Support Look Like?

When it comes to our customers, NetGen goes the extra mile to troubleshoot any issues a customer may have. By understanding what challenge has arisen, we are able to work with the customer to solve the problem. Below is a response to a customer’s V.34 question. We don’t expect you to read all of this or to understand it if you did, but we thought it might be interesting to see just how far we go at NetGen to provide extreme support.

posted on: 10/02/14 07:43:24 PM
After reviewing your captures, I am confident that the remote terminal is getting a corrupt signal. In call 3, the caller misses the first INFO0a and initiates a resend of the INFO0a. BladeWare sends INFO0a three times before the caller moves to probing. After probing it again misses the INFOh and goes into a strange recovery mode. I don’t see how the remote terminal gets to this state. It appears that INFO0c is being resent, but that should not happen if probing has been sent.

RFC 6913 Support Now in Smart ATA

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

If you’ve been wrestling with the “FoIP problem” (who hasn’t?) you may be aware that 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. Obviously, all of this happens after the call has been routed. So, how can you take control of the 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, 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 Smart ATA 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. But you can take matters into your own hands and only deploy ATAs that support RFC6913, then route those FoIP calls over proven routes.

FaxTap NG’s NSF/NSS Support

FaxTap NG is now shipping, and any of you that have run into problems analyzing NFS/NLL calls should be eager to get your hands on it.

For most faxes, T.30, the international fax protocol, guides the two endpoint terminals through the fax procedure from beginning to end. But there is an escape procedure in the T.30 protocol that allows the two terminals, if from the same manufacturer, to depart from the T.30 standard and communicate via a protocol proprietary to the terminal manufacturer. This is used to implement secure polling, for example.

So software designed to analyze third-party recordings of fax sessions, say from Wireshark captures, is left in the dark since it has no idea what modems are used and the size and encoding of the image data since the pre-image-transfer signaling is all non-standard. The primary commands used to set this up are NSF (Non-Standard Facilities) and NSS (Non-Standard Setup), hence the headline, above.

This non-standard signaling means that to render the image, the analysis software must determine which modem is used and at what bit rate for the image data—all without being able to decode the NSF/NSS. And then there’s the encoding and image size to somehow determine. FaxTap NG is the only fax-analysis product that can automatically handle NSF/NSS sessions, correctly rendering the image.

FaxTap NG also add an easy-to-use GUI, which means it’s suitable for less skilled support personnel.
Also, we’re looking for test specimens. So if you have a PCAP of an NSF/NSS session, email it to marketing@NetGenCommunications.com. We will run it through FaxTap NG, send you the results, and a 15-day demo of FaxTap NG for your trouble.