idnits 2.17.1 draft-jones-sip-forum-fax-problem-statement-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 17, 2009) is 5264 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'ANSam' on line 414 == Unused Reference: '1' is defined on line 440, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 443, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '2') (Obsoleted by RFC 4234) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Paul E. Jones, Ed. 3 Internet Draft Cisco 4 Intended status: Informational Gonzalo Salgueiro, Ed. 5 Expires: May 17, 2010 Cisco 6 November 17, 2009 8 SIP Forum - Fax Over IP Task Group Problem Statement 9 draft-jones-sip-forum-fax-problem-statement-00.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as 24 reference material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 This Internet-Draft will expire on May 17, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your 43 rights and restrictions with respect to this document. 45 Abstract 47 This memo is published for informational purposes to document the 48 issues identified by the SIP Forum with respect to the transmission 49 of facsimile signaling messages and fax page data over Internet 50 Protocol (IP) networks. Further, it is the intent of this memo to 51 alert the IETF to the formation of a Fax Over IP Task Group within 52 the SIP Forum chartered to investigate and address identified issues 53 as they relate to the deployment of fax services in Session 54 Initiation Protocol (SIP) networks. 56 Table of Contents 58 1. Introduction...................................................2 59 2. Problem Summary................................................4 60 2.1. Network Interconnection and Peering.......................4 61 2.2. Product Validation........................................4 62 2.3. Interoperability..........................................5 63 2.4. T.38 Performance..........................................5 64 2.5. G.711-V.34 Data-V.34 Fax Negotiations.....................7 65 2.6. SDP Negotiations..........................................7 66 2.7. Tandem Networks...........................................7 67 2.8. Unified-Messaging "single number" faxing is problematic...8 68 2.9. Improvements to T.38 Recommendation.......................8 69 2.10. Position of the TG Regarding T.38, V.152, and G.711 pass- 70 through........................................................8 71 2.11. Redundancy/FEC/ECM for Further Study.....................8 72 2.12. LECs in access and tandem gateways.......................8 73 3. Security Considerations........................................9 74 4. IANA Considerations............................................9 75 5. Preliminary Recommendations: The Low-Hanging Fruit.............9 76 5.1. V.34 to V.17 Fallback.....................................9 77 5.2. Support for ECM (Error Correcting Mode) in gateways is 78 strongly recommended...........................................9 79 6. Normative References..........................................10 80 7. Acknowledgments...............................................10 82 1. Introduction 84 While the T.38 protocol [3], approved by the ITU-T in 1998, was 85 designed to allow fax machines and computer-based fax to carry 86 forward in a transitioning communications infrastructure of both IP- 87 and Time Division Multiplexing (TDM)-based telephony, in 2009 there 88 are enough problems and confusion among vendors, enterprises, and 89 service providers to slow the use of IP as a real-time fax transport 90 significantly. 92 The issues surrounding IP-based fax in general and the use of T.38 93 make it difficult for users to determine if T.38 can or will work 94 reliably and thus offer an alternative to traditional TDM-based fax 95 transport. To address these problems and offer solutions, the SIP 96 Forum has chartered the Fax over IP (FoIP) Task Group (TG). 98 The proposed charter of the SIP Forum FoIP Task Group is to 99 investigate ongoing issues with the deployment of fax services, 100 specifically ITU-T T.38, in SIP [4] networks. SIP networks cannot 101 adequately replace analog the Public Switched Telephone Network 102 (PSTN) in enterprises unless essential services such as fax are 103 accommodated. 105 This document details the problems the Task Group has chosen to 106 address. Subsequent documents will make recommendations to the 107 industry to solve the problems. For those problems that cannot be 108 solved, the TG's role will be to describe the problems and recommend 109 best practices to be followed to alleviate them. Many of these real- 110 time IP-fax problems are occurring with increasing frequency due to 111 the maturation of IP telephony within the enterprise and carrier 112 networks. 114 Today, capex by both enterprises and carriers is largely confined to 115 IP infrastructure, creating demand for SIP trunking and reducing the 116 need for gateways. The absence of gateways and substitution of SIP 117 trunking, then, boosts demand for effective support of fax in 118 access-provider and backbone IP networks. This move to interconnect 119 the enterprise and wide area networks creates new interoperability 120 requirements. 122 Previously, when IP stopped at the enterprise edge, T.38 123 interoperability was relatively simple, as it was only required 124 between the Analog Terminal Adapter (ATA) or fax server and the 125 enterprise PSTN gateway. But with direct SIP connections, T.38 126 interoperability is required between the enterprise and access 127 provider, and between the access and long-haul providers. And all 128 of the links in this chain must provide effective T.38 support. 129 It's the addition of all these "moving parts" that present today's 130 challenges. 132 Despite the existence of the necessary standards, 11 years in the 133 case of T.38, the overall experience of the industry in dealing with 134 IP fax is low, exacerbating the problems. This committee's goal is 135 to publish the guidelines (recommended practices) that will reduce 136 the implementation problems that are hindering IP-based fax 137 deployments today. 139 If, in the judgment of the SIP Forum FoIP Task Group, existing IETF 140 and or ITU standards need to be modified, the Task Group will 141 develop a recommendation to the appropriate Standards Development 142 Organization (SDO) on what has been discovered and recommend 143 appropriate action by the SDO to remedy the issue. 145 2. Problem Summary 147 While the following is not an inclusive list, it presents the 148 highest-priority issues as determined by the Task Group. 150 2.1. Network Interconnection and Peering 152 Effective wide-area transport of IP fax requires that T.38 be 153 supported in all IP networks traversed by a fax session, and that 154 the inter-network signaling be correctly implemented. Yet the 155 information needed by equipment vendors, integrators, and end users 156 is difficult to obtain due to the difficulty of obtaining SIP 157 trunking and peering information from service providers. 159 It is a goal of the TG to assist interconnection and peering through 160 its recommendations, but carriers and equipment vendors can 161 immediately improve the situation by publishing on the Web all the 162 information needed for T.38 inter-network interoperability. 164 2.2. Product Validation 166 A major issue facing effective IP fax is that many media gateway 167 vendors have simply not had the tools nor focus and desire to test 168 their T.38 implementations thoroughly. Many are satisfied with 169 their implementations based on data that can be misleading since 170 transaction logs, an often-used metric for T.38 effectiveness, do 171 not necessarily expose errors in the facsimile document. 173 Several test-equipment vendors offer IP-fax test capability, but 174 enterprise and service provider exposure to fax technology is so 175 light that effective testing is still not understood. This Task 176 Group will publish a set of recommended tests for T.38-capable 177 gateways and fax-servers. 179 Users should be aware that all media gateways are not created equal 180 when it comes to load and T.38. Few vendors have the ability to 181 perform full load tests for their T.38-capable products. The 182 problem is that fax often requires more compute resources than does 183 Voice over IP (VoIP). For example, while a gateway may be able to 184 process a full DS-3 of voice calls, that same gateway may only be 185 able to handle a few DS-1s of fax before hitting critical CPU 186 utilization levels. 188 Moreover, the problem can become even more complex since load 189 balancers and routing rules have not been designed or tested for 190 T.38 loads. Often a user learns of the need to load-balance the 191 T.38 fax traffic differently due to CPU loading issues, but they 192 then find that their load balancer is unable to perform this task 193 reliably. 195 The Task Group will investigate whether practicable T.38 load-test 196 facilities are available and recommend them to the industry, if 197 available. 199 2.3. Interoperability 201 In a market where vendors are struggling to get T.38 to work, adding 202 the necessary testing to ensure interoperability among the myriad of 203 T.38-capable ATAs and media gateways adds to the challenge. Fax has 204 always been a complex specialized technology. T.30's complexity 205 makes it common to encounter a non-conforming fax terminal. Getting 206 fax machines to send/receive directly and reliably between each 207 other was complicated to start with; now the industry is adding many 208 more "moving parts" in the form of IP-PSTN gateways. And as an 209 emerging technology, there are many unproven gateways, media 210 servers, and IP networks. The validation challenge to vendors and 211 users is daunting. This includes compatibility for a wide range of 212 fax machines due to modem implementations, issues to do with local 213 loop, T.38 and T.30 implementations. 215 The Task Group will explore the possibility of a public test 216 facility or a test suite that will validate equipments and networks 217 against the problems defined here. 219 2.4. T.38 Performance 221 T.38 implementations vary as to features, interoperability, and 222 performance. Features are usually quite obvious: Does the 223 implementation support T.38 Version 3 (V3)? Error Correction Mode 224 (ECM)? Does it support User Datagram Protocol Transport Layer 225 (UDPTL), Real-time Transport Protocol (RTP) and Transmission Control 226 Protocol (TCP)? Determining interoperability is more difficult, but 227 can be readily done with T.38-specific test tools and time-in-market 228 of the T.38 implementation. By far the most difficult 229 characteristic to determine is performance. 231 The FoIP Task Group's objective is to improve the effectiveness of 232 T.38 in supporting real-time fax transport in IP networks using SIP 233 signaling. The Task Group has identified several recurring problems 234 that need to be addressed and that can be divided into several 235 categories: 237 1. SIP interoperability: 239 Can the TG promote standardization of T.38-related Session 240 Description protocol (SDP) negotiations? 242 2. Gateway media-handling strategy: 244 How does the gateway handle media-specific (voice/fax/data) 245 negotiations, such as V.34 to V.17 step-down? Can the TG help 246 standardize T.38 V3 and V.8 call flows? 248 3. T.38 interoperability: 250 No specific T.38 interoperability problems have been identified, 251 but the need for better interoperability testing has been noted. 253 4. T.38 relay performance: 255 Many of the problems the TG has identified, such as multi-TDM-hop 256 networks, satellite hops, and packet loss, are related to 257 performance of T.38 relay implementations. 259 The TG has noted that few equipment vendors and even fewer 260 enterprises and service providers understand the differences between 261 interoperability and performance, and, if they did, doubt they could 262 adequately test performance with the tools available today. The TG 263 has indentified three metrics of T.38 relay performance: 265 1. The Task Group identified a need to provide guidance on delay 266 tolerance of the relay. Some handle a fraction of a second; some 267 up to five seconds. Packet-delay tolerance is the relay's ability 268 to keep the two T.30 end-point terminals engaged in the 269 transaction in spite of packet delays. T.38 does not give any 270 guidance on how to improve delay tolerance, but, as we know, it is 271 improved through so-called spoofing techniques implemented by 272 skilled T.38 relay developers. Better relays can handle up to 273 five seconds of round-trip delay in the IP path. 275 2. The Task Group identified multi-TDM-hop delays exacerbated by 276 high gateway latencies. Part of the delay is the result of 277 requirements of the T.38 recommendation. The requirement to 278 suppress High-level Data Link Control (HDLC) framing and Cyclic 279 Redundancy Check (CRC) octets forces a delay of three HDLC payload 280 octets (80ms) into the relay. To this you add IP transmit data 281 buffering of, say, 40ms and Pulse Code Modulation (PCM) buffering. 282 The PCM jitter buffer should be deep enough to accommodate the 283 expected network delay, 160ms being a typical minimum. 284 Performance can be affected by things such as whether the jitter 285 buffer is dynamic, for example by emitting packets immediately if 286 there are no errors. 288 3. A relay's ability to handle the situation that occurs when 289 packet loss exceeds the redundancy or Forward Error Correction 290 (FEC) settings is also a dimension of performance, not 291 interoperability. How does the relay handle the modem signal when 292 lost packets cannot be recovered? The high-speed modem of the 293 receiving fax terminal will see the error, possibly producing a 294 bad line or lines, depending on the mode. But how does the relay 295 handle the control frames that cannot be recovered in time? What 296 does the relay do when the V.21-preamble signal is missing? What 297 about a missing V.21 octet? T.38 doesn't say, but the answers 298 will determine whether the session succeeds or fails. This has to 299 do with relay performance, not interoperability. 301 The FoIP Task Group will recommend tests for T.38 performance. 303 2.5. G.711-V.34 Data-V.34 Fax Negotiations 305 The negotiation and fall-back procedures implemented in network 306 gateways are inconsistent at best, and fail at worst. They may also 307 be disturbed by malfunctioning echo cancellers (see problem 12). The 308 Task Group will recommend best practices to follow and support them 309 with call-flow/use-case examples that enable proper fax, modem and 310 textphone functionality. 312 The Task Group will operate with the understanding that no 313 recommendation has the unintended consequence of interfering with 314 other media and protocols, e.g. modem and textphone protocols. 316 2.6. SDP Negotiations 318 In general, implementers are inconsistent in their handling of T.38 319 SDP negotiations. When should a Re-invite to T.38 be accepted? 320 When can and should T.38 capability be declared? Should fax-only 321 T.38 endpoints be able to invite directly to T.38? 323 These questions will be answered by the Task Group and supported by 324 use cases and call flows. Task Group will recommend the necessary 325 syntax for T.38 to aid in consistent implementations. 327 2.7. Tandem Networks 329 With increased deployment, users are seeing three, four, and five 330 TDM-network segments in a fax call. Once the cumulative delays 331 exceed the T.4 (3 sec. +-15%) timer in the endpoint T.30 terminals, 332 the chance of collision between repeated signals from the calling 333 and called terminals increases significantly. The Task Group will 334 investigate and define the problem and include recommended best 335 practices in its results. 337 2.8. Unified-Messaging "single number" faxing is problematic 339 A standard procedure for one-number voice-fax systems is required. 340 One common problem is a deadlock issue: the Unified Messaging (UM) 341 system answers in voice mode and listens for Calling (CNG) tone to 342 transition to fax. However, a calling fax device may be listening 343 for the Calling Terminal Identification (CED) tone to proceed. If 344 the calling terminal assumes the called entity is a fax terminal, 345 then it can emit CNG tones immediately on answer and enter into fax 346 negotiation. If, however, the answering endpoint does not know if 347 it's a fax or voice call, it must enable a call classifier. 348 However, if the calling device is waiting for the CED or V.21 fax 349 tones to enter fax sending mode the call will not proceed. There 350 are solutions to this problem, however the calling and called party 351 must know which solution is being used and behave accordingly for 352 the call to succeed. 354 The Task Group will develop best practices for such UM systems. 356 2.9. Improvements to T.38 Recommendation 358 Although the TG has identified no specific problems with T.38, if 359 some are made during the operational phase of the TG's work, they 360 will be collected here. It has been suggested that one improvement 361 would be to recommend default settings. 363 2.10. Position of the TG Regarding T.38, V.152, and G.711 pass-through 365 A Working Group (WG) will be formed to draft a recommendation to the 366 industry regarding the use of T.38, V.152, and G.711 pass-through in 367 various types of networks. The WG will consider if it should 368 recommend the use of a particular version of T.38. 370 2.11. Redundancy/FEC/ECM for Further Study 372 A Working Group will be formed to draft recommendations regarding 373 the use of redundancy, FEC, and ECM in different network scenarios. 375 2.12. LECs in access and tandem gateways 377 The effective use of Line Echo Cancellers (LECs) in access and 378 tandem-network gateways is reported to be inconsistent and 379 problematic. The TG will study the question and offer 380 recommendations as to the settings of LECs in order to avoid 381 problems when handling fax calls. 383 3. Security Considerations 385 There are security risks associated with the transmission of 386 facsimile signaling and page data over IP networks, though no 387 security risks are introduced in this memo. 389 Relating to the IP portion of the communication, the Task Group will 390 explore and recommend security options such as Datagram Transport 391 Layer Security (DTLS) or Secure Real-Time Transport Protocol (SRTP). 392 It is not the Task Group's intention to discuss security issues 393 between the gateway and the terminal. 395 4. IANA Considerations 397 There are no Internet Assigned Numbers Authority (IANA) 398 considerations. 400 5. Preliminary Recommendations: The Low-Hanging Fruit 402 The following are preliminary implementation recommendations for IP 403 fax. 405 5.1. V.34 to V.17 Fallback 407 Carrier deployments of gateways with T.38 V3, which supports V.34, 408 have, thus far, had very limited application. But with the arrival 409 of T.38 V3, carriers must ensure that they correctly handle fallback 410 from V.34. Some carriers do not step down V.34 connections to T.38 411 with V.17 when fax is detected, but rather attempt to transport the 412 V.34 session with G.711 pass-through. Fax reliability requires that 413 if a V.34 fax session is detected (V.8 with Answer tone, amplitude 414 modulated [ANSam] tone), the non-V3 gateway must Re-INVITE to T.38 415 and negotiate V.17. 417 5.2. Support for ECM in gateways is strongly recommended. 419 MMR (Modified Modified Read) compression, which significantly 420 reduces bandwidth requirements, requires ECM. So does color fax and 421 V.34. Automated processing of faxes is a requirement in many 422 enterprises that process large volumes of faxes. The value of ECM 423 becomes immediately obvious when deploying automated Intelligent 424 Character Recognition (ICR)/ Optical Character Recognition (OCR) and 425 barcode processing. Chat carriers that deploy gateways that do not 426 support ECM lower the value of their service. But despite this, 427 many IP-backbone providers have based their second-generation 428 infrastructure on gateways that do not currently support ECM. These 429 carriers must update to any software release for these gateways that 430 supports ECM. 432 Moreover, ECM also supports quality monitoring. The ECM error count 433 does an excellent job of highlighting line-quality issues. 434 Enterprises should be knowledgeable of these details so they can 435 easily monitor their networks for the quality of service they are 436 receiving. 438 6. Normative References 440 [1] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [2] Crocker, D. and Overell, P.(Editors), "Augmented BNF for 444 Syntax Specifications: ABNF", RFC 2234, Internet Mail 445 Consortium and Demon Internet Ltd., November 1997. 447 [3] ITU-T Recommendation T.38, "Procedures for real-time Group 3 448 facsimile communication over IP networks", 2007. 450 [4] Rosenberg, J., et al., "SIP: Session Initiation Protocol", 451 June 2002. 453 7. Acknowledgments 455 This document was prepared using 2-Word-v2.0.template.dot. 457 Authors' Addresses 459 Ximing Michael Chen 460 LSI Corp. 461 1110 American Parkway NE 462 Room 12E-220A 463 Allentown, PA 18109 464 USA 466 Tel: +1 610 712 3596 467 Email: Michael.Chen@LSI.COM 469 Mike Coffee 470 Commetrex Corporation 471 1225 Northmeadow Pkwy, Ste 120 472 Roswell, GA 30076 474 Phone: +1 770 407 6021 475 Email: mcoffee@commetrex.com 477 Kevin P. Fleming 478 Digium, Inc. 479 445 Jan Davis Drive NW 480 Huntsville, AL 35806 481 USA 483 Phone: +1 256 428 6012 484 Email: kpfleming@digium.com 486 Gunnar Hellstrom 487 Omnitor AB 488 Renathvagen 2 489 SE-121 37 Johanneshov 490 Sweden 492 Phone: +46 708 204 288 493 Email: gunnar.hellstrom@omnitor.se 494 Paul Jones 495 Cisco Systems, Inc. 496 7025 Kit Creek Rd. 497 Research Triangle Park, NC 27709 498 USA 500 Phone: +1 919 476 2048 501 Email: paulej@packetizer.com 503 John Lunsford 504 QualityLogic, Inc. 505 5401 Tech Circle 506 Moorpark, CA 93021 508 Email: jlunsford@qualitylogic.com 510 Antonios Papageorgiou 511 Siemens Enterprise Communications 512 Metaxa 15, 14564 513 Kato Kifisia, Athens 514 Greece 516 Phone: +30 210 8189659 517 Email: antonios.papageorgiou@siemens-enterprise.com 519 Gonzalo Salgueiro 520 Cisco Systems, Inc. 521 7025 Kit Creek Rd. 522 Research Triangle Park, NC 27709 523 USA 525 Phone: +1 919 392 3266 526 Email: gsalguei@cisco.com 528 Ed Schulz 529 LSI Corporation 530 1110 American Parkway NE 531 Room 12C-265 532 Allentown, PA 18109 533 USA 535 Phone: +1 610 712 2068 536 Email: ed.schulz@lsi.com 537 Neil Weldon 538 Dialogic Corporation 539 4034 Kingswood Ave., 540 Citywest, Saggart, Co. Dublin 541 Ireland 543 Phone: +353 1 630 9000 544 Email: neil.weldon@dialogic.com