[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/