Simple Hotel Style Wake-Up Calls – THE MODULE

[tshif]

How about:
On some Red Hat and similar systems, the time zone is also stored in "/etc/sysconfig/clock". Edit this file and set the correct time zone.

Im sure it's related to php. The code that works with times and dates is in the wakeconfirm.php and possibly wakeupphp files, which are installed with the module from the modules agi-bin folder. When you look at the code - there not much sophistication with how it deals with time. It perrty much just expects PHP to handle it.

Please let us know if you find anything more out about this -

 

[unsichtbarre]

I'll work it till it works!

No /etc/sysconfig folder on Ubuntu. Time is in /etc/timezone.
I created the file date.php with the following contents:

<?php
echo date('l jS \of F Y h:i:s A');
?>

and it echos the correct time/date, now I am relly puzzeled?

-J

 

[tshif]

No /etc/sysconfig folder on Ubuntu. Time is in /etc/timezone.
I created the file date.php with the following contents:

<?php
echo date('l jS \of F Y h:i:s A');
?>

and it echos the correct time/date, now I am relly puzzeled?

-J

You and me both.

 

[bobvr]

Yes, furthermore when I dial for the time I get the correct time. I have checked into the following article:

freepbx.org/forum/freepbx/tips-and-tricks/incorrect-server-time-on-the-time-conditions-page

and while my PHP date.timezone = was not set, I set it to date.timezone = America/Phoenix and restarted the server. My closest guess is that wake up calls are happening in Mountain Daylight Time, while Arizona continues to use Mountain Standard Time all year.

-J

Did you backspace out the semi colon on the date.time line in php.ini? Then restart?

Does the server time on the time groups page in FreePbx show correct?

 

[unsichtbarre]

Yes and Yes!

Server time shows correct in Time groups and here's the line from php.ini:

; Defines the default timezone used by the date functions
date.timezone = "America/Phoenix"

 

[bobvr]

The only other thing I can think of to check is by going in to webmin and checking that the time is correct under Hardware, System Time and the Change timezone tab.

Note, I am in AZ also and the only problem I have ever had with time was the php setting which is now "corrected" thanks to the link we both used.

The wake up calls for me always worked correctly with the old one I used, (posted a few replies up) and the new module version here worked correctly also. - Even though I "modified" the module install a little to use the Perl script I was used too again.

 

[Bitnetix]

ARG! My time doesn't work

Love the idea, hate the results. I'm finding that no matter what I do as far as entering times, the call comes in before Alison even stops talking during the setup process.

So if I type "0630" for 6:30 and hit 1 for am or 2 for pm, even if it's noon, the wake up call comes in as Alison is telling me that the call has been scheduled.

My system time is right. I installed the module according to the instructions, and I haven't seen anyone else complain about this, so I have to assume it's just me.

Any words of advice? I suppose it's possible that it's a protection issue, but the I ran amportal chown and that should take care of that, right?

PIAF 1.2 upgraded to 1.4 via update-scripts/update-fixes/update-sources/update-fixes.

 

[tshif]

Bitnetix - I haven't heard this failure before - so we may have to do some investigating.

The system works by placing call files in the outbound spool folder. See if you can grab one of these files and lets get its name and contents to look at.

 

[Bitnetix]

Will get a file when I'm on a computing platform a little easier to navigate with than my blackberry.

Thanks.

Bitnetix - I haven't heard this failure before - so we may have to do some investigating.

The system works by placing call files in the outbound spool folder. See if you can grab one of these files and lets get its name and contents to look at.

 

[Bitnetix]

My outbound call file

Phone numbers are changed to protect the innocent.

In /var/spool/asterisk/outgoing, we have this file:
$ ls -l
4 -rw------- 1 asterisk asterisk 183 May 28 2009 1830.ext.5852593742.call

Which contains this:
$ cat 1830.ext.1234567890.call
channel: Local/1234567890@from-internal
maxretries: 3
retrytime: 60
waittime: 20
callerid: Wake Up Calls <*68>
application: AGI
data: wakeconfirm.php

