Re: [Asterisk-Users] E1 Echo (was: Small explanation of txgain rx gain statement please)
On 12/15/05, Colin Anderson [EMAIL PROTECTED] wrote: Does anyone have any experience in this area? Any ideas? How heavy handed would it be to increase the tap length to 256? I have not seen anyone suggest that this might be a good idea. On my PRI, 256 made things bad, super echo-y. Moving back to 128 works good 99% of the time, for me. I tried this last night, and have to agree that 256 does seem to be somehow broken. Thanks for the datapoint. Regards, Steve ___ --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] E1 Echo
I am beginning to wonder whether what echo IS heard is being caused by packetisation delays in the network - The default tap length is 128, or I believe 16ms. If something in the PSTN causes a delay more than that length (no idea what might cause that) then echo would still be heard. We have found that a relatively innocent change by the local incumbent operator has forced us to modify our pstn gateways to change from 128 taps to 256 taps. What type of a change did they make? ___ --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] E1 Echo
Rich Adamson wrote: We have found that a relatively innocent change by the local incumbent operator has forced us to modify our pstn gateways to change from 128 taps to 256 taps. What type of a change did they make? Although it's a bit unclear how things evolved exactly (since no-one ever tells us), a number of interconnection points throughout the country were consolidated, significantly increasing the chance that delay exceeded 128 taps. ___ --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] E1 Echo
We have found that a relatively innocent change by the local incumbent operator has forced us to modify our pstn gateways to change from 128 taps to 256 taps. What type of a change did they make? Although it's a bit unclear how things evolved exactly (since no-one ever tells us), a number of interconnection points throughout the country were consolidated, significantly increasing the chance that delay exceeded 128 taps. Strange... I would never had expected consolidation to have that kind of impact. It almost sounds like they have something in the E1 data stream that buffers (and delays) content, maybe decoding and re-encoding in some fashion. ___ --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] E1 Echo
On Friday 16 December 2005 08:12, Florian Overkamp wrote: Although it's a bit unclear how things evolved exactly (since no-one ever tells us), a number of interconnection points throughout the country were consolidated, significantly increasing the chance that delay exceeded 128 taps. I need to do some investigation of bringing the tap count WELL above that... I'd like to see what kind of performance we can get with 128 MILLISECOND tail... 128 taps is only 16ms... and 16ms of echo cancel is damn near useless, as it's fast enough that you'd likely not even hear the echo as anything more than a sidetone anyway. I imagine it's deathly hard on the CPU though. :-) -A. ___ --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] E1 Echo
Andrew Kohlsmith wrote: On Friday 16 December 2005 08:12, Florian Overkamp wrote: Although it's a bit unclear how things evolved exactly (since no-one ever tells us), a number of interconnection points throughout the country were consolidated, significantly increasing the chance that delay exceeded 128 taps. I need to do some investigation of bringing the tap count WELL above that... I'd like to see what kind of performance we can get with 128 MILLISECOND tail... 128 taps is only 16ms... and 16ms of echo cancel is damn near useless, as it's fast enough that you'd likely not even hear the echo as anything more than a sidetone anyway. I imagine it's deathly hard on the CPU though. :-) Actually, the problem is different. If you receive an echo on the PSTN gateway that has a 16ms echo, the problem would not be noticeable there, but if you then add a VoIP connection the delay added would make the echo audible. Florian ___ --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] E1 Echo
Rich Adamson wrote: Strange... I would never had expected consolidation to have that kind of impact. It almost sounds like they have something in the E1 data stream that buffers (and delays) content, maybe decoding and re-encoding in some fashion. Well, the problem is the difference between keeping under 16ms and sliding _just_ over limit to 18ms would make the effect audible almost immediately. We used the sangoma echospike tools to measure the delay and adjusted our taps accordingly. Florian ___ --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] E1 Echo
On Friday 16 December 2005 09:02, Florian Overkamp wrote: Well, the problem is the difference between keeping under 16ms and sliding _just_ over limit to 18ms would make the effect audible almost immediately. We used the sangoma echospike tools to measure the delay and adjusted our taps accordingly. Sangoma echospike tools? Please elaborate! -A. ___ --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] E1 Echo
Well, the problem is the difference between keeping under 16ms and sliding _just_ over limit to 18ms would make the effect audible almost immediately. We used the sangoma echospike tools to measure the delay and adjusted our taps accordingly. Sangoma echospike tools? Please elaborate! See sangoma's -users posting from Dec 13th, which I quote: I just wanted to let you know that we do provide a tool to debug echo. We send a unit impulse and record the Finite Impulse Response (FIR) so it can be plotted and analyzed. The code that does this is the release at ftp.sangoma.com/linux/custom/2.3.4. Instructions on using it are in the wiki in http://sangoma.editme.com/wanpipe-linux-asterisk-debugging. Although the code is wanpipe, all the interaction is at the zaptel level, so I am pretty sure it will work on Digium or other cards as well. Just being able to see what the echo looks like on a troublesome line gives quite a lot of info. You can see if the echo is delayed, or markedly non-linear. I haven't tried it as yet but plan to do so. Rich ___ --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] E1 Echo
Hi Rich, Rich Adamson wrote: Sangoma echospike tools? Please elaborate! See sangoma's -users posting from Dec 13th, which I quote: I just wanted to let you know that we do provide a tool to debug echo. We send a unit impulse and record the Finite Impulse Response (FIR) so it can be plotted and analyzed. The code that does this is the release at ftp.sangoma.com/linux/custom/2.3.4. Instructions on using it are in the wiki in http://sangoma.editme.com/wanpipe-linux-asterisk-debugging. Although the code is wanpipe, all the interaction is at the zaptel level, so I am pretty sure it will work on Digium or other cards as well. Just being able to see what the echo looks like on a troublesome line gives quite a lot of info. You can see if the echo is delayed, or markedly non-linear. I haven't tried it as yet but plan to do so. Correct, this is what we used. Florian ___ --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
[Asterisk-Users] E1 Echo (was: Small explanation of txgain rxgain statement please)
On 12/15/05, Rich Adamson [EMAIL PROTECTED] wrote: I was just looking at: http://www.asteriskdocs.org/modules/tinycontent/content/docbook/current/docs-html/x1695. html regarding echo canceller tuning, and I noticed the statement Most people find that they need an rxgain level around 8.0 to have good echo cancellation. The txgain setting varies from installation to installation. Which feels a bit wrong :) Could someone explain why increasing the gain on the inbound zap leg (rxgain) would improve echo cancellation? Of have I misunderstood the roles and meanings of rxgain and txgain? [snip] Many thanks for clearing that up for me :) the largest part of my misunderstanding was caused by not noticing that that article was referring to the tuning of an FXO line. I am in fact trying to find information on the tuning of an E1 to reduce echo. (Doh!) In theory of course an E1 should work with rxgain=0.0, txgain=0.0 (assuming there is no digital messing going on in the network) and the echo canceller should have a relatively easy job of cancelling echo given that the large majority of the UK phone network is digital, and only the last leg at the far end is usually analogue. I am running Asterisk 1.0.9, and have backported the KB1 canceller into Zaptel 1.0.9.2, which does not seem to have caused any problems. Nor has it really caused any improvement though :) I am beginning to wonder whether what echo IS heard is being caused by packetisation delays in the network - The default tap length is 128, or I believe 16ms. If something in the PSTN causes a delay more than that length (no idea what might cause that) then echo would still be heard. Does anyone have any experience in this area? Any ideas? How heavy handed would it be to increase the tap length to 256? I have not seen anyone suggest that this might be a good idea. Thanks, Steve ___ --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] E1 Echo (was: Small explanation of txgain rxgain statement please)
I was just looking at: http://www.asteriskdocs.org/modules/tinycontent/content/docbook/current/docs-html/x1695. html regarding echo canceller tuning, and I noticed the statement Most people find that they need an rxgain level around 8.0 to have good echo cancellation. The txgain setting varies from installation to installation. Which feels a bit wrong :) Could someone explain why increasing the gain on the inbound zap leg (rxgain) would improve echo cancellation? Of have I misunderstood the roles and meanings of rxgain and txgain? [snip] Many thanks for clearing that up for me :) the largest part of my misunderstanding was caused by not noticing that that article was referring to the tuning of an FXO line. I am in fact trying to find information on the tuning of an E1 to reduce echo. (Doh!) In theory of course an E1 should work with rxgain=0.0, txgain=0.0 (assuming there is no digital messing going on in the network) and the echo canceller should have a relatively easy job of cancelling echo given that the large majority of the UK phone network is digital, and only the last leg at the far end is usually analogue. That last leg is usually part of the problem since there is going to be a hybrid conversion. I am running Asterisk 1.0.9, and have backported the KB1 canceller into Zaptel 1.0.9.2, which does not seem to have caused any problems. Nor has it really caused any improvement though :) The KB1 canceller improves echo, but it appears as though it achieved better results by forcing half-duplex communications. From a pure non-technical user perspective, the quality of a telephone conversation has been lowered simply because humans are use to communicating in full duplex mode. I am beginning to wonder whether what echo IS heard is being caused by packetisation delays in the network - The default tap length is 128, or I believe 16ms. If something in the PSTN causes a delay more than that length (no idea what might cause that) then echo would still be heard. Certainly not hard to change the tap length and eval it. Does anyone have any experience in this area? Any ideas? How heavy handed would it be to increase the tap length to 256? I have not seen anyone suggest that this might be a good idea. ___ --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] E1 Echo (was: Small explanation of txgain rx gain statement please)
Does anyone have any experience in this area? Any ideas? How heavy handed would it be to increase the tap length to 256? I have not seen anyone suggest that this might be a good idea. On my PRI, 256 made things bad, super echo-y. Moving back to 128 works good 99% of the time, for me. ___ --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] E1 Echo
Hi, Rich Adamson wrote: I am beginning to wonder whether what echo IS heard is being caused by packetisation delays in the network - The default tap length is 128, or I believe 16ms. If something in the PSTN causes a delay more than that length (no idea what might cause that) then echo would still be heard. We have found that a relatively innocent change by the local incumbent operator has forced us to modify our pstn gateways to change from 128 taps to 256 taps. Since th Does anyone have any experience in this area? Any ideas? How heavy handed would it be to increase the tap length to 256? I have not seen anyone suggest that this might be a good idea. There have been a few issues especially related to the echotraining section (which can go boo-boo on E1 lines because the audio path is not always entirely complete when zaptel expects it to). If you make sure you are on recent zaptel EC standards you can up to 256 taps. There will be a minor residue that needs work, but it will allow a lot of room to decrease the loss-plan you may be using now. Florian. ___ --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
