[asterisk-users] Zap channel faxing in or out fails but phone calls work.
I have AAH2.8 on a dual Xeon system with a Sangoma A104 and an Adtran Channel Bank. The system has a single PRI connected to port 1 and port 2 has the T1 cable connected to the Channel Bank. Both are configured properly and work for the inbound/outbound calls and soft-fax reception. I have fax machines connected to FXS ports on the channel bank. The idea here is to allow faxing out over the PRI from these FXS ports and for inbound DIDs to go to specific fax machines. I have [EMAIL PROTECTED] 2.8 setup on this system and I am pretty certain I have it configured correctly. * Each fax machine has it's own Zap extension. * The DID routes to the correct fax machine (zap extension). * I can make and receive phone calls with these fax machines. Meaning, the fax machine has a phone hand set. I can call out with that handset and receive calls on that handset. Here's the problem. When I try send or receive faxes it fails telling me there was a com error. Any ideas? I am at a loss. I have followed the logs. The transmit and receive work. Once the connection is made it fails indicating "com error". Additionally, I hear the "whistle and chirp" of fax machines talking to each other. Combined with being able to make and receive calls over those fax machine hand sets I don't know what the problem is at this point. Please, if anyone has fax machines setup with a similar situation I would appreciate knowing how you have it setup. OS - CentOS 4.3 zaptel - 1.2.5 libpri - 1.2.3 asterisk - 1.2.9.1 freepbx - 2.0.1 Thank you, Greg -- This message has been scanned for viruses and dangerous content and is believed to be clean. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zap channel faxing in or out fails but phone calls work.
I had similar problems with a Sangoma card in this configuration. I recently recieved from Sangoma an updated driver that fixed issues with resyncing the clock on the card. You might try getting a hold of Sangoma, David Yat Sin if possible and ask him about it, it may very well be the same problew. On 7/19/06, Gregory L Miller-Kramer [EMAIL PROTECTED] wrote: I have AAH2.8 on a dual Xeon system with a Sangoma A104 and an Adtran Channel Bank. The system has a single PRI connected to port 1 and port 2 has the T1 cable connected to the Channel Bank. Both are configured properly and work for the inbound/outbound calls and soft-fax reception. I have fax machines connected to FXS ports on the channel bank. The idea here is to allow faxing out over the PRI from these FXS ports and for inbound DIDs to go to specific fax machines. I have [EMAIL PROTECTED] 2.8 setup on this system and I am pretty certain I have it configured correctly. * Each fax machine has it's own Zap extension. * The DID routes to the correct fax machine (zap extension). * I can make and receive phone calls with these fax machines. Meaning, the fax machine has a phone hand set. I can call out with that handset and receive calls on that handset. Here's the problem. When I try send or receive faxes it fails telling me there was a com error. Any ideas? I am at a loss. I have followed the logs. The transmit and receive work. Once the connection is made it fails indicating com error. Additionally, I hear the whistle and chirp of fax machines talking to each other. Combined with being able to make and receive calls over those fax machine hand sets I don't know what the problem is at this point. Please, if anyone has fax machines setup with a similar situation I would appreciate knowing how you have it setup. OS - CentOS 4.3 zaptel - 1.2.5 libpri - 1.2.3 asterisk - 1.2.9.1 freepbx - 2.0.1 Thank you, Greg -- This message has been scanned for viruses and dangerous content and is believed to be clean. ___--Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing listTo UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users-- BruceNortex Networks ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zap channel faxing in or out fails but phone calls work.
Just a couple checks... You are using G711u for the FXS - right? Also if possible turn off ECM on the FAX machines Otherwise I have never used Sangoma cars but this configuration works very well with Digium cards, at least with asterisk, I do not use aah On Jul 19, 2006, at 11:11 AM, Bruce Reeves wrote: I had similar problems with a Sangoma card in this configuration. I recently recieved from Sangoma an updated driver that fixed issues with resyncing the clock on the card. You might try getting a hold of Sangoma, David Yat Sin if possible and ask him about it, it may very well be the same problew. On 7/19/06, Gregory L Miller-Kramer [EMAIL PROTECTED] wrote: I have AAH2.8 on a dual Xeon system with a Sangoma A104 and an Adtran Channel Bank. The system has a single PRI connected to port 1 and port 2 has the T1 cable connected to the Channel Bank. Both are configured properly and work for the inbound/outbound calls and soft-fax reception. I have fax machines connected to FXS ports on the channel bank. The idea here is to allow faxing out over the PRI from these FXS ports and for inbound DIDs to go to specific fax machines. I have [EMAIL PROTECTED] 2.8 setup on this system and I am pretty certain I have it configured correctly. * Each fax machine has it's own Zap extension. * The DID routes to the correct fax machine (zap extension). * I can make and receive phone calls with these fax machines. Meaning, the fax machine has a phone hand set. I can call out with that handset and receive calls on that handset. Here's the problem. When I try send or receive faxes it fails telling me there was a com error. Any ideas? I am at a loss. I have followed the logs. The transmit and receive work. Once the connection is made it fails indicating com error. Additionally, I hear the whistle and chirp of fax machines talking to each other. Combined with being able to make and receive calls over those fax machine hand sets I don't know what the problem is at this point. Please, if anyone has fax machines setup with a similar situation I would appreciate knowing how you have it setup. OS - CentOS 4.3 zaptel - 1.2.5 libpri - 1.2.3 asterisk - 1.2.9.1 freepbx - 2.0.1 Thank you, Greg -- This message has been scanned for viruses and dangerous content and is believed to be clean. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users -- Bruce Nortex Networks ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zap channel faxing in or out fails but phone calls work.
Jerry Jones wrote: Also if possible turn off ECM on the FAX machines This is unsound advice. Why do you think this could possily help? Lee. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zap channel faxing in or out fails but phone calls work.
On 7/19/06, Lee Howard [EMAIL PROTECTED] wrote: Jerry Jones wrote: Also if possible turn off ECM on the FAX machines This is unsound advice. Why do you think this could possily help? Lee. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users Actually it's quite rational. Check the paragraph on ECM at http://www.voip-info.org/wiki-Asterisk+fax -- Cheers, Maxim Vexler Free as in Freedom - Do u GNU ? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zap channel faxing in or out fails but phone calls work.
without ecm - line errors will cause slight imperfections (dots) on transmitted image with ecm - retry, retry, retry, fail On Jul 19, 2006, at 12:23 PM, Maxim Vexler wrote: On 7/19/06, Lee Howard [EMAIL PROTECTED] wrote: Jerry Jones wrote: Also if possible turn off ECM on the FAX machines This is unsound advice. Why do you think this could possily help? Lee. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users Actually it's quite rational. Check the paragraph on ECM at http://www.voip-info.org/wiki-Asterisk +fax -- Cheers, Maxim Vexler Free as in Freedom - Do u GNU ? ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zap channel faxing in or out fails but phone calls work.
Maxim Vexler wrote: Check the paragraph on ECM at http://www.voip-info.org/wiki-Asterisk+fax Everything that you read on a wiki must be considered potentially bogus or otherwise misinformed. Let me rewrite that paragraph for you... ECM - error correction mode Good fax machines with proper memory and programming are able to use Error Correction Mode (ECM) for error-free image transmission. When ECM is used, a fax page is transmitted as a series of blocks, each block consisting of a series of HDLC data frames. After receiving the data for a complete block, a receiving fax machine notifies the transmitting fax machine of any frames with errors. The transmitting fax machine then may retransmit the specified frames. This process may be repeated until all frames are received without errors, and then the procedure may continue on to the next block. If, for some reason, the receiving fax machine is unable to receive an error-free block, the fax sender may abort and disconnect, thus leaving the receiver with a partial or truncated image. The sentence that begins, On networks that have a packet loss rate... is simply nonsense, first-off, and what truth it is actually hinting at is as relevant to non-ECM faxing as it is to ECM faxing. The intent of that sentence is probably directed towards the situation where you'd have a fax machine plugged into an ATA that is communicating to your LAN-hosted PBX that has PSTN connections. So let me talk about that situation... In order to experience packet-loss or some other kind of jitter on a LAN you either have problems with the LAN or your LAN bandwidth is seriously stretched. VoIP packets running on a LAN are *far* more reliable than VoIP packets running over the internet. So if you truly are experiencing 2% packet loss on a LAN between the ATA and the PBX, then there are network issues that need to be resolved. In truth, most of the issues involved with using a fax machine on an ATA are not going to be network-related... but instead they're going to deal with issues in the ATA and in the PBX themselves when handling audio like fax that reliably cannot be corrupted (jitter buffers, echo cancellation, proper function, etc.). The typical packet loss issues that Asterisk users see with fax are not network related, but rather deal with issues in the zaptel hardware or driver. This has nothing to do with whether or not ECM is being used. These issues generally cause premature carrier loss detection to occur by the fax receiver (meaning that the missing audio became silence somewhere along the audio path). Fax protocol uses carrier loss as a way to indicate end-of-signal or end-of-message. If carrier loss is detected prematurely then the connectivity between endpoints is put at risk and recovery largly will depend on the receiver's tolerance for that situation. In fact, in these kinds of situations using ECM on a well-tolerant receiver may actually prove to be the only way that reliable fax reception can occur. Whether or not that is the case depends upon the timings of the packet loss the effect of that packet loss on the receiver, and the data format used for the image. By disabling ECM you limit data format types to MH and MR - which are both image format types that are generally rather tolerant of data corruption. So if the packet loss translates into image data corruption and not premature carrier loss and if the amount of data corruption is negligible to the human eye, then it may appear that disabling ECM will help. The chances that enabling ECM on an ATA-connected receiver will cause fax failures are pretty slim, in my expectation... and if it actually did, then I would suspect more fault lies on the ECM implementation on the receiver than in the nature of the ECM protocol itself. Lee. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zap channel faxing in or out fails but phone calls work.
Jerry Jones wrote: without ecm - line errors will cause slight imperfections (dots) on transmitted image with ecm - retry, retry, retry, fail In the ECM retransmissions only the frames that were not received properly are resent. Once the data to send is assembled by the sender it is transmitted in exactly the same way as with non-ECM communications. So as an example let's say that an ECM page consisting of a single block of 100 frames is sent, and that a slight imperfection is detected, so maybe 10 frames are bad: frames 5, 15, 25, 35, 45, 55, 65, 75, 85, and 95. ECM protocol will cause there to be three more retransmissions before the sender has a deliberate chance to abort retransmissions. You can probably see that the same slight imperfection would have a difficult time persisting through three more iterations. However, for the sake of argument, let's say that frames 5, 55, and 95 still aren't received properly by the 3rd retransmission (4th attempt). The sender then has the choice to change the speed of transmission and continue another set of 4 retransmissions or to end retransmissions and (in theory) move on to the next block. Most fax machines will abort the call if they do not choose to continue retransmissions... even if they do signal that they're going to move on to the next block. So at that point the receiver is left with a page of image data with some very slight imperfections in frames 5, 55, and 95. Now it's up to the receiver to be able to make something out of that image. If the image type is MH or MR then the receiver is going to be able to print out the full page... with maybe some dots as you say. If the image type is MMR then the image will be truncated at the data where frame 5 occurs (pretty much the top of the page). If the image type is JBIG then the end result will depend upon the decoder... but generally the decoders are lightly tolerant of some slight data corruption, but too much corruption will be a problem. So at the end of all of this contrived scenario the problem in not getting a slightly imperfect image out of an ECM-using fax machine would be due to the data type more than it woudl be due to the usage of ECM. If you truly are experiencing the kind of, perhaps contrived, situation where retry, retry, retry, fail occurs then I would expect that disabling MMR+JBIG would be more effective than disabling ECM. (Yes, disabling ECM does also disable MMR and JBIG, but you can use ECM with MH and MR and thus benefit of a tolerant image type *and* a tolerant protocol.) If you continue to experience problems with ECM without MMR/JBIG then you will (guaranteed) experience problems without ECM. Lee. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Zap channel faxing in or out fails but phone calls work.
I would agree with you on just about everything. Except the op had his fax connected via channel bank directly to * and a pri on the other port - ie no packets involved here. However - all faxing does involve the transfer of frames from one fax to the other and that is was ecm handles. But yes even with traditional tdm circuits in between and no voip you still get frame losses. Which should be minimal and ecm should be able to compensate for. However, in the real world (tm), most of my customers are very sensitive to how long does it take to send a page vs are there any slight imperfections on a page. And yes we have found that MOST issues involve poor fax machines. Why customers whose 'business depends on these 100s of faxes daily' choose to buy $100 faxes and place on a single line is beyond my comprehension. Everything that you read on a wiki must be considered potentially bogus or otherwise misinformed. Let me rewrite that paragraph for you... ECM - error correction mode Good fax machines with proper memory and programming are able to use Error Correction Mode (ECM) for error-free image transmission. When ECM is used, a fax page is transmitted as a series of blocks, each block consisting of a series of HDLC data frames. After receiving the data for a complete block, a receiving fax machine notifies the transmitting fax machine of any frames with errors. The transmitting fax machine then may retransmit the specified frames. This process may be repeated until all frames are received without errors, and then the procedure may continue on to the next block. If, for some reason, the receiving fax machine is unable to receive an error-free block, the fax sender may abort and disconnect, thus leaving the receiver with a partial or truncated image. The sentence that begins, On networks that have a packet loss rate... is simply nonsense, first-off, and what truth it is actually hinting at is as relevant to non-ECM faxing as it is to ECM faxing. The intent of that sentence is probably directed towards the situation where you'd have a fax machine plugged into an ATA that is communicating to your LAN-hosted PBX that has PSTN connections. So let me talk about that situation... In order to experience packet-loss or some other kind of jitter on a LAN you either have problems with the LAN or your LAN bandwidth is seriously stretched. VoIP packets running on a LAN are *far* more reliable than VoIP packets running over the internet. So if you truly are experiencing 2% packet loss on a LAN between the ATA and the PBX, then there are network issues that need to be resolved. In truth, most of the issues involved with using a fax machine on an ATA are not going to be network-related... but instead they're going to deal with issues in the ATA and in the PBX themselves when handling audio like fax that reliably cannot be corrupted (jitter buffers, echo cancellation, proper function, etc.). The typical packet loss issues that Asterisk users see with fax are not network related, but rather deal with issues in the zaptel hardware or driver. This has nothing to do with whether or not ECM is being used. These issues generally cause premature carrier loss detection to occur by the fax receiver (meaning that the missing audio became silence somewhere along the audio path). Fax protocol uses carrier loss as a way to indicate end-of-signal or end-of- message. If carrier loss is detected prematurely then the connectivity between endpoints is put at risk and recovery largly will depend on the receiver's tolerance for that situation. In fact, in these kinds of situations using ECM on a well-tolerant receiver may actually prove to be the only way that reliable fax reception can occur. Whether or not that is the case depends upon the timings of the packet loss the effect of that packet loss on the receiver, and the data format used for the image. By disabling ECM you limit data format types to MH and MR - which are both image format types that are generally rather tolerant of data corruption. So if the packet loss translates into image data corruption and not premature carrier loss and if the amount of data corruption is negligible to the human eye, then it may appear that disabling ECM will help. The chances that enabling ECM on an ATA-connected receiver will cause fax failures are pretty slim, in my expectation... and if it actually did, then I would suspect more fault lies on the ECM implementation on the receiver than in the nature of the ECM protocol itself. Lee. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit:
