John,
The request for this type of indicator was posted some time back here on the 
forums.  It would be used for anyone that has to track several voicemail 
accounts on their system.  In my case, my office phone can see both house and 
office lines.  In several clients, it can be used to track the group support 
voicemail or reception voicemail as well as the person's personal voicemail.  
It simply saves having to log into both accounts to check when the MWI is on.

The script is actually fairly straight forward.  To minimize the configuration 
requirements, it simply scans the existing MAC.cfg and aastra.cfg files, finds 
the keys you've assigned vmail.php, the Aastra visual voicemail buttons, and 
recalls itself with the extensions (needed for the voicemail lookup) and key 
(needed to know what button to light).  The next pass through the file then 
simply reads the number of voicemails and lights the led indicator and changes 
the label to indicate the number of VM at each line where the Visual VM is 
used.  It actually makes two passes per line since the process to light the LED 
and change label are handled by two different functions and they cannot be done 
on the same pass.

To your comment, on a better way to do it...I truly hope so...

I don't think much needs changing in the application itself.  It's simply a 
question of how it triggers.  Ideally, to be able to filter MWI sip notify 
messages would be ideal.  Unfortunately, I only have two viable and one wishful 
thinking option today as I see it:
1. poll regularly as I do today
2. have the pbx issue a empty sip notify whenever a MWI status change occurs 
causing the script to run.  This would be much better than polling but the only 
way I see this happening would be to hack ...oops..I meant patch the voicemail 
application to do such a task
3. have Aastra update the firmware to provide more options for triggering 
scripts that could benefit this.  Today, the ideal as I said would to have 
various filters available and a script run on every type of sip notify which 
could easily solve this.  That said, if not done right, the filter process 
could bury the cpu in the phone...so I could see reluctance on the part of 
Aastra to implement this...not to mention it still requires waiting for a whole 
new firmware which we know won't happen immediately regardless so I'm back to 
options 1 or 2 as I see it.

As it stands now, I've got this running on a couple demo phones and 1 
production phone.  I've seen one lockup at the beginning of the week on one 
demo set.  That said, I can't say it was the script that caused it though.  The 
whole polling and sip notify triggers are new in the 2.2 firmware so there may 
be issues/bugs there too.  I've already seen inconsistency in the sip notify 
script even being set on the phone when it loads the config file.  Haven't 
figured out exactly why but for some reason, it doesn't always get set.  I 
suspect a few bugs are still there but so far, I'm pleased with what I've seen.

As to improvements in the efficiency of the trigger or in the script itself, 
any and all suggestions are greatly welcome.

Dave Bour
Desktop Solution Center
905.381.0077 X501
[EMAIL PROTECTED]

For people who just want IT to work

Business http://www.desktopsolutioncenter.ca
Personal http://www.davebour.com

P.S.  Today, in any multiple set environment where multiple sets can be used to 
configure the various line options, the concept of this autoconfiguring script 
could be used to trigger updates to all of the various indicators like the dnd, 
cfwd, day/night etc since it could read the various settings from the phone's 
config file, poll the system for the status and set indicators accordingly.  
Again, having a trigger to the various phones on any change of the settings 
would be ideal rather than a polling basis.  It makes remote setting of these 
options even more viable now too.  Again, that filtered sip notify function I 
mentioned earlier would be very useful for all this.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to