Late T.38 re-Invites: A Report from the Field

Our largest BladeWare customer, a service provider with thousands of ports deployed, reported that they had been seeing a high failure rate on outbound faxes, sometimes up to 20%. They had looked at the captures and noticed that BladeWare was sending a SIP 406, Not Acceptable Here code, for the failing calls. “What was going on?” they asked.

It turns out that one of their carriers was experiencing some unusually high traffic loads, causing their generation of T.38 re-Invites to be slow, sometimes over 20 seconds. Well, as we’ve stated in the past, it only takes about 7.5 seconds for the two endpoint terminals to get far enough into a fax call so that interrupting them to switch to T.38 will kill a fax (the point of no return).

Late T.38 re-Invite
You can see this very clearly in the capture above, which is from testing we did in 2Q09, but is typical of the problem reported yesterday. The calling fax terminal can “hear” the called terminal at 433, when it starts collecting the DIS, as shown the RTP capture, below.

In this particular call, which was captured prior to our patent-pending late-T.38-re-Invite discovery, the RTP stream was shut down at about 444.4, killing the fax by accepting the re-Invite when it should have given the network the ol’ 406.

But why did the calls fail after the 406 in the recent case? Well, it turns out that some gateways mute the RTP stream as soon as they decide to issue a re-Invite. Ironically, the strategy is to try to reduce the chances that this very problem will occur by not allowing the signal to get through to the terminals, what some call “T.30 leakage.” But, in this case, the called gateway was so late, it actually killed the call.

Late T.38 re-Invite

For more information on Commetrex’ Smart FoIP, please contact us at 770-449-7775 (push 1 for Sales) or at

FaxTap for SIP Is Coming Soon

Did you know that Wireshark interprets packets following a T.38 re-Invite as T.38, even if they are RTP (flags them as “Malformed T.38 packets”). Of course, Wireshark performs no analysis, and doesn’t render the image for you. Well, if things go reasonably well, we’ll launch the Beta program for FaxTap for SIP, which takes up where Wireshark leaves off, in early October.

As many of you know, we’ve been supplying the industry with FaxTap for PCM and FaxTap for T.38 for several years. FaxTap for PCM was originally called PCM-to-TIFF, which describes the initial function of the product. Subsequent updates have added limited analysis (e.g., displaying V.21 frames, image information). It required a PCM file as input. FaxTap for T.38 was originally developed as a custom package for a test-equipment OEM. As a result, it had more analysis features. It was packaged as a DLL and it returned a linked list of session events that covered T.30 events, frame data, and image data. The calling program had the freedom to display the analysis results as it wished. The input to this product was a PCAP containing a single T.38 session. Subsequent updates allowed multiple T.38 sessions to be included, however, SIP signals were ignored.

FaxTap for SIP will merge the functions of both products into a form similar to FaxTap for T.38 and add support for T.38 version 3 with V.34 in both G.711 pass-through and T.38 modes. It also performs an extensive analysis, which, we hope, will help the industry move ahead with international-carrier deployments.

Are you interested in the Beta program? Let us know by August 31 to receive a discount on a full license. (All current FaxTap licensees will receive upgrades for a reduced fee.)


June 25-27, 2012

Commetrex’ CEO, Mike Coffee, recently attended SIPNOC.

The SIP Forum comprises, for the most part, equipment vendors interested in removing barriers to the deployment of SIP-based networks. And, for the second year in a row, the SIP Forum has hosted “SIP Network Operators Conference” (SIPNOC) in Herndon, VA for the technical personnel from the global carrier community responsible for designing and operating SIP networks. The conference affords the SIP Forum and carrier-community attendees the opportunity to personally meet and to exchange ideas and experiences that relate to the on-going transition from a PSTN that uses SS-7 for call routing and management to a Public IP Network (PIPN) that uses SIP for routing and session management.

SIPNOC is unique in its absence of promotion and industry press. (It was wall-to-wall geeks.) This attendee profile is reflected in the presentations and birds-of-a-feather meetings. Kicking it off was Henning Schulzrinne, the Father of SIP and the CTO of the U.S. Federal Communications Commission. His presentation, naturally, dealt with topics of concern to the FCC, such as the role of telephone numbers in the new network, security, and reliability.

