1. The Three Phases of FoIP Deployment
Mike Coffee CEO Commetrex Co-Chair SIP Forum FoIP Task Group
Good morning. My name is Mike Coffee, CEO of Commetrex. Gonzalo Salgueiro of Cisco and I are co-chairmen of the SIP Forum’s FoIP Task Group. In addition to our usual duties, Gonzalo has been focused on working with the ITU and IEFT; I have worked with the i3 Forum, primarily through Jerzy Soldrowski of Telecom Poland, who heads up the i3 FoIP task group.
This morning, I will bring you up to date with 1) the state of FoIP deployment, and introduce my view of the phases of FoIP deployment. I’ll also bring you up to date on the work of the SIP Forum’s FoIP Task Group, in particular, what we’ve learned about FoIP involving tandem carrier networks.

2. A Marriage of Necessity
Vendors
Carriers
On that last point: I’m sure I’ll be corrected if I’m wrong, but to the best of my knowledge, prior to the current efforts being undertaken by the FoIP task groups of the SIP Forum and the i3 Forum, which I’m going to review, there has been no effective effort by our industry to perform the testing needed to solve the FoIP problems that have appeared with the recent introduction of real-time fax into IP-carrier networks. The equipment vendors, which comprise the bulk of the SIP Forum membership, and the carriers of the i3 Forum have each tried to make FoIP work, but they haven’t succeeded because they can’t do it alone.
Fortunately, we are now working together.
You could say that the cooperation of the two groups was a marriage of necessity. The equipment vendors know the protocols as only developers can; the carriers know their network operations as only they can. But the problems have to do with the deployment of the network equipment into those carrier networks, so the two groups must work together to test, analyze, and solve the problems.

3. Fax Relay Real-Time Packet-Based Fax T.38 T.30 Emitting/on-ramp
Receiving/off-ramp
Gateway
Gateway
PSTN
PSTN
Packet
Network
Receiving
Fax
Real-Time
But just to make sure everyone is on the same page…
I frequently see confusion among people in the industry about just what T.30 is and what T.38 is. T.30 is a computer-computer protocol for real-time image exchange! It is the protocol the two endpoint fax terminals, shown here, use to communicate and transfer image data. That is literally the definition of facsimile made by a US Federal court in a patent-infringement case.’’
But T.30 was designed for TDM networks and the timing requirements that it supports. However, the indeterminacies of IP networks can’t reliably support the requirements of T.30, so T.38 was developed to render the interposing IP network transparent to the endpoint terminals. T.38’s job is to make the packet network disappear to the endpoint terminals.
Transmitting
Packet-Based
Fax
Fax
T.30

4. Phase I, intra-enterprise: 1998-2008+ Phase II, SIP trunking: 2007+
T.38 Deployment Phases:
Phase I, intra-enterprise:
Phase II, SIP trunking: 2007+
Phase III, tandem carriers: 2011+
When discussing FoIP and T.38 in particular, I’ve found it useful to point out that T.38 has so far been deployed in three phases: intra-enterprise, SIP trunking, and tandem carriers.

5. Intra-Enterprise
Phase I began with the publication of T.38 V0 in October 1998, and, within the next few years, we saw T.38-capable ATAs and gateways enter the market. Commetrex opened its free T.38 Interop Test Lab in The first HMP fax media server with T.38 and G.711 pass-through support shipped in And 2005 saw some early service provider-based FoIP deployments of fax-to- .
But in both the enterprise- and carrier-based deployments, the IP transport of real-time fax came to a screeching halt at the edge of the corporate and service-provider networks. IP-carrier interworking of FoIP had yet to happen since the carriers, including the IP carriers that came out of the ‘90s, hadn’t gotten around to upgrading their infrastructure to support T.38, and G.711-pass-through fax was too error-prone in most, but not all, applications.
And, phase I was relatively simple since the networks were usually homogeneous as they were confined to one organization. In , many of the early T.38 implementations by AudioCodes, Cisco, Commetrex, and Telogy, a unit of TI, were interop tested in Commetrex’ T.38 Interop Lab. If interop problems did come up in the field, the enterprise customers could crack the whip and the two vendors involved could generally quickly solve the problems. If the problem was in the enterprise network, the customer would take care of it.
Today, over 50% of enterprise-fax servers being purchased are IP based. The PSTN interface, if any, is typically provided by the IP-PSTN gateway or PSTN interface boards. FoIP with SIP trunking is next.

