Hmmm...<br>
<br>
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?)<br>
<br>
<br>
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.<br>
<br>
With 1.2-beta, ChanIsAvail works for me. With CVS-HEAD, it hangs up on the 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 not hangup Zap/3-1 at this point.<br>
<br>
<br><br><div><span class="gmail_quote">On 9/24/05, <b class="gmail_sendername">Rich Adamson</b> <<a href="mailto:radamson@routers.com">radamson@routers.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;">
The patch is in cvs-head, which has been very stable for me. :)<br><br>------------------------<br><br>> Hi Richard,<br>> I am experiencing the same problem. I'd like to test your patch. Thing, 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 type 'show application<br>voicemail', it does not describe the<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 from in incoming POTS<br>connection. When I enter<br>> voicemail by direct dialing a local extension and leave a message from the advanced options
<br>menu, the recorded message is much<br>> louder.<br>><br>> I should qualify, not only are my VMs coming in over POTS, I am actually calling out first<br>through the TDM22B, to Sipura, to<br>> VOIP provider, back in via PSTN, to TDM22B, to VM. I'm amazed it works at all :) ... I'm very
<br>impressed by Asterisk and<br>> especially it's voicemail. I would like to resolve the low volume issue though.<br>><br>> If you can tell me which CVS to check out, I can try it. I'd like to stick to the 1.2-beta
<br>branch though because I don't want to<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>> > On Monday 19 September 2005 12:38, Rich Adamson wrote:
<br>> > > The g(6) adds a 6 db gain for zap calls that end up recording a Voicemail<br>> > > message.<br>> > ...<br>> ><br>> > > * 'g(#)' the specified amount of gain will be requested during message
<br>>
>
> recording
(units are whole-number decibels (dB))<br>> ><br>> > How in the hell does that make any sense? are your normal incoming calls<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), setting<br>> the rxgain and/or txgain to any level that would be considered reasonable<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>> > > 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 adjusted<br>> > > for with rxgain and txgain as changing those values to something<br>> > > reasonable generates echo). Retrieving that VM message from an outside
<br>> > > location creates another 7db loss (now -14db down in total), making it<br>> > > very difficult (if not impossible) to hear the message. (And, yes I've<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 without<br>> > adding unacceptable echo... this all seems very odd... I mean for a test<br>> > you should be able to dial an echo() application and have extremely quiet
<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 equipment.
<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>> > > 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 message.
<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> --<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>---------------End of Original Message-----------------
<br><br><br></blockquote></div><br>