Other presentations included:

  • Large-Scale FoIP, Voxbone
  • User-Agent Configuration, birds-of-a-feather (BoF) meeting
  • The World Conference on International Telecommunications, ISOC
  • SIP and IPV6, ISOC and BoF
  • SIP Forum FoIP Task Group Testing, Commetrex
  • SIP and Network Security, panel
  • FoIP Interoperability, Panel: Commetrex, Sonus, Voxbone
  • Redundancy in SIP Networks, ECG
  • SIPconnect Security, Georgetown U.
  • SS-7 and SIP, panel
  • Simultaneous Ring, The Monster Eating Your Network, ECG

Takeaway? If you are a SIP stakeholder you should be a SIP Forum member. And if you are responsible for SIP-based products or networks, seriously consider attending next year’s SIPNOC.

Interested and have questions? Send an e-mail to

Commetrex Launches Developer’s Wiki

This month we launched our long-anticipated Developer’s Wiki (, based on Tiki Wiki by CMS Groupware. It gives you a go-to site for BladeWare documentation, and, as of August 1, it will be where you need to go for all BladeWare support requests. The target for Wiki support for licensed media technologies is September 30.

Many of you have received invitations to become registered users, necessary for full access, but you don’t have to wait for an invite, just go to the site and request credentials. If you need additional info, please contact Marilyn Troup.

International FoIP Calls

The SIP and i3 Forums have performed extensive testing of FoIP in carrier networks, and we have found that routing an FoIP call over multiple international tandem connections is just too problematic to be practicable. This means carriers that want to provide reliable FoIP service today must route FoIP calls over validated FoIP routes (e.g., all-IP routes, preferably with guaranteed QoS). Generally, IP-to-TDM conversions should only be used to reach the TDM fax terminals. For the most part, that means over-the-top IP routes, not handing off the call to the next-in-line least-cost carrier, but giving it to an IP carrier that can deliver it to the TDM incumbent in the destination country.

But if you know something about network operations and FoIP, you may be wondering how all this routing magic is performed, after all, a carrier’s routing entity assumes the a session is a voice call, not a fax call. And it’s well known that for T.38 version 0 the re-Invite to T.38 is the responsibility of the off-ramp or called gateway, long after the call was routed. The answer is that the carriers must deploy a way for the on-ramp/calling/emitting gateway to signal that the call should be routed over an FoIP-qualified route.

The SIP Forum FoIP Task Group surveyed the IETF RFCs and found what we were looking for: RFC 3840 and 3841. Here’s the 3841 abstract:

This document describes a set of extensions to the Session Initiation Protocol (SIP) which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which Uniform Resource Identifiers (URI) a request gets routed to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request header fields, Accept-Contact, Reject-Contact, and Request- Disposition, which specify the caller’s preferences.

And the RFC 3840 abstract:

This specification defines mechanisms by which a Session Initiation Protocol (SIP) user agent can convey its capabilities and characteristics to other user agents and to the registrar for its domain. This information is conveyed as parameters of the Contact header field.

RFC 3841 addresses how to use the media-preferences tags that are specified in RFC 3840. It’s interesting that 3840 specifies 18 media features, such as audio, video, and text, but there’s no mention of fax, a situation the SIP Forum is working to remedy.

Questions: shoot us an e-mail at

Have You Registered for ITEXPO?

ITEXPO West 2012It’s in Austin, Texas, October 2-5, 2012, and it will bring together members of the telecom industry as hasn’t been done in the U.S. in quite awhile. If you are a buyer or seller, you owe it to yourself and your organization to be there for the sessions and the exhibits.

And Commetrex will be there in booth 722. Our focus will be on NetGen Communication’s Smart ATA, the only ATA with T.38 V3 and V.34 support and Commetrex’ patent-pending Smart FoIP. Smart ATA is truly the only ATA with the technology needed for reliable operation in carrier networks.

We will also be featuring FaxTap for SIP. As many of you know, Wireshark is unable to accurately decode many FoIP calls, but FaxTap for SIP, slated for beta release in October, searches a PCAP file for FoIP calls, both G.711 pass-through and T.38, producing the image, if available, along with an analysis of what happened.

We believe FaxTap for SIP will be the go-to tool for anyone installing a SIP-based FoIP system or operating a network that transports FoIP calls. That may be most people in the industry, so come to booth 722 to find out what it’s all about.

Can’t wait? Skype Cliff Schornak at “cschornak”.