6. And Now…Bring on The ITSPs & Carriers!
Then, 4-5 years ago we began to see the boundaries of FoIP pushed beyond the enterprise network, marking the beginning of Phase II. Today, in some markets enough of the large-footprint IP carriers have added T.38 support, and many VoIP service providers have added SIP trunking, removing the requirement for enterprise gateways.
As there were plenty of problems in these early deployments, some early adopters of T.38 in service-provider applications, after being frustrated by the lower-than-PSTN fax-transaction success rates, devised proprietary solutions. Early on, Cisco offered gateways with built-in T.30 for fax termination in the GW, and clients and servers within the related IP network would use non-real-time carriage, such as T.37, between the GW and the user. Others offer ATAs that do essentially the same thing by terminating the premises fax terminal’s fax in the ATA, and ing it to a hosted server, where it is forwarded via the PSTN. Still others have proprietary ATAs that use HTML-like protocols to convey the fax in near real time.
But the need for these stop-gap proprietary techniques will be obviated by a solution to the tandem-carrier configuration and signaling problems now being encountered in many Phase II deployments. But there is some talk in the industry of looking for an alternative solution to SIP and T.38. If you can imagine the years of delay and major investments any alternative would require, you may wonder why this would be brought up prior to the industry making an reasonable effort to do something about it. And that is exactly what we are working to do.
Can we get there from here? Consider this: If ENUM, which I’ll discuss in a few minutes, were fully deployed today, T.38 and SIP would be supporting FoIP with PSTN transaction-success rates over the open Internet. But problems arise as soon as carriers are asked to route an FoIP call.

7. Separating the Issues But let’s see if we can separate the issues.
Recent tests with the i3 Forum have shown that neither SIP nor T.38 are themselves a problem. It’s the way they are used together in tandem carrier networks…that is, Phase II and III deployments. After seeing very low success rates over multiple international carrier networks, we decided to test between fax servers over the Internet. In these tests SIP and T.38 worked together to deliver flawless faxes. Practically speaking, in North America, where we performed these tests, real-time fax is error-free.
Granted, in these tests, since it is server-to-server, there is no requirement for gateways or carrier-based SBCs since the transaction is server-to-server—no real gateways involved, and, of course, no analog modems, where we still see problems. And those servers know their role is that of a fax endpoint, so the T.38 re-Invite is essentially immediate. (We’ve even had to put a configuration parameter in our server to allow the installer to add delay to the T.38 re-Invite since some PBXs had a problem with a too-fast re-Invite.)
But, in general, without outside influence, SIP works exceptionally well to setup FoIP calls, and T.38 works well to carry them on a par or better with pure PSTN fax calls. Our goal, of course, is to make it just as effective when the carriers use SIP and T.38.
And what about ENUM? ENUM let’s you start with the part of the SIP address to the left of and find out part that follows

8. Voice Is Easy! Voice is generally the default Agree on a codec
Enable the media stream
Take care of jitter-buffer management
Get rid of echo
You’re done!
Call set-up timing not critical.
So, you may be wondering, why is fax more of a problem than voice? Well, to begin, voice is pretty easy, and you’ve now had over 15 years to get it right: Agree on a codec. Manage the jitter buffer. Take care of echo. And you’re good to go! Also, you have a very forgiving human ear on each end, not a fussy synchronous modem.

9. But in Fax…
Timing is everything.
But in fax…timing is everything.

10. FoIP…It’s About Time Computer-to-computer protocol (T.30)
Synchronous modems
Media stream, which begins in G.711, wants to be renegotiated and switched to T.38
Timing is everything!
Remember, T.30 has strict timing requirements. There are synchronous modems involved. So, G.711 must be switched to T.38, and it must be done in time, if it’s to be switched at all.

