As IP-as-a-telephony transport matures, equipment vendors, service providers, and carriers are working out problems with implementing, configuring, and operating extra-enterprise FoIP. Only a few years ago, FoIP did not venture beyond the edge of the enterprise IP network, but today SIP trunking and direct carrier peering have pushed the boundaries of FoIP in some cases beyond national borders. But in international calls, the problems with reliable FoIP are becoming somewhat intractable when legacy carriers employ routing as usual rather than intelligent FoIP routing.
As a comparative baseline, note that FoIP with T.38 over the open Internet—no carriers involved—is even more reliable than PSTN fax for just about any call. The big difference? No carrier routing and no TDM-IP conversion. It’s T.38 end-to-end. So, how do we approach that ideal with carriers responsible for the routing?
You might know that the FoIP Task Groups of the SIP and i3 Forums have been performing extensive testing of FoIP in international calls. And it hasn’t been pretty. In most cases, it was the carrier’s first exposure to FoIP qualification, leading to significant problems with equipment and network interoperability and configuration. These problems have been addressed one-by-one. But the remaining problems caused by routing-as-usual for FoIP calls are significant enough to slow the industry’s move to an all-IP global network. FoIP-aware routing, which would be IP everywhere but to and from the TDM-connected fax terminals, is required for success. Not implementing intelligent FoIP routing casts a shadow over the testing effort since it’s a problem not easily solved…but it is a problem that can be solved.
A SIP call switches from voice to FoIP (which usually means T.38) when the called fax endpoint answers. Of course, by that time the call has already been routed. Routing decisions begin when the on-ramp proxy or SIP server receives the first SIP Invite. At that point, the provider’s routing algorithm should, if possible, route the call over qualified FoIP routes.
A switch to T.38 for a non-fax call would be a call failure, but routing a call that turns out to be a voice call over an FoIP-qualified route is not a problem. So, although a carrier doesn’t always know that a call is going to be fax call, often it does since the subscriber can declare a number to be a fax terminal or it could be assigned to a fax server.
Of course, the best answer would be ENUM, which would allow the first proxy to query the ENUM database and learn, among other things, that the destination is a fax terminal and route the call accordingly. But the forces of darkness have conspired to keep ENUM from being widely deployed. That leaves somehow “marking” an outbound call to let the providers know that it is likely to be a fax transaction.
Ten months ago the two task groups proposed that the SIP servers routing a fax call would set the user= parameter to user=fax in the header of the SIP Invite (see RFC3261, section 25.1). But then just last monght we found a better answer: RFC 3840, “Indicating User-Agent Capabilities in SIP”, which is specific to the task. According to 3840, setting the header fields to indicate the capabilities of a terminal (user agent) can be used to “express a preference for routing.”
The SIP and i3 Forum FoIP task groups are now moving ahead to standardize “SIP.FAX=”. It is interesting to note that RFC3840 defines 18 different feature tags in its section10, with none of them being fax, se we are setting out to make that 19 tag (News - Alert) definitions.
Edited by Juliana Kenny