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<http://Easynews.com>--
Asterisk-Users mailing list
[email protected]
http://lists.digium.com/mailman/listinfo/asterisk-users
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
---------------End of Original Message-----------------