11. Phase III: Tandem-Carrier-Based Fax
Of course, not using E.164 terminal addressing is not practicable. For the foreseeable future, we need carriers to route our calls.
So, let’s bring in the carriers and get on with Phase II & III so we can effectively handle the 20% of international calls that happen to be fax. We need to make FoIP work. And it’s doable.

12. So…What about testing? Many networks are untested for FoIP.
Many firewalls and other network elements are not correctly configured.
Excessive signaling delay remains undiagnosed
Although many do, we can’t expect FoIP to just work. After all, VoIP didn’t. And just because your IP network and WAN routes now work for voice, they won’t necessarily work for fax without some attention being paid to the entire signaling and media path through your networks to make sure they are fax-friendly, and to make sure your peering partners are also fax friendly.
I’m sure many of you have thoroughly tested you network, but all it takes is one untested segment to foul things up.

13. Plan Your FoIP Trip
We usually plan a road trip in advance. But from the testing we’ve done, it appears that the inter-carrier routes of FoIP calls have not been previously explored.

14. In a Recent Broadcast Test 200 out of 2000 calls
Some Results:
In a Recent Broadcast Test
200 out of 2000 calls
had late-arriving T.38 re-Invites leading to fax failures.
A few slides back I asked, somewhat rhetorically, whether the carrier’s signaling could make the G.711-to-T.38 switch in time. We’ve found that in some carrier networks, in 5-10% of the cases it doesn’t. Here’s a war story:
Today, most mission-critical fax, such as fax-on-demand and fax broadcast, is still PSTN based. But even though toll charges continue to fall, there are significant equipment and operational cost savings available to any fax-broadcast vendor that can move to FoIP. So, as part of our fax-server business, we’ve done some serious testing with one of our BladeWare OEMs that has a large broadcast-fax customer base.
In this North American fax-broadcast test, for successful calls, the delay from the initial SIP 200 OK (signifying that the called terminal had answered) and the called GW’s T.38 re-Invite was less that 6 seconds. But the 200 failures averaged 8.11 seconds, with some being over 20 seconds.
That’s not good enough!

15. Outbound to ITSP Remote off hook T.38 re-Invite
Here’s a great real-life example of a late-arriving T.38 re-Invite.
Take a look at the 200 OK at 434 and the T.38 re-Invite at That’s 10 seconds where the two endpoint fax terminals are engaged in the T.30 protocol over G.711 while the two GWs are trying to determine whether to switch to T.38. Now, let’s take a look at the G.711 audio stream for this call, which begins at 433.

16. G.711 Audio Point of no return Caller
At 434, RTP G.711 begins to flow, so we see the caller’s fax calling tone (CNG) and the called terminal’s capabilities frame (DIS). If the calling terminal “hears” the DIS and responds with its command signal (DCS) telling the called terminal what modem to use, the document size, etc., the two T.30 engines are off to the races, and it’s too late to make the switch to T.38.
But the gateways don’t know all this has happened, so they dutifully switch to T.38 anyway, killing the session in the process by shutting down the audio stream. Pity the poor fax transaction.
Now, the SIP Forum TG has issued a detailed implementation recommendation to keep this from happening by having the off-ramp GW, which is generally responsible for the T.38 re-Invite, muting the PCM media stream as soon as the DIS flags are detected. (That would be right here.) However, for this to work, all off-ramp GWs in a broadcast must have implemented this recommendation. What we really need is an on-ramp solution that carriers can deploy that works whether or not the off-ramp GW has implemented the TG recommendation. Based on our N. America testing, this would result in a 5-10-percent improvement in transaction success rate.
T.38 re-Invite here. Bye-bye fax.
DIS
Callee

17. Can our industry respond effectively to these problems?
So…
Can our industry respond effectively to these problems?
Soooo…are we up to the task? Are we willing to work together and get the FoIP integration-testing job done?

18. SIP Forum FoIP Task Group Goal:
Develop and publish the guidelines (recommended practices) that will reduce the implementation problems that are today hindering IP-based fax deployments in carrier-based applications.
The SIP Forum said “YES”. And the SIP Forum’s FoIP Task Group was specifically formed in late 2008 to do something about it.
Copyright © 2010 SIP Forum

