Re: [Asterisk-Users] VM low volume - testers needed
The patch is in cvs-head, which has been very stable for me. :) Hi Richard, I am experiencing the same problem. I'd like to test your patch. Thing, is, I don't know which CVS it's in :) ... I checked out 1.2-beta on Tuesday (9/21) and compiled it. When I type 'show application voicemail', it does not describe the g(#) option, so I think my version must not have it. I am using a TDM22B card and voicemails seem very quiet if they are left from in incoming POTS connection. When I enter voicemail by direct dialing a local extension and leave a message from the advanced options menu, the recorded message is much louder. I should qualify, not only are my VMs coming in over POTS, I am actually calling out first through the TDM22B, to Sipura, to VOIP provider, back in via PSTN, to TDM22B, to VM. I'm amazed it works at all :) ... I'm very impressed by Asterisk and especially it's voicemail. I would like to resolve the low volume issue though. If you can tell me which CVS to check out, I can try it. I'd like to stick to the 1.2-beta branch though because I don't want to rework all my config files. On 9/21/05, Rich Adamson [EMAIL PROTECTED] wrote: On Monday 19 September 2005 12:38, Rich Adamson wrote: The g(6) adds a 6 db gain for zap calls that end up recording a Voicemail message. ... * 'g(#)' the specified amount of gain will be requested during message recording (units are whole-number decibels (dB)) How in the hell does that make any sense? are your normal incoming calls quiet too or just voicemail? Yes, see bug 2022 and 2023 for details, as well as http://www.routers.com/asteriskprob/asterisk-config.htm for a very detailed analysis of the problem. I believe one of the more serious issues amounts to: if asterisk is located a fair distance from the central office (-7db in my case), setting the rxgain and/or txgain to any level that would be considered reasonable for that loss (eg, rxgain=5, txgain=5), hugh amounts of echo result that cannot be addressed through zapata.conf echo entris, and changing compile options to agressive, etc, does not help. Its my believe (from working with several TDM users), the further one is from the CO, the bigger the problem. (Or, short pstn cable lengths less then about 4 or 5db can almost always be addressed via parameters.) The above workaround is very usable (assuming it works) when someone calls in via the pstn and leaves a voicemail (which is already at least 7db down plus their own pstn loss), and then I call in via the pstn to retrive the voicemail (now 14db down PLUS the original callers pstn loss), the audio is so faint its difficult to impossible to listen to. In my case, the asterisk box is located about 7db from the central office. As noted in bug 2023 (and 2022), calls from an outside pstn line coming into asterisk incure a 7db pstn loss (which can't be adjusted for with rxgain and txgain as changing those values to something reasonable generates echo). Retrieving that VM message from an outside location creates another 7db loss (now -14db down in total), making it very difficult (if not impossible) to hear the message. (And, yes I've gone through all the recommendations with wav vs gsm files, etc.) I am not sure I understand why the txgain/rxgain isn't fixing it without adding unacceptable echo... this all seems very odd... I mean for a test you should be able to dial an echo() application and have extremely quiet echoed audio... is this the case? As an ex-telco transmission engineer, believe me I've done my homework and some very solid testing with expensive well-calibrated test equipment. As I've mentioned to Kevin, its almost like the TigerJet pci controller on the TDM card is reversing bits six and seven (or something very odd like that). Digium apparently now has a pci engineering type looking at the issues, which I'm told is using a pci logic analyzer, etc. The work around only kicks in if the call comes from a zap channel and ends up in voicemail, adding a 6db gain to that recorded message. No other channel types are impacted by this new parameter. This is a HELL of a band-aid. If you actually follow the logic that was originally stated in 2023, this gain setting is highly useful for those systems that are further away from the CO (as mentioned above). For those closer to the CO, it has zero value. Rich ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com
Re: [Asterisk-Users] VM low volume - testers needed
Hmmm...
I checked out CVS-HEAD, built and installed it this morning. Most
testing was going well, but then I found out the behavior of
ChanIsAvail has changed (is broken?)
In my Dial Plan, if a call comes in on the PSTN line, and is not
answered by the extension (or if the extension is busy), ChanIsAvail
checks to see of the outgoing VOIP line is available. If so, it
forwards the call to the VOIP voice mail. If not, it forwards the call
to the Asterisk Voicemail.
With 1.2-beta, ChanIsAvail works for me. With CVS-HEAD, it hangs up on the caller.
Here is the relevant portion of my extensions.conf:
exten = s,7,Dial(${PHONE1},15)
exten = s,8,Goto(108)
exten = s,108,ChanIsAvail(${VOIP1})
exten = s,109,Dial(${VOIP1}/${VOIPNUM})
exten = s,209,VoiceMail(123|sbg(6))
In the globals section, VOIP1 is set equal to Zap/4
With 1.2-beta, -vvv logs show this, which is successful:
-- Executing ChanIsAvail(Zap/3-1, Zap/4) in new stack
-- Executing VoiceMail(Zap/3-1, 123|sbg(6)) in new stack
-- Playing '/var/spool/asterisk/voicemail/default/123/busy' (language 'en')
With CVS-HEAD -vvv logs show this, which is unsuccessful:
-- Executing ChanIsAvail(Zap/3-1, Zap/4) in new stack
== Spawn extension (incoming-pstn, s, 208) exited non-zero on 'Zap/3-1'
-- Hungup 'Zap/3-1'
Is there another list or someone I should mention this to? Asterisk should not hangup Zap/3-1 at this point.
On 9/24/05, Rich Adamson [EMAIL PROTECTED] wrote:
The patch is in cvs-head, which has been very stable for me. :) Hi Richard, I am experiencing the same problem. I'd like to test your patch. Thing, is, I don't know which
CVS it's in:) ... I checked out 1.2-beta on Tuesday (9/21) and compiled it. When I type 'show applicationvoicemail', it does not describe the g(#) option, so I think my version must not have it.
I am using a TDM22B card and voicemails seem very quiet if they are left from in incoming POTSconnection. When I enter voicemail by direct dialing a local extension and leave a message from the advanced options
menu, the recorded message is much louder. I should qualify, not only are my VMs coming in over POTS, I am actually calling out firstthrough the TDM22B, to Sipura, to VOIP provider, back in via PSTN, to TDM22B, to VM. I'm amazed it works at all:)... I'm very
impressed by Asterisk and especially it's voicemail. I would like to resolve the low volume issue though. If you can tell me which CVS to check out, I can try it. I'd like to stick to the 1.2-beta
branch though because I don't want to rework all my config files. On 9/21/05, Rich Adamson [EMAIL PROTECTED] wrote: On Monday 19 September 2005 12:38, Rich Adamson wrote:
The g(6) adds a 6 db gain for zap calls that end up recording a Voicemail message. ...* 'g(#)' the specified amount of gain will be requested during message
recording
(units are whole-number decibels (dB)) How in the hell does that make any sense?are your normal incoming calls quiet too or just voicemail? Yes, see bug 2022 and 2023 for details, as well as
http://www.routers.com/asteriskprob/asterisk-config.htm for a very detailed analysis of the problem. I believe one of the more serious issues amounts to: if asterisk is
located a fair distance from the central office (-7db in my case), setting the rxgain and/or txgain to any level that would be considered reasonable for that loss (eg, rxgain=5, txgain=5), hugh amounts of echo result that
cannot be addressed through zapata.conf echo entris, and changing compile options to agressive, etc, does not help. Its my believe (from working with several TDM users), the further one is from the CO,
the bigger the problem. (Or, short pstn cable lengths less then about 4 or 5db can almost always be addressed via parameters.) The above workaround is very usable (assuming it works) when someone
calls in via the pstn and leaves a voicemail (which is already at least 7db down plus their own pstn loss), and then I call in via the pstn to retrive the voicemail (now 14db down PLUS the original callers
pstn loss), the audio is so faint its difficult to impossible to listen to. In my case, the asterisk box is located about 7db from the central office. As noted in bug 2023 (and 2022), calls from an outside pstn
line coming into asterisk incure a 7db pstn loss (which can't be adjusted for with rxgain and txgain as changing those values to something reasonable generates echo).Retrieving that VM message from an outside
location creates another 7db loss (now -14db down in total), making it very difficult (if not impossible) to hear the message. (And, yes I've gone through all the recommendations with wav vs gsm files, etc.)
I am not sure I understand why the txgain/rxgain isn't fixing it without adding unacceptable echo...this all seems very odd...I mean for a test you should be able to dial an echo() application and have extremely quiet
echoed audio... is this the case? As an ex-telco transmission engineer,
Re: [Asterisk-Users] VM low volume - testers needed
Under 1.2 the +101 jumping is not enabled by default. There is a
variable returned showing the status of the application. You need to add
a j flag or put priorityjumping=yes in extensions.conf
Julian.
Brian McEntire wrote:
Hmmm...
I checked out CVS-HEAD, built and installed it this morning. Most testing
was going well, but then I found out the behavior of ChanIsAvail has changed
(is broken?)
In my Dial Plan, if a call comes in on the PSTN line, and is not answered by
the extension (or if the extension is busy), ChanIsAvail checks to see of
the outgoing VOIP line is available. If so, it forwards the call to the VOIP
voice mail. If not, it forwards the call to the Asterisk Voicemail.
With 1.2-beta, ChanIsAvail works for me. With CVS-HEAD, it hangs up on the
caller.
Here is the relevant portion of my extensions.conf:
exten = s,7,Dial(${PHONE1},15)
exten = s,8,Goto(108)
exten = s,108,ChanIsAvail(${VOIP1})
exten = s,109,Dial(${VOIP1}/${VOIPNUM})
exten = s,209,VoiceMail(123|sbg(6))
In the globals section, VOIP1 is set equal to Zap/4
With 1.2-beta, -vvv logs show this, which is successful:
-- Executing ChanIsAvail(Zap/3-1, Zap/4) in new stack
-- Executing VoiceMail(Zap/3-1, 123|sbg(6)) in new stack
-- Playing '/var/spool/asterisk/voicemail/default/123/busy' (language 'en')
With CVS-HEAD -vvv logs show this, which is unsuccessful:
-- Executing ChanIsAvail(Zap/3-1, Zap/4) in new stack
== Spawn extension (incoming-pstn, s, 208) exited non-zero on 'Zap/3-1'
-- Hungup 'Zap/3-1'
Is there another list or someone I should mention this to? Asterisk should
not hangup Zap/3-1 at this point.
On 9/24/05, Rich Adamson [EMAIL PROTECTED] wrote:
The patch is in cvs-head, which has been very stable for me. :)
Hi Richard,
I am experiencing the same problem. I'd like to test your patch. Thing,
is, I don't know which
CVS it's in :)
... I checked out 1.2-beta on Tuesday (9/21) and compiled it. When I
type 'show application
voicemail', it does not describe the
g(#) option, so I think my version must not have it.
I am using a TDM22B card and voicemails seem very quiet if they are left
from in incoming POTS
connection. When I enter
voicemail by direct dialing a local extension and leave a message from
the advanced options
menu, the recorded message is much
louder.
I should qualify, not only are my VMs coming in over POTS, I am actually
calling out first
through the TDM22B, to Sipura, to
VOIP provider, back in via PSTN, to TDM22B, to VM. I'm amazed it works
at all :) ... I'm very
impressed by Asterisk and
especially it's voicemail. I would like to resolve the low volume issue
though.
If you can tell me which CVS to check out, I can try it. I'd like to
stick to the 1.2-beta
branch though because I don't want to
rework all my config files.
On 9/21/05, Rich Adamson [EMAIL PROTECTED] wrote:
On Monday 19 September 2005 12:38, Rich Adamson wrote:
The g(6) adds a 6 db gain for zap calls that end up recording a
Voicemail
message.
...
* 'g(#)' the specified amount of gain will be requested during
message
recording (units are whole-number decibels (dB))
How in the hell does that make any sense? are your normal incoming
calls
quiet too or just voicemail?
Yes, see bug 2022 and 2023 for details, as well as
http://www.routers.com/asteriskprob/asterisk-config.htm
for a very detailed analysis of the problem.
I believe one of the more serious issues amounts to: if asterisk is
located a fair distance from the central office (-7db in my case),
setting
the rxgain and/or txgain to any level that would be considered
reasonable
for that loss (eg, rxgain=5, txgain=5), hugh amounts of echo result that
cannot be addressed through zapata.conf echo entris, and changing
compile options to agressive, etc, does not help. Its my believe
(from working with several TDM users), the further one is from the CO,
the bigger the problem. (Or, short pstn cable lengths less then about
4 or 5db can almost always be addressed via parameters.)
The above workaround is very usable (assuming it works) when someone
calls in via the pstn and leaves a voicemail (which is already at
least 7db down plus their own pstn loss), and then I call in via the
pstn to retrive the voicemail (now 14db down PLUS the original callers
pstn loss), the audio is so faint its difficult to impossible to
listen to.
In my case, the asterisk box is located about 7db from the central
office. As noted in bug 2023 (and 2022), calls from an outside pstn
line coming into asterisk incure a 7db pstn loss (which can't be
adjusted
for with rxgain and txgain as changing those values to something
reasonable generates echo). Retrieving that VM message from an
outside
location creates another 7db loss (now -14db down in total), making
it
very difficult (if not impossible) to hear the message. (And, yes
I've
gone through all the recommendations with wav vs gsm files, etc.)
I am
Re: [Asterisk-Users] VM low volume - testers needed
Hmm. Thanks for the heads up, but I'm not sure that's it.
It's jumping to 208 rather than 209, so it looks more like an off-by-one error.
I tried changing to priorityjumping=yes in
/etc/asterisk/extensions.conf and reinstalled the CVS-HEAD version, but
it still jumps to 208 whereas it used to jump to 209.
On 9/24/05, Julian Lyndon-Smith [EMAIL PROTECTED] wrote:
Under 1.2 the +101 jumping is not enabled by default. There is avariable returned showing the status of the application. You need to adda j flag or put priorityjumping=yes in extensions.confJulian.
Brian McEntire wrote: Hmmm... I checked out CVS-HEAD, built and installed it this morning. Most testing was going well, but then I found out the behavior of ChanIsAvail has changed
(is broken?) In my Dial Plan, if a call comes in on the PSTN line, and is not answered by the extension (or if the extension is busy), ChanIsAvail checks to see of the outgoing VOIP line is available. If so, it forwards the call to the VOIP
voice mail. If not, it forwards the call to the Asterisk Voicemail. With 1.2-beta, ChanIsAvail works for me. With CVS-HEAD, it hangs up on the caller. Here is the relevant portion of my
extensions.conf: exten = s,7,Dial(${PHONE1},15) exten = s,8,Goto(108) exten = s,108,ChanIsAvail(${VOIP1}) exten = s,109,Dial(${VOIP1}/${VOIPNUM}) exten = s,209,VoiceMail(123|sbg(6))
In the globals section, VOIP1 is set equal to Zap/4 With 1.2-beta, -vvv logs show this, which is successful: -- Executing ChanIsAvail(Zap/3-1, Zap/4) in new stack
-- Executing VoiceMail(Zap/3-1, 123|sbg(6)) in new stack -- Playing '/var/spool/asterisk/voicemail/default/123/busy' (language 'en') With CVS-HEAD -vvv logs show this, which is unsuccessful:
-- Executing ChanIsAvail(Zap/3-1, Zap/4) in new stack == Spawn extension (incoming-pstn, s, 208) exited non-zero on 'Zap/3-1' -- Hungup 'Zap/3-1'
Is there another list or someone I should mention this to? Asterisk should not hangup Zap/3-1 at this point. On 9/24/05, Rich Adamson
[EMAIL PROTECTED] wrote:The patch is in cvs-head, which has been very stable for me. :)Hi Richard,
I am experiencing the same problem. I'd like to test your patch. Thing,is, I don't know whichCVS it's in :)... I checked out 1.2-beta on Tuesday (9/21) and compiled it. When I
type 'show applicationvoicemail', it does not describe theg(#) option, so I think my version must not have it.I am using a TDM22B card and voicemails seem very quiet if they are left
from in incoming POTSconnection. When I entervoicemail by direct dialing a local extension and leave a message fromthe advanced options
menu, the recorded message is muchlouder.I should qualify, not only are my VMs coming in over POTS, I am actuallycalling out first
through the TDM22B, to Sipura, toVOIP provider, back in via PSTN, to TDM22B, to VM. I'm amazed it worksat all :) ... I'm veryimpressed by Asterisk and
especially it's voicemail. I would like to resolve the low volume issuethough.If you can tell me which CVS to check out, I can try it. I'd like to
stick to the 1.2-betabranch though because I don't want torework all my config files.On 9/21/05, Rich Adamson
[EMAIL PROTECTED] wrote:On Monday 19 September 2005 12:38, Rich Adamson wrote:The g(6) adds a 6 db gain for zap calls that end up recording a
Voicemailmessage* 'g(#)' the specified amount of gain will be requested during
messagerecording (units are whole-number decibels (dB))How in the hell does that make any sense? are your normal incoming
callsquiet too or just voicemail?Yes, see bug 2022 and 2023 for details, as well as
http://www.routers.com/asteriskprob/asterisk-config.htmfor a very detailed analysis of the problem.I believe one of the more serious issues amounts to: if asterisk is
located a fair distance from the central office (-7db in my case),settingthe rxgain and/or txgain to any level that would be consideredreasonable
for that loss (eg, rxgain=5, txgain=5), hugh amounts of echo result thatcannot be addressed through zapata.conf echo entris, and changingcompile options to agressive, etc, does not help. Its my believe
(from working with several TDM users), the further one is from the CO,the bigger the problem. (Or, short pstn cable lengths less then about4 or 5db can almost always be addressed via parameters.)
The above workaround is very usable (assuming it works) when someonecalls in via the pstn and leaves a voicemail (which is already atleast 7db down plus their own pstn loss), and then I call in via the
pstn to retrive the voicemail (now 14db down PLUS the original callerspstn loss), the audio is so faint its difficult to impossible tolisten to.
In my case, the asterisk box is located about 7db from the centraloffice. As noted in bug 2023 (and 2022), calls from an outside pstnline coming into asterisk incure a 7db pstn loss (which can't be
adjustedfor with rxgain and txgain as changing those values to somethingreasonable generates echo). Retrieving that VM message from an
outsidelocation
Re: [Asterisk-Users] VM low volume - testers needed
Oops, I didn't cc the list. Julian suggested I should try the older version of app_chanisavail.c and that worked out well. I can now use the g(#) switch and that works very well. On 9/24/05, Brian McEntire [EMAIL PROTECTED] wrote: That fixes it! Thanks. So I can run CVS HEAD but I need to check out -r 1.17 asterisk/apps/app_chanisavail.c to revert just that file to the old version. I guess it could still be a prob with the new app_chanisavail.c but it also looks like whatever provides ast_goto_if_exists could be at fault. - - - To Rich: The new gain g(#) switch works great! I have to bump mine up to g(12) which seems rediculously high, but then again I'm going out voip and back in PSTN and perhaps the VOIP is quieting the signal too. Anway, with g(12), voicemail messages are recorded at a very acceptable volume and sound good too. Thanks! ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] VM low volume - testers needed
Hi Richard, I am experiencing the same problem. I'd like to test your patch. Thing, is, I don't know which CVS it's in :) ... I checked out 1.2-beta on Tuesday (9/21) and compiled it. When I type 'show application voicemail', it does not describe the g(#) option, so I think my version must not have it. I am using a TDM22B card and voicemails seem very quiet if they are left from in incoming POTS connection. When I enter voicemail by direct dialing a local extension and leave a message from the advanced options menu, the recorded message is much louder. I should qualify, not only are my VMs coming in over POTS, I am actually calling out first through the TDM22B, to Sipura, to VOIP provider, back in via PSTN, to TDM22B, to VM. I'm amazed it works at all :) ... I'm very impressed by Asterisk and especially it's voicemail. I would like to resolve the low volume issue though. If you can tell me which CVS to check out, I can try it. I'd like to stick to the 1.2-beta branch though because I don't want to rework all my config files. On 9/21/05, Rich Adamson [EMAIL PROTECTED] wrote: On Monday 19 September 2005 12:38, Rich Adamson wrote: The g(6) adds a 6 db gain for zap calls that end up recording a Voicemail message. ... * 'g(#)' the specified amount of gain will be requested during message recording (units are whole-number decibels (dB)) How in the hell does that make any sense?are your normal incoming calls quiet too or just voicemail?Yes, see bug 2022 and 2023 for details, as well as http://www.routers.com/asteriskprob/asterisk-config.htmfor a very detailed analysis of the problem.I believe one of the more serious issues amounts to: if asterisk is located a fair distance from the central office (-7db in my case), settingthe rxgain and/or txgain to any level that would be considered reasonablefor that loss (eg, rxgain=5, txgain=5), hugh amounts of echo result that cannot be addressed through zapata.conf echo entris, and changingcompile options to agressive, etc, does not help. Its my believe(from working with several TDM users), the further one is from the CO,the bigger the problem. (Or, short pstn cable lengths less then about 4 or 5db can almost always be addressed via parameters.)The above workaround is very usable (assuming it works) when someonecalls in via the pstn and leaves a voicemail (which is already atleast 7db down plus their own pstn loss), and then I call in via the pstn to retrive the voicemail (now 14db down PLUS the original callerspstn loss), the audio is so faint its difficult to impossible tolisten to. In my case, the asterisk box is located about 7db from the central office. As noted in bug 2023 (and 2022), calls from an outside pstn line coming into asterisk incure a 7db pstn loss (which can't be adjusted for with rxgain and txgain as changing those values to something reasonable generates echo).Retrieving that VM message from an outside location creates another 7db loss (now -14db down in total), making it very difficult (if not impossible) to hear the message. (And, yes I've gone through all the recommendations with wav vs gsm files, etc.) I am not sure I understand why the txgain/rxgain isn't fixing it without adding unacceptable echo...this all seems very odd...I mean for a test you should be able to dial an echo() application and have extremely quiet echoed audio... is this the case?As an ex-telco transmission engineer, believe me I've done my homeworkand some very solid testing with expensive well-calibrated test equipment. As I've mentioned to Kevin, its almost like the TigerJet pci controlleron the TDM card is reversing bits six and seven (or something very oddlike that). Digium apparently now has a pci engineering type looking at the issues, which I'm told is using a pci logic analyzer, etc. The work around only kicks in if the call comes from a zap channel and ends up in voicemail, adding a 6db gain to that recorded message. No other channel types are impacted by this new parameter. This is a HELL of a band-aid.If you actually follow the logic that was originally stated in 2023,this gain setting is highly useful for those systems that are further away from the CO (as mentioned above). For those closer tothe CO, it has zero value.Rich___--Bandwidth and Colocation sponsored by Easynews.com --Asterisk-Users mailing listAsterisk-Users@lists.digium.comhttp://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] VM low volume - testers needed
On Mon, 2005-09-19 at 10:38 -0600, Rich Adamson wrote: For those that have experienced low VM recording volumes when using a Digium TDM04b (or similar analog pstn card), a work around has been committed to cvs-head. Does this mean that tracking down the cause of the low volume issue was not successful or was the workaround an easier solution? Regards, Patrick ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] VM low volume - testers needed
On Monday 19 September 2005 12:38, Rich Adamson wrote: The g(6) adds a 6 db gain for zap calls that end up recording a Voicemail message. ... * 'g(#)' the specified amount of gain will be requested during message recording (units are whole-number decibels (dB)) How in the hell does that make any sense? are your normal incoming calls quiet too or just voicemail? In my case, the asterisk box is located about 7db from the central office. As noted in bug 2023 (and 2022), calls from an outside pstn line coming into asterisk incure a 7db pstn loss (which can't be adjusted for with rxgain and txgain as changing those values to something reasonable generates echo). Retrieving that VM message from an outside location creates another 7db loss (now -14db down in total), making it very difficult (if not impossible) to hear the message. (And, yes I've gone through all the recommendations with wav vs gsm files, etc.) I am not sure I understand why the txgain/rxgain isn't fixing it without adding unacceptable echo... this all seems very odd... I mean for a test you should be able to dial an echo() application and have extremely quiet echoed audio... is this the case? The work around only kicks in if the call comes from a zap channel and ends up in voicemail, adding a 6db gain to that recorded message. No other channel types are impacted by this new parameter. This is a HELL of a band-aid. -A. ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] VM low volume - testers needed
On Mon, 2005-09-19 at 10:38 -0600, Rich Adamson wrote: For those that have experienced low VM recording volumes when using a Digium TDM04b (or similar analog pstn card), a work around has been committed to cvs-head. Does this mean that tracking down the cause of the low volume issue was not successful or was the workaround an easier solution? It means this is a short-term work around while there is an ongong effort to identify the root cause (along with other possible TDM issues). ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] VM low volume - testers needed
On Monday 19 September 2005 12:38, Rich Adamson wrote: The g(6) adds a 6 db gain for zap calls that end up recording a Voicemail message. ... * 'g(#)' the specified amount of gain will be requested during message recording (units are whole-number decibels (dB)) How in the hell does that make any sense? are your normal incoming calls quiet too or just voicemail? Yes, see bug 2022 and 2023 for details, as well as http://www.routers.com/asteriskprob/asterisk-config.htm for a very detailed analysis of the problem. I believe one of the more serious issues amounts to: if asterisk is located a fair distance from the central office (-7db in my case), setting the rxgain and/or txgain to any level that would be considered reasonable for that loss (eg, rxgain=5, txgain=5), hugh amounts of echo result that cannot be addressed through zapata.conf echo entris, and changing compile options to agressive, etc, does not help. Its my believe (from working with several TDM users), the further one is from the CO, the bigger the problem. (Or, short pstn cable lengths less then about 4 or 5db can almost always be addressed via parameters.) The above workaround is very usable (assuming it works) when someone calls in via the pstn and leaves a voicemail (which is already at least 7db down plus their own pstn loss), and then I call in via the pstn to retrive the voicemail (now 14db down PLUS the original callers pstn loss), the audio is so faint its difficult to impossible to listen to. In my case, the asterisk box is located about 7db from the central office. As noted in bug 2023 (and 2022), calls from an outside pstn line coming into asterisk incure a 7db pstn loss (which can't be adjusted for with rxgain and txgain as changing those values to something reasonable generates echo). Retrieving that VM message from an outside location creates another 7db loss (now -14db down in total), making it very difficult (if not impossible) to hear the message. (And, yes I've gone through all the recommendations with wav vs gsm files, etc.) I am not sure I understand why the txgain/rxgain isn't fixing it without adding unacceptable echo... this all seems very odd... I mean for a test you should be able to dial an echo() application and have extremely quiet echoed audio... is this the case? As an ex-telco transmission engineer, believe me I've done my homework and some very solid testing with expensive well-calibrated test equipment. As I've mentioned to Kevin, its almost like the TigerJet pci controller on the TDM card is reversing bits six and seven (or something very odd like that). Digium apparently now has a pci engineering type looking at the issues, which I'm told is using a pci logic analyzer, etc. The work around only kicks in if the call comes from a zap channel and ends up in voicemail, adding a 6db gain to that recorded message. No other channel types are impacted by this new parameter. This is a HELL of a band-aid. If you actually follow the logic that was originally stated in 2023, this gain setting is highly useful for those systems that are further away from the CO (as mentioned above). For those closer to the CO, it has zero value. Rich ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] VM low volume - testers needed
For those that have experienced low VM recording volumes when using a Digium TDM04b (or similar analog pstn card), a work around has been committed to cvs-head. Need some folks to test it; it doesn't seem to work for me, but need some feedback from others to ensure the work around is actually functioning. (The work around relates back to bug #2023, and was committed around Thursday or Friday last week.) The work around involves adding g(6) to an exten definition like this: exten = 3000,1,Dial(SIP/3000,15,r) exten = 3000,2,Voicemail(3000|ug(6)) exten = 3000,102,Voicemail(3000|bg(6)) exten = 3000,103,Hangup The g(6) adds a 6 db gain for zap calls that end up recording a Voicemail message. show application voicemail indicates: [Synopsis] Leave a voicemail message [Description] VoiceMail([EMAIL PROTECTED][EMAIL PROTECTED]|options]): Leavesvoicem ail for a given mailbox (must be configured in voicemail.conf). If the options contain: * 's'instructions for leaving the message will be skipped. * 'u'the unavailable greeting will be played. * 'b'the busy greeting will be played. * 'g(#)' the specified amount of gain will be requested during message recording (units are whole-number decibels (dB)) In my case, the asterisk box is located about 7db from the central office. As noted in bug 2023 (and 2022), calls from an outside pstn line coming into asterisk incure a 7db pstn loss (which can't be adjusted for with rxgain and txgain as changing those values to something reasonable generates echo). Retrieving that VM message from an outside location creates another 7db loss (now -14db down in total), making it very difficult (if not impossible) to hear the message. (And, yes I've gone through all the recommendations with wav vs gsm files, etc.) The work around only kicks in if the call comes from a zap channel and ends up in voicemail, adding a 6db gain to that recorded message. No other channel types are impacted by this new parameter. Could others that have this same issue give the above a try to see if it impacts your VM recordings? (Kevin tested it on his development workstation and it seemed to work, but he's at VON right now and can't do much testing. Both of us are looking for a little help with the testing effort.) Post results to the -user list please. Rich ___ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
