Network Working Group Paul E. Jones, Ed.
Internet Draft Cisco
Intended status: Informational Gonzalo Salgueiro, Ed.
Expires: May 17, 2010 Cisco
November 17, 2009
SIP Forum - Fax Over IP Task Group Problem Statement
draft-jones-sip-forum-fax-problem-statement-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on May 17, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your
rights and restrictions with respect to this document.
Jones, et al. Expires May 17, 2010 [Page 1]
Internet-Draft Fax Problem Statement November 2009
Abstract
This memo is published for informational purposes to document the
issues identified by the SIP Forum with respect to the transmission
of facsimile signaling messages and fax page data over Internet
Protocol (IP) networks. Further, it is the intent of this memo to
alert the IETF to the formation of a Fax Over IP Task Group within
the SIP Forum chartered to investigate and address identified issues
as they relate to the deployment of fax services in Session
Initiation Protocol (SIP) networks.
Table of Contents
1. Introduction...................................................2
2. Problem Summary................................................4
2.1. Network Interconnection and Peering.......................4
2.2. Product Validation........................................4
2.3. Interoperability..........................................5
2.4. T.38 Performance..........................................5
2.5. G.711-V.34 Data-V.34 Fax Negotiations.....................7
2.6. SDP Negotiations..........................................7
2.7. Tandem Networks...........................................7
2.8. Unified-Messaging "single number" faxing is problematic...8
2.9. Improvements to T.38 Recommendation.......................8
2.10. Position of the TG Regarding T.38, V.152, and G.711 pass-
through........................................................8
2.11. Redundancy/FEC/ECM for Further Study.....................8
2.12. LECs in access and tandem gateways.......................8
3. Security Considerations........................................9
4. IANA Considerations............................................9
5. Preliminary Recommendations: The Low-Hanging Fruit.............9
5.1. V.34 to V.17 Fallback.....................................9
5.2. Support for ECM (Error Correcting Mode) in gateways is
strongly recommended...........................................9
6. Normative References..........................................10
7. Acknowledgments...............................................10
1. Introduction
While the T.38 protocol [3], approved by the ITU-T in 1998, was
designed to allow fax machines and computer-based fax to carry
forward in a transitioning communications infrastructure of both IP-
and Time Division Multiplexing (TDM)-based telephony, in 2009 there
are enough problems and confusion among vendors, enterprises, and
service providers to slow the use of IP as a real-time fax transport
significantly.
The issues surrounding IP-based fax in general and the use of T.38
make it difficult for users to determine if T.38 can or will work
Jones, et al. Expires May 17, 2010 [Page 2]
Internet-Draft Fax Problem Statement November 2009
reliably and thus offer an alternative to traditional TDM-based fax
transport. To address these problems and offer solutions, the SIP
Forum has chartered the Fax over IP (FoIP) Task Group (TG).
The proposed charter of the SIP Forum FoIP Task Group is to
investigate ongoing issues with the deployment of fax services,
specifically ITU-T T.38, in SIP [4] networks. SIP networks cannot
adequately replace analog the Public Switched Telephone Network
(PSTN) in enterprises unless essential services such as fax are
accommodated.
This document details the problems the Task Group has chosen to
address. Subsequent documents will make recommendations to the
industry to solve the problems. For those problems that cannot be
solved, the TG's role will be to describe the problems and recommend
best practices to be followed to alleviate them. Many of these real-
time IP-fax problems are occurring with increasing frequency due to
the maturation of IP telephony within the enterprise and carrier
networks.
Today, capex by both enterprises and carriers is largely confined to
IP infrastructure, creating demand for SIP trunking and reducing the
need for gateways. The absence of gateways and substitution of SIP
trunking, then, boosts demand for effective support of fax in
access-provider and backbone IP networks. This move to interconnect
the enterprise and wide area networks creates new interoperability
requirements.
Previously, when IP stopped at the enterprise edge, T.38
interoperability was relatively simple, as it was only required
between the Analog Terminal Adapter (ATA) or fax server and the
enterprise PSTN gateway. But with direct SIP connections, T.38
interoperability is required between the enterprise and access
provider, and between the access and long-haul providers. And all
of the links in this chain must provide effective T.38 support.
It's the addition of all these "moving parts" that present today's
challenges.
Despite the existence of the necessary standards, 11 years in the
case of T.38, the overall experience of the industry in dealing with
IP fax is low, exacerbating the problems. This committee's goal is
to publish the guidelines (recommended practices) that will reduce
the implementation problems that are hindering IP-based fax
deployments today.
If, in the judgment of the SIP Forum FoIP Task Group, existing IETF
and or ITU standards need to be modified, the Task Group will
develop a recommendation to the appropriate Standards Development
Jones, et al. Expires May 17, 2010 [Page 3]
Internet-Draft Fax Problem Statement November 2009
Organization (SDO) on what has been discovered and recommend
appropriate action by the SDO to remedy the issue.
2. Problem Summary
While the following is not an inclusive list, it presents the
highest-priority issues as determined by the Task Group.
2.1. Network Interconnection and Peering
Effective wide-area transport of IP fax requires that T.38 be
supported in all IP networks traversed by a fax session, and that
the inter-network signaling be correctly implemented. Yet the
information needed by equipment vendors, integrators, and end users
is difficult to obtain due to the difficulty of obtaining SIP
trunking and peering information from service providers.
It is a goal of the TG to assist interconnection and peering through
its recommendations, but carriers and equipment vendors can
immediately improve the situation by publishing on the Web all the
information needed for T.38 inter-network interoperability.
2.2. Product Validation
A major issue facing effective IP fax is that many media gateway
vendors have simply not had the tools nor focus and desire to test
their T.38 implementations thoroughly. Many are satisfied with
their implementations based on data that can be misleading since
transaction logs, an often-used metric for T.38 effectiveness, do
not necessarily expose errors in the facsimile document.
Several test-equipment vendors offer IP-fax test capability, but
enterprise and service provider exposure to fax technology is so
light that effective testing is still not understood. This Task
Group will publish a set of recommended tests for T.38-capable
gateways and fax-servers.
Users should be aware that all media gateways are not created equal
when it comes to load and T.38. Few vendors have the ability to
perform full load tests for their T.38-capable products. The
problem is that fax often requires more compute resources than does
Voice over IP (VoIP). For example, while a gateway may be able to
process a full DS-3 of voice calls, that same gateway may only be
able to handle a few DS-1s of fax before hitting critical CPU
utilization levels.
Moreover, the problem can become even more complex since load
balancers and routing rules have not been designed or tested for
T.38 loads. Often a user learns of the need to load-balance the
Jones, et al. Expires May 17, 2010 [Page 4]
Internet-Draft Fax Problem Statement November 2009
T.38 fax traffic differently due to CPU loading issues, but they
then find that their load balancer is unable to perform this task
reliably.
The Task Group will investigate whether practicable T.38 load-test
facilities are available and recommend them to the industry, if
available.
2.3. Interoperability
In a market where vendors are struggling to get T.38 to work, adding
the necessary testing to ensure interoperability among the myriad of
T.38-capable ATAs and media gateways adds to the challenge. Fax has
always been a complex specialized technology. T.30's complexity
makes it common to encounter a non-conforming fax terminal. Getting
fax machines to send/receive directly and reliably between each
other was complicated to start with; now the industry is adding many
more "moving parts" in the form of IP-PSTN gateways. And as an
emerging technology, there are many unproven gateways, media
servers, and IP networks. The validation challenge to vendors and
users is daunting. This includes compatibility for a wide range of
fax machines due to modem implementations, issues to do with local
loop, T.38 and T.30 implementations.
The Task Group will explore the possibility of a public test
facility or a test suite that will validate equipments and networks
against the problems defined here.
2.4. T.38 Performance
T.38 implementations vary as to features, interoperability, and
performance. Features are usually quite obvious: Does the
implementation support T.38 Version 3 (V3)? Error Correction Mode
(ECM)? Does it support User Datagram Protocol Transport Layer
(UDPTL), Real-time Transport Protocol (RTP) and Transmission Control
Protocol (TCP)? Determining interoperability is more difficult, but
can be readily done with T.38-specific test tools and time-in-market
of the T.38 implementation. By far the most difficult
characteristic to determine is performance.
The FoIP Task Group's objective is to improve the effectiveness of
T.38 in supporting real-time fax transport in IP networks using SIP
signaling. The Task Group has identified several recurring problems
that need to be addressed and that can be divided into several
categories:
1. SIP interoperability:
Jones, et al. Expires May 17, 2010 [Page 5]
Internet-Draft Fax Problem Statement November 2009
Can the TG promote standardization of T.38-related Session
Description protocol (SDP) negotiations?
2. Gateway media-handling strategy:
How does the gateway handle media-specific (voice/fax/data)
negotiations, such as V.34 to V.17 step-down? Can the TG help
standardize T.38 V3 and V.8 call flows?
3. T.38 interoperability:
No specific T.38 interoperability problems have been identified,
but the need for better interoperability testing has been noted.
4. T.38 relay performance:
Many of the problems the TG has identified, such as multi-TDM-hop
networks, satellite hops, and packet loss, are related to
performance of T.38 relay implementations.
The TG has noted that few equipment vendors and even fewer
enterprises and service providers understand the differences between
interoperability and performance, and, if they did, doubt they could
adequately test performance with the tools available today. The TG
has indentified three metrics of T.38 relay performance:
1. The Task Group identified a need to provide guidance on delay
tolerance of the relay. Some handle a fraction of a second; some
up to five seconds. Packet-delay tolerance is the relay's ability
to keep the two T.30 end-point terminals engaged in the
transaction in spite of packet delays. T.38 does not give any
guidance on how to improve delay tolerance, but, as we know, it is
improved through so-called spoofing techniques implemented by
skilled T.38 relay developers. Better relays can handle up to
five seconds of round-trip delay in the IP path.
2. The Task Group identified multi-TDM-hop delays exacerbated by
high gateway latencies. Part of the delay is the result of
requirements of the T.38 recommendation. The requirement to
suppress High-level Data Link Control (HDLC) framing and Cyclic
Redundancy Check (CRC) octets forces a delay of three HDLC payload
octets (80ms) into the relay. To this you add IP transmit data
buffering of, say, 40ms and Pulse Code Modulation (PCM) buffering.
The PCM jitter buffer should be deep enough to accommodate the
expected network delay, 160ms being a typical minimum.
Performance can be affected by things such as whether the jitter
buffer is dynamic, for example by emitting packets immediately if
there are no errors.
Jones, et al. Expires May 17, 2010 [Page 6]
Internet-Draft Fax Problem Statement November 2009
3. A relay's ability to handle the situation that occurs when
packet loss exceeds the redundancy or Forward Error Correction
(FEC) settings is also a dimension of performance, not
interoperability. How does the relay handle the modem signal when
lost packets cannot be recovered? The high-speed modem of the
receiving fax terminal will see the error, possibly producing a
bad line or lines, depending on the mode. But how does the relay
handle the control frames that cannot be recovered in time? What
does the relay do when the V.21-preamble signal is missing? What
about a missing V.21 octet? T.38 doesn't say, but the answers
will determine whether the session succeeds or fails. This has to
do with relay performance, not interoperability.
The FoIP Task Group will recommend tests for T.38 performance.
2.5. G.711-V.34 Data-V.34 Fax Negotiations
The negotiation and fall-back procedures implemented in network
gateways are inconsistent at best, and fail at worst. They may also
be disturbed by malfunctioning echo cancellers (see problem 12). The
Task Group will recommend best practices to follow and support them
with call-flow/use-case examples that enable proper fax, modem and
textphone functionality.
The Task Group will operate with the understanding that no
recommendation has the unintended consequence of interfering with
other media and protocols, e.g. modem and textphone protocols.
2.6. SDP Negotiations
In general, implementers are inconsistent in their handling of T.38
SDP negotiations. When should a Re-invite to T.38 be accepted?
When can and should T.38 capability be declared? Should fax-only
T.38 endpoints be able to invite directly to T.38?
These questions will be answered by the Task Group and supported by
use cases and call flows. Task Group will recommend the necessary
syntax for T.38 to aid in consistent implementations.
2.7. Tandem Networks
With increased deployment, users are seeing three, four, and five
TDM-network segments in a fax call. Once the cumulative delays
exceed the T.4 (3 sec. +-15%) timer in the endpoint T.30 terminals,
the chance of collision between repeated signals from the calling
and called terminals increases significantly. The Task Group will
investigate and define the problem and include recommended best
practices in its results.
Jones, et al. Expires May 17, 2010 [Page 7]
Internet-Draft Fax Problem Statement November 2009
2.8. Unified-Messaging "single number" faxing is problematic
A standard procedure for one-number voice-fax systems is required.
One common problem is a deadlock issue: the Unified Messaging (UM)
system answers in voice mode and listens for Calling (CNG) tone to
transition to fax. However, a calling fax device may be listening
for the Calling Terminal Identification (CED) tone to proceed. If
the calling terminal assumes the called entity is a fax terminal,
then it can emit CNG tones immediately on answer and enter into fax
negotiation. If, however, the answering endpoint does not know if
it's a fax or voice call, it must enable a call classifier.
However, if the calling device is waiting for the CED or V.21 fax
tones to enter fax sending mode the call will not proceed. There
are solutions to this problem, however the calling and called party
must know which solution is being used and behave accordingly for
the call to succeed.
The Task Group will develop best practices for such UM systems.
2.9. Improvements to T.38 Recommendation
Although the TG has identified no specific problems with T.38, if
some are made during the operational phase of the TG's work, they
will be collected here. It has been suggested that one improvement
would be to recommend default settings.
2.10. Position of the TG Regarding T.38, V.152, and G.711 pass-through
A Working Group (WG) will be formed to draft a recommendation to the
industry regarding the use of T.38, V.152, and G.711 pass-through in
various types of networks. The WG will consider if it should
recommend the use of a particular version of T.38.
2.11. Redundancy/FEC/ECM for Further Study
A Working Group will be formed to draft recommendations regarding
the use of redundancy, FEC, and ECM in different network scenarios.
2.12. LECs in access and tandem gateways
The effective use of Line Echo Cancellers (LECs) in access and
tandem-network gateways is reported to be inconsistent and
problematic. The TG will study the question and offer
recommendations as to the settings of LECs in order to avoid
problems when handling fax calls.
Jones, et al. Expires May 17, 2010 [Page 8]
Internet-Draft Fax Problem Statement November 2009
3. Security Considerations
There are security risks associated with the transmission of
facsimile signaling and page data over IP networks, though no
security risks are introduced in this memo.
Relating to the IP portion of the communication, the Task Group will
explore and recommend security options such as Datagram Transport
Layer Security (DTLS) or Secure Real-Time Transport Protocol (SRTP).
It is not the Task Group's intention to discuss security issues
between the gateway and the terminal.
4. IANA Considerations
There are no Internet Assigned Numbers Authority (IANA)
considerations.
5. Preliminary Recommendations: The Low-Hanging Fruit
The following are preliminary implementation recommendations for IP
fax.
5.1. V.34 to V.17 Fallback
Carrier deployments of gateways with T.38 V3, which supports V.34,
have, thus far, had very limited application. But with the arrival
of T.38 V3, carriers must ensure that they correctly handle fallback
from V.34. Some carriers do not step down V.34 connections to T.38
with V.17 when fax is detected, but rather attempt to transport the
V.34 session with G.711 pass-through. Fax reliability requires that
if a V.34 fax session is detected (V.8 with Answer tone, amplitude
modulated [ANSam] tone), the non-V3 gateway must Re-INVITE to T.38
and negotiate V.17.
5.2. Support for ECM in gateways is strongly recommended.
MMR (Modified Modified Read) compression, which significantly
reduces bandwidth requirements, requires ECM. So does color fax and
V.34. Automated processing of faxes is a requirement in many
enterprises that process large volumes of faxes. The value of ECM
becomes immediately obvious when deploying automated Intelligent
Character Recognition (ICR)/ Optical Character Recognition (OCR) and
barcode processing. Chat carriers that deploy gateways that do not
support ECM lower the value of their service. But despite this,
many IP-backbone providers have based their second-generation
infrastructure on gateways that do not currently support ECM. These
carriers must update to any software release for these gateways that
supports ECM.
Jones, et al. Expires May 17, 2010 [Page 9]
Internet-Draft Fax Problem Statement November 2009
Moreover, ECM also supports quality monitoring. The ECM error count
does an excellent job of highlighting line-quality issues.
Enterprises should be knowledgeable of these details so they can
easily monitor their networks for the quality of service they are
receiving.
6. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for
Syntax Specifications: ABNF", RFC 2234, Internet Mail
Consortium and Demon Internet Ltd., November 1997.
[3] ITU-T Recommendation T.38, "Procedures for real-time Group 3
facsimile communication over IP networks", 2007.
[4] Rosenberg, J., et al., "SIP: Session Initiation Protocol",
June 2002.
7. Acknowledgments
This document was prepared using 2-Word-v2.0.template.dot.
Jones, et al. Expires May 17, 2010 [Page 10]
Internet-Draft Fax Problem Statement November 2009
Authors' Addresses
Ximing Michael Chen
LSI Corp.
1110 American Parkway NE
Room 12E-220A
Allentown, PA 18109
USA
Tel: +1 610 712 3596
Email: Michael.Chen@LSI.COM
Mike Coffee
Commetrex Corporation
1225 Northmeadow Pkwy, Ste 120
Roswell, GA 30076
Phone: +1 770 407 6021
Email: mcoffee@commetrex.com
Kevin P. Fleming
Digium, Inc.
445 Jan Davis Drive NW
Huntsville, AL 35806
USA
Phone: +1 256 428 6012
Email: kpfleming@digium.com
Gunnar Hellstrom
Omnitor AB
Renathvagen 2
SE-121 37 Johanneshov
Sweden
Phone: +46 708 204 288
Email: gunnar.hellstrom@omnitor.se
Jones, et al. Expires May 17, 2010 [Page 11]
Internet-Draft Fax Problem Statement November 2009
Paul Jones
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Phone: +1 919 476 2048
Email: paulej@packetizer.com
John Lunsford
QualityLogic, Inc.
5401 Tech Circle
Moorpark, CA 93021
Email: jlunsford@qualitylogic.com
Antonios Papageorgiou
Siemens Enterprise Communications
Metaxa 15, 14564
Kato Kifisia, Athens
Greece
Phone: +30 210 8189659
Email: antonios.papageorgiou@siemens-enterprise.com
Gonzalo Salgueiro
Cisco Systems, Inc.
7025 Kit Creek Rd.
Research Triangle Park, NC 27709
USA
Phone: +1 919 392 3266
Email: gsalguei@cisco.com
Ed Schulz
LSI Corporation
1110 American Parkway NE
Room 12C-265
Allentown, PA 18109
USA
Phone: +1 610 712 2068
Email: ed.schulz@lsi.com
Jones, et al. Expires May 17, 2010 [Page 12]
Internet-Draft Fax Problem Statement November 2009
Neil Weldon
Dialogic Corporation
4034 Kingswood Ave.,
Citywest, Saggart, Co. Dublin
Ireland
Phone: +353 1 630 9000
Email: neil.weldon@dialogic.com
Jones, et al. Expires May 17, 2010 [Page 13]