19. The i3 Forum said “YES”
The SIP Forum, largely comprised of equipment vendors, and the i3 Forum, comprised of over 36 carriers with 1.5 B subscribers in 80 countries, agreed to join forces and solve these FoIP inter-working problems once and for all, I, for one, rejoiced.
At a meeting in Warsaw in June of last year, we decided to perform extensive testing by each carrier installing an FoIP fax server for testing and sending fax broadcasts to each other. 13 carriers agreed to commit resources to the effort and become testers and test subjects.
To accomplish the testing, two SIP Forum TG members agreed to install fax servers at each carrier location for no charge. The carriers set up E.164 and SIP-accessible numbers, both carrier and Internet routed, and broadcast to each other, recording the results. We then analyzed the data and will publish a test report in October. By the end of Q4, we intend to publish our best-practices recommendations.

20. These Carriers said “Yes”!
Deutsche Telekom
iBasis
SFT
OTEGLOBE
TATA
Telkom SA
WIS
Telekom Italia Sparkle
Telecom Poland
Telefonica
Reach
FSB
Telenor
And these carriers are the carriers where we installed the servers and performed the testing.

21. Testing Report INTERNATIONAL INTERCONNECTION FORUM
FOR SERVICES OVER IP
(i3 FORUM) (
Workstream “Technical Aspects”
Testing Report
Fax over IP service
(September 2011)
The test report is in early draft.

22. I3 Testing Results
Using international-carrier SS7-based routing, call-completion rates were nominally 50%.
But here’s the key finding. Their were many causes of this terrible completion rate: First, there were major problems caused by routing over TDM segments, requiring multiple PCM-to-T.38 conversions. Many problems resulted from the on-ramp IP network never having been tested for FoIP. For example gateways in the path with proprietary relays. Often G.711 was badly mangled. Some GWs muted RTP when fax was detected, but never issued a re-Invite. We called these fax-hostile. We saw what appeared to be random BYEs. And, of course, there were late T.38 re-Invites.

23. Best Practices Recommendations
Next Steps
Best Practices Recommendations
In Q4
All of this will be further analyzed and distilled to a best-practices recommendation.

24. Intelligent Routing User=fax ENUM
All of this will help, but a 50-percent success rate is a non-starter. What can we do? Testing and qualifying FoIP routes will be a big boost, but how will carriers route the calls? Currently, it’s least-cost-routing using SS-7, not best-FoIP route routing.
I believe that carrier-based ENUM is the real answer, but until that is a reality, we are considering a recommendation of adding “User-fax” to the initial Invite, allowing the call-handling/routing functions in a network to route the call over FoIP-qualified routes.

25. User=Fax RFC 3261, section 25.1, URI Parameters
user-param = "user=" ( "phone" / "ip" / other-user)
RFC 3261 says it’s OK.
So, other-user = fax.

26. ENUM: Tells you where you want to go
Convert E.164 numbers to DNS lookup
Returns URI of user’s ENUM record
Record contains info on all services
HD voice is driver
But what about fax?
Used for IP-only routing
But, in my opinion, ENUM is the long-term answer. Today, carriers use SS-7 for their routing, and it doesn’t know anything about FoIP-qualified routes. But ENUM is a standard that allows the routing function to convert an E.164 number to a domain…the part of a SIP address that follows Today, one of the drivers of ENUM is HD voice, which can’t be routed over TDM segments. “Intelligent” routing is required. Well, if it can be done for HD voice, it can be done for FoIP.

27. SPEERMINT helps you get there
Session PEERing for Multimedia INTerconnect
Part of Real-Time Applications and Infrastructure study area (ENUM, SIP, Sigtran, etc)
Indentify, signal, and route real-time communication sessions
Picks up where ENUM leaves off
So, ENUM tells your where you want to go, but not how to get there. SPEERMINT is part of the real-time applications study area of the IETF. It picks up where ENUM leaves off by developing recommendations for how to route a call to get to that destination IP network.

28. SIP Forum & i3 Forum FoIP Task Groups…
Will We Solve the Phase II & III problems?