I see three parts to this if I was doing it.
1) set up an extension that, when dialed, requests a huge pin number.
upon successfull pin number entry, it 'touch'es a file on the server to
update its modification time
[internal]
; 9999 could be extension to update heartbeat, asks for pin next
exten => 9999,1,WaitExten(60)
exten => 9999,2,Hangup
exten => 12345679,1,System(touch /etc/such_and_such)
exten => 12345679,2,Hangup
2) a cron entry that checks the modification time on that file every 10
minutes or so and sends an email if the modification time is more than
30 or so minutes old. You could use the 'find' command to find files
matching that name and the criteria of less than 30 minutes age. If a
file matching this criteria isn't found (it's there but too old),
generate the email you desire.
3) a call file every 29 minutes that dials out and back into the above
extension you created. could be as simple as using 'w' in the dial
string to dial the pin at the right time. Notice I put WaitExten(60) up
there, that should accommodate just about anything :)
Dial(ZAP/g1/18005551212wwwwww9999w12345679
The reason I put both 9999 AND 12345679 as extensions in the same
context might seem redundant, as you could simply dial 12345679 from the
main menu, but you don't necessarily want callers to the IVR to have a
60-second pause before repeating the IVR for example, so pressing 9999
would extend the wait to 60 seconds... If your main IVR uses
Background() application solely, though, and lasts for a while, you
might just skip the 9999 part.
Anyway, just an idea. Let me know if I can clarify.. :)
Moj
P.S. Just thought of a cleaner way, skipping the filesystem overhead.
Every time the pin number extension is dialed, set an asterisk db entry
that contains the current second in the epoch. then, regularly use cron
to check the stored astdb epoch value and compare it to the current one.
Might be cleaner, and we've got that new STRFTIME() or whatever-it-is
to help us (memory failing now)
Moj some more
Dave Bour wrote:> I've had slew of problems with my Bell Canada Single Number Reach (SNR)
> dropping in the past couple of months. Another outage Monday for
> several hours has me wondering if there's a way to
>
> 1. Make a call out of my system via a PSTN back to my SNR line, say
> every 30 minutes (this I'm sure is easy enough via the call
> file...however...)
> 2. Track the outgoing call and match to an incoming call...if there's
no
> incoming call...it means my Bell circuit or VoIP provider or ....
> something is down...send me an email that the service is down such that
> I can reroute my SNR to cellular.
>
> The whole point of this SNR was to give me mobility...though that came
> at a cost...Add the Voip off Asterisk and it's a near perfect solution
> except when this fails.
>
> From a network perspective, I've got dual hosted solution now to
> resolve network outages and recent tests have shown that works well,
> albeit the switch takes about 20 minutes to propagate the dns updates
> but otherwise flawless.
>
> It's embarrassing and I'm losing credibility when clients are
asking if
> I'm still in business as the phone has dropped way to often in the past
> few month. Interesting enough all outages to date have been Fridays or
> Mondays.
>
> Does anyone else do anything like this. Anyone else using the Bell SNR
> service? Suggestions welcome.
>
> Thanks in advance
> Dave Bour
> Desktop Solution Center
> 905.381.0077
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
> http://lists.digium.com/mailman/listinfo/asterisk-users