StartRetry: 2955 1 (1243515506)


I did this about five minutes ago. Before hanging up, my phone was ringing with the wakeup call.

In /tmp, we have wakeup.log that contains this:

$ cat wakeup.log
---Start---
agi_request: wakeconfirm.php
agi_channel: Local/1234567890@from-internal-ce80,1
agi_language: en
agi_type: Local
agi_uniqueid: 1243515446.104
agi_callerid: *68
agi_calleridname: Wake Up Calls
agi_callingpres: 0
agi_callingani2: 0
agi_callington: 0
agi_callingtns: 0
agi_dnid: unknown
agi_rdnis: unknown
agi_context: from-internal
agi_extension: 1234567890
agi_priority: 1
agi_enhanced: 0.0
agi_accountcode:

ANSWER
200 result=0
STREAM FILE hello ""
200 result=0 endpos=0
STREAM FILE this-is-yr-wakeup-call "1234"
200 result=0 endpos=14720
STREAM FILE to-cancel-wakeup "1234"
200 result=0 endpos=15360
STREAM FILE press-1 "1234"
200 result=0 endpos=7360
STREAM FILE to-snooze-for "1234"
200 result=49 endpos=6240
EXEC background "wakeup-call-cancelled"
200 result=0
HANGUP
200 result=1


Any words of wisdom?

 

[Bitnetix]

More info from the debug file

I didn't realize that the debug file wasn't complete or being overwritten by the calling out process. Not sure which, and didn't spend time trying to figure it out. I just forced debug mode on and spewed stuff to the screen. Here's proof that the script is properly creating the times, and that it knows our current time:

(Note: This is just a snippet, but it's the important parts.)

Checking Results [1100]
GET DATA 1-for-am-2-for-pm 15000 1
READ=200 result=1
1=1, 2=, 3=, 4=
Wakeup File [/tmp/1100.ext.1234567890.call]
time_wakeup=Thursday 28th of May 2009 11:00:00 AM (1243522800) | time_now=Thursday 28th of May 2009 09:15:57 AM (1243516557)
Setting WAKEUP file to =Thursday 28th of May 2009 11:00:00 AM - 1243522800
STREAM FILE for ""
READ=200 result=0 endpos=4160
1=0, 2= endpos=4160, 3=, 4=
STREAM FILE extension ""
READ=200 result=0 endpos=7360
1=0, 2= endpos=7360, 3=, 4=
SAY DIGITS 1234567890 ""
READ=200 result=0
1=0, 2=, 3=, 4=
Wakeup time is set to 1100
STREAM FILE rqsted-wakeup-for ""
READ=200 result=0 endpos=20800
1=0, 2= endpos=20800, 3=, 4=
SAY NUMBER 11 ""

There. I'm done adding logs.

 

[tshif]

Great info - thanks for getting it together for us to look at.

Sadly - I don't see anything out of character at all. I had hoped that the contents of the call files would be the problem - since they drive the entire process. But the contents of yours looks just perfect.

I know that in cases like the Voice Reminder System (Nerd Vittles) - if you create a reminder for the past - it sends it out the moment its created.

But my experience with the Wake Up calls is that if you create one for a time of day that is already past - it just waits for the next day to deliver it - rather than send it out immediately.

Do you currently have any other program or process running on your PBX that uses call files? It would be valuable to see if all call files are failing to work as expected, or if its only the Wake Up Calls call files that are not working right.

Hmmmm. Still thinking about it - but I "got nothing" else coming to mind right now.
-tshif

 

[Bitnetix]

I'm using the Nerd Vittles reminders without problem. I'll investigate further with some custom debug php code. Thanks.

 

[tshif]

I'm using the Nerd Vittles reminders without problem. I'll investigate further with some custom debug php code. Thanks.

Excellent. This one will be very interesting to see resolved.

 

[Bitnetix]

Solved. Potential change to module as permanent fix.

I'll lead you down the path towards solution. This is for everyone's benefit, not just Tony's, so please forgive me if I get overly complicated.


/var/spool/asterisk/outgoing normally has call files in it. Asterisk reads this directory and processes any files that have modification times that are not in the future.

The wakeupphp script creates a temporary call file and changes the modification time to the wakeup time via the PHP touch command. It then issues a move to move the file into the outgoing call directory. Unix moves move information about the file, but not the actual content, if the files are on the same filesystem (or mount point). This makes it fast and easy and convenient, since it doesn't have to copy and delete (which is what it has to do if they're on different mount points).

In wake.inc, the
temp dir is $param_temp_dir="/tmp";
call dir is $param_call_dir="/var/spool/asterisk/outgoing";

In our case, /tmp and /var are two separate filesystems. /tmp is on /, and /var is on its own mount point. That's because we've been using unix since the 80s and don't like having one filesystem. We like /, /usr, and /var, and that means /tmp and /var/anything are not sharing inodes.

So the move becomes a copy, and now it's a new file with NOW as its timestamp, and Asterisk promptly processes it.

Changing $param_temp_dir to /var/spool/asterisk/tmp fixes this problem and should probably be a permanent fix to wake.inc, since unless someone is really doing weird things, this is guaranteed to be on the same filesystem as /var/spool/asterisk/outgoing and will prevent this problem for occuring for anyone else.

 

[tshif]

Bitnetix - Nice!

Eric - this is a great contribution you have made - thank you for sharing the solution and reasons behind it. I just looked at the code - and I see no reason not to make the changes you have suggested.

I promise you it would have taken me a LOT longer to find the nature of the problem!

Ill open a bug ticket, and include your solution.

Tony

 

[tshif]

I'm pleased to inform you that not only has Bitnetix found and provided a fix for this bug - he's just signed up at the Software Development Project site as our newest developer and will be jumping in and fixing this (I think) as his first contribution.

Please join me in welcoming Bitnetix to Ward, Tom and Joe's wonderful community here, and the Dev Project site.

 

[Bitnetix]

Stop. I'm just trying to make MY life easier.

I'm pleased to inform you that not only has Bitnetix found and provided a fix for this bug - he's just signed up at the Software Development Project site as our newest developer and will be jumping in and fixing this (I think) as his first contribution.

Please join me in welcoming Bitnetix to Ward, Tom and Joe's wonderful community here, and the Dev Project site.

 

[tshif]

Hotel Style Wakeup Calls Module Maintenance Release 1.2.1

Hotel Style Wakeup Calls Module Maintenance Release 1.2.1

The Hotel Style Wakeup Calls module has been updated.

This is a maintenance release. Upgrading is recommended, but not required. Please get the upgrade here.

This maintenance release has one change:

1. Wakeup Calls sent the very same second they are created regardless of specified time.
(Fixed by Bitnetix)

This module upgrade has been regression tested against and been verified to be compatible with the security models used in the following distributions:

Fonicatec PABX
Foncordiax
PBX In A Flash
TrixBOX CE

Asterisk Version Compatibility
This module has been tested and found to work correctly with Asterisk versions 1.4 and 1.6.

 

[tshif]

Hotel Style Wakeup Calls Module Maintenance Release 1.2.2

Hotel Style Wakeup Calls Module Maintenance Release 1.2.2

The Hotel Style Wakeup Calls module has been updated.

This is a maintenance release. Upgrading is strongly suggested for all platforms. Please get the upgrade here.

This maintenance release has one change:

1. Module Version Ver 1.2.1 not installing
(Bug ticket posted by HAT. Thanks Tom.)

This module upgrade has been tested against and been verified to be functional, and compatible with the security models used in the following distributions:

Fonicatec PABX
Foncordiax
PBX In A Flash
TrixBOX CE

Asterisk Version Compatibility
This module has been tested and found to work correctly with Asterisk versions 1.4 and 1.6.