Hmm. Thanks for the heads up, but I'm not sure that's it.<br>
<br>
It's jumping to 208 rather than 209, so it looks more like an off-by-one error.<br>
<br>
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.<br><br>
<br>
<br><div><span class="gmail_quote">On 9/24/05, <b class="gmail_sendername">Julian Lyndon-Smith</b> <<a href="mailto:asterisk@dotr.com">asterisk@dotr.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Under 1.2 the +101 jumping is not enabled by default. There is a<br>variable returned showing the status of the application. You need to add<br>a "j" flag or put priorityjumping=yes in extensions.conf<br><br>Julian.
<br><br>Brian McEntire wrote:<br>> Hmmm...<br>><br>> I checked out CVS-HEAD, built and installed it this morning. Most testing<br>> was going well, but then I found out the behavior of ChanIsAvail has changed<br>
> (is broken?)<br>><br>><br>> In my Dial Plan, if a call comes in on the PSTN line, and is not answered by<br>> the extension (or if the extension is busy), ChanIsAvail checks to see of<br>> the outgoing VOIP line is available. If so, it forwards the call to the VOIP
<br>> voice mail. If not, it forwards the call to the Asterisk Voicemail.<br>><br>> With 1.2-beta, ChanIsAvail works for me. With CVS-HEAD, it hangs up on the<br>> caller.<br>><br>> Here is the relevant portion of my
extensions.conf:<br>><br>> exten => s,7,Dial(${PHONE1},15)<br>> exten => s,8,Goto(108)<br>> exten => s,108,ChanIsAvail(${VOIP1})<br>> exten => s,109,Dial(${VOIP1}/${VOIPNUM})<br>> exten => s,209,VoiceMail(123|sbg(6))
<br>><br>><br>> In the globals section, VOIP1 is set equal to Zap/4<br>><br>> With 1.2-beta, -vvv logs show this, which is successful:<br>><br>> -- Executing ChanIsAvail("Zap/3-1", "Zap/4") in new stack
<br>> -- Executing VoiceMail("Zap/3-1", "123|sbg(6)") in new stack<br>> -- Playing '/var/spool/asterisk/voicemail/default/123/busy' (language 'en')<br>><br>><br>> With CVS-HEAD -vvv logs show this, which is unsuccessful:
<br>><br>> -- Executing ChanIsAvail("Zap/3-1", "Zap/4") in new stack<br>> == Spawn extension (incoming-pstn, s, 208) exited non-zero on 'Zap/3-1'<br>> -- Hungup 'Zap/3-1'<br>><br>><br>
> Is there another list or someone I should mention this to? Asterisk should<br>> not hangup Zap/3-1 at this point.<br>><br>><br>><br>> On 9/24/05, Rich Adamson <<a href="mailto:radamson@routers.com">
radamson@routers.com</a>> wrote:<br>><br>>>The patch is in cvs-head, which has been very stable for me. :)<br>>><br>>>------------------------<br>>><br>>><br>>>>Hi Richard,<br>
>>>I am experiencing the same problem. I'd like to test your patch. Thing,<br>>><br>>>is, I don't know which<br>>>CVS it's in :)<br>>><br>>>>... I checked out 1.2-beta on Tuesday (9/21) and compiled it. When I
<br>>><br>>>type 'show application<br>>>voicemail', it does not describe the<br>>><br>>>>g(#) option, so I think my version must not have it.<br>>>><br>>>>I am using a TDM22B card and voicemails seem very quiet if they are left
<br>>><br>>>from in incoming POTS<br>>>connection. When I enter<br>>><br>>>>voicemail by direct dialing a local extension and leave a message from<br>>><br>>>the advanced options
<br>>>menu, the recorded message is much<br>>><br>>>>louder.<br>>>><br>>>>I should qualify, not only are my VMs coming in over POTS, I am actually<br>>><br>>>calling out first
<br>>>through the TDM22B, to Sipura, to<br>>><br>>>>VOIP provider, back in via PSTN, to TDM22B, to VM. I'm amazed it works<br>>><br>>>at all :) ... I'm very<br>>>impressed by Asterisk and
<br>>><br>>>>especially it's voicemail. I would like to resolve the low volume issue<br>>><br>>>though.<br>>><br>>>>If you can tell me which CVS to check out, I can try it. I'd like to
<br>>><br>>>stick to the 1.2-beta<br>>>branch though because I don't want to<br>>><br>>>>rework all my config files.<br>>>><br>>>>On 9/21/05, Rich Adamson <<a href="mailto:radamson@routers.com">
radamson@routers.com</a>> wrote:<br>>>><br>>>><br>>>>>On Monday 19 September 2005 12:38, Rich Adamson wrote:<br>>>>><br>>>>>>The g(6) adds a 6 db gain for zap calls that end up recording a
<br>>><br>>>Voicemail<br>>><br>>>>>>message.<br>>>>><br>>>>>...<br>>>>><br>>>>><br>>>>>>* 'g(#)' the specified amount of gain will be requested during
<br>>><br>>>message<br>>><br>>>>>>recording (units are whole-number decibels (dB))<br>>>>><br>>>>>How in the hell does that make any sense? are your normal incoming
<br>>><br>>>calls<br>>><br>>>>>quiet too or just voicemail?<br>>>><br>>>>Yes, see bug 2022 and 2023 for details, as well as<br>>>><a href="http://www.routers.com/asteriskprob/asterisk-config.htm">
http://www.routers.com/asteriskprob/asterisk-config.htm</a><br>>>>for a very detailed analysis of the problem.<br>>>><br>>>>I believe one of the more serious issues amounts to: if asterisk is<br>
>>>located a fair distance from the central office (-7db in my case),<br>>><br>>>setting<br>>><br>>>>the rxgain and/or txgain to any level that would be considered<br>>><br>>>reasonable
<br>>><br>>>>for that loss (eg, rxgain=5, txgain=5), hugh amounts of echo result that<br>>>>cannot be addressed through zapata.conf echo entris, and changing<br>>>>compile options to agressive, etc, does not help. Its my believe
<br>>>>(from working with several TDM users), the further one is from the CO,<br>>>>the bigger the problem. (Or, short pstn cable lengths less then about<br>>>>4 or 5db can almost always be addressed via parameters.)
<br>>>><br>>>>The above workaround is very usable (assuming it works) when someone<br>>>>calls in via the pstn and leaves a voicemail (which is already at<br>>>>least 7db down plus their own pstn loss), and then I call in via the
<br>>>>pstn to retrive the voicemail (now 14db down PLUS the original callers<br>>>>pstn loss), the audio is so faint its difficult to impossible to<br>>>>listen to.<br>>>><br>>>>
<br>>>>>>In my case, the asterisk box is located about 7db from the central<br>>>>>>office. As noted in bug 2023 (and 2022), calls from an outside pstn<br>>>>>>line coming into asterisk incure a 7db pstn loss (which can't be
<br>>><br>>>adjusted<br>>><br>>>>>>for with rxgain and txgain as changing those values to something<br>>>>>>reasonable generates echo). Retrieving that VM message from an<br>
>><br>>>outside<br>>><br>>>>>>location creates another 7db loss (now -14db down in total), making<br>>><br>>>it<br>>><br>>>>>>very difficult (if not impossible) to hear the message. (And, yes
<br>>><br>>>I've<br>>><br>>>>>>gone through all the recommendations with wav vs gsm files, etc.)<br>>>>><br>>>>>I am not sure I understand why the txgain/rxgain isn't fixing it
<br>>><br>>>without<br>>><br>>>>>adding unacceptable echo... this all seems very odd... I mean for a<br>>><br>>>test<br>>><br>>>>>you should be able to dial an echo() application and have extremely
<br>>><br>>>quiet<br>>><br>>>>>echoed audio... is this the case?<br>>>><br>>>>As an ex-telco transmission engineer, believe me I've done my homework<br>>>>and some very solid testing with expensive well-calibrated test
<br>>><br>>>equipment.<br>>><br>>>>As I've mentioned to Kevin, its almost like the TigerJet pci controller<br>>>>on the TDM card is reversing bits six and seven (or something very odd<br>
>>>like that). Digium apparently now has a pci engineering type looking<br>>>>at the issues, which I'm told is using a pci logic analyzer, etc.<br>>>><br>>>><br>>>>>>The work around "only" kicks in if the call comes from a zap channel
<br>>>>>>and ends up in voicemail, adding a 6db gain to that recorded<br>>><br>>>message.<br>>><br>>>>>>No other channel types are impacted by this new parameter.<br>>>>>
<br>>>>>This is a HELL of a band-aid.<br>>>><br>>>>If you actually follow the logic that was originally stated in 2023,<br>>>>this gain setting "is" highly useful for those systems that are
<br>>>>further away from the CO (as mentioned above). For those closer to<br>>>>the CO, it has zero value.<br>>>><br>>>>Rich<br>>>><br>>>>_______________________________________________
<br>>>>--Bandwidth and Colocation sponsored by <a href="http://Easynews.com">Easynews.com</a><<a href="http://Easynews.com">http://Easynews.com</a>>--<br>>>><br>>>>Asterisk-Users mailing list
<br>>>><a href="mailto:Asterisk-Users@lists.digium.com">Asterisk-Users@lists.digium.com</a><br>>>><a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users
</a><br>>>>To UNSUBSCRIBE or update options visit:<br>>>><a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>>><br>>>---------------End of Original Message-----------------
<br>>><br>>><br>>><br>><br>><br>><br>> ------------------------------------------------------------------------<br>><br>> _______________________________________________<br>> --Bandwidth and Colocation sponsored by
<a href="http://Easynews.com">Easynews.com</a> --<br>><br>> Asterisk-Users mailing list<br>> <a href="mailto:Asterisk-Users@lists.digium.com">Asterisk-Users@lists.digium.com</a><br>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">
http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>> To UNSUBSCRIBE or update options visit:<br>> <a href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users
</a><br><br></blockquote></div><br>