[Asterisk-Users] VM low volume - testers needed

Sat Sep 24 10:41:53 MST 2005

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 <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-----------------
>>
>>
>>
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> --Bandwidth and Colocation sponsored by 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