[Asterisk-Users] VM low volume - testers needed

Sat Sep 24 10:37:31 MST 2005

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 <radamson at routers.com> 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 <radamson at routers.com> 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
> > Asterisk-Users at 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
> ---------------End of Original Message-----------------
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20050924/53003bb7/attachment.htm