Aastra XML scripts 2.3.0 Beta

[edisoninfo]

Thanks aastra1 ! Sorry for the noise. I guess I "assumed" incorrectly since the vars in amportal.conf where there and set by default, that the function was there also. I am compiling 1.4.33.1 now 'with' the func_devstate.c in place!

OK. compile and install complete.

core show function DEVSTATE fails
core show function DEVICE_STATE shows the function properly

Beta5 xml scripts, the DND key does indeed toggle the flags in the "database show" command, but does NOT update the phone display and lights properly. I rebooted the box and same results.


The core show hints command still shows unavailable for each as well as the CF and FM hints.


Is there maybe some confusion between asterisk version 1.4.x and 1.6.x and the DEVSTATE vs DEVICE_STATE functions? I ask this because the 'full' log still shows the error 'function DEVSTATE' not registered.

Also I had to manually issue 'module load func_devstate.so' for some reason after a reboot it did not load on it's own.

 

[Socs28]

Ok, so I forgot I had disabled the feature code in FreePBX which takes that hint out. I have reenabled that, I still have to test the buttons as it is a remote location. Is there a way to disable the feature code and still have this work correctly?

 

[aastra1]

Re: Socs28

Ok, so I forgot I had disabled the feature code in FreePBX which takes that hint out. I have reenabled that, I still have to test the buttons as it is a remote location. Is there a way to disable the feature code and still have this work correctly?

Hi there,

Thanks to your post we just realized that the DND sync mechanism only works when the feature codes are enabled in freePBX as this is the place where the hints are created.

So it should work correctly for you but (right now in Beta5) now way to have them disable, is that an issue for you?

Regards

aastra1

 

[Socs28]

It should be fine with them enabled, just trying to simplify as much as possible and leave as much room for extensions with good dial plans as possible. If in the future there is a way to have it disabled, that would be good.

 

[aastra1]

Re: edisoninfo

OK. compile and install complete.

core show function DEVSTATE fails
core show function DEVICE_STATE shows the function properly

Beta5 xml scripts, the DND key does indeed toggle the flags in the "database show" command, but does NOT update the phone display and lights properly. I rebooted the box and same results.

The core show hints command still shows unavailable for each as well as the CF and FM hints.

Thanks to Socs28 post, we know know that the sync mechanism based on hints works only if the feature codes relative to the function are enabled in freePBX, can you please make sure that *76, *78 and *79 are enabled?

Is there maybe some confusion between asterisk version 1.4.x and 1.6.x and the DEVSTATE vs DEVICE_STATE functions? I ask this because the 'full' log still shows the error 'function DEVSTATE' not registered.

We have done our best to send the right command for the right version in the code but we may have miss one. We will double check.

Also I had to manually issue 'module load func_devstate.so' for some reason after a reboot it did not load on it's own.

Maybe you can check /etc/asterisk/modules.conf.

aastra1

 

[edisoninfo]

Thanks to Socs28 post, we know know that the sync mechanism based on hints works only if the feature codes relative to the function are enabled in freePBX, can you please make sure that *76, *78 and *79 are enabled?

Yes, they are all enabled

We have done our best to send the right command for the right version in the code but we may have miss one. We will double check.

Most of the documentation seems to point to DEVSTATE for Asterisk 1.4.x and DEVICE_STATE for 1.6.x but for some reason, the func_devstate.c file I downloaded this morning created the DEVICE_STATE command in my 1.4.33.1 version instead of DEVSTATE.

Maybe you can check /etc/asterisk/modules.conf.

aastra1

You are correct. It was not in the modules.conf file, I had to add it manually.

 

[Socs28]

I've noticed on the check_install script, if you have g722 congigured via the new sip configuration module in FreePBX, which edits the sip_general_additional.conf file, it is not detected and the script tells you to add it in the sip_general_custom.conf file.

 

[aastra1]

Re: Socs28

What would it take to get the Parking script to subscribe to specific parking lots? I am installing for my local city government and the departments don't want to see eachother's parked calls.

Some work , I don't believe tis would be too difficult to implement but would require some configuration as we cannot guess who is in which department. Unfortunately too much work for 2.3.0.

Asking the question to everybody, is that a critical feature you would like to see implemented?

Regards

aastra1

 

[aastra1]

Re:Socs28

It should be fine with them enabled, just trying to simplify as much as possible and leave as much room for extensions with good dial plans as possible. If in the future there is a way to have it disabled, that would be good.

We modified the code to have an hybrid solution will be part of beta6.

aastra1

 

[totalimpact]

Sorry, guess I should have paid more attention to the devstate setting, but I believe it is not compiled by default on 1.4 systems (unless you are using one of the asterisk rpm distros).

At any rate, with devstate fully compiled and enabled on my 1.4.33 system many buttons do not work, but turning off devstate in amportal.conf is just like you said, most everything works instantly.

I can go live with no devstate on beta5 with all feature keys working.

Thanks for all your awsome work, and listening to all our wining about bs because we didnt rtfm.

It would however be extremely nice to be able to add a key using the webui - is that a remote possibility in the future roadmap?

 

[edisoninfo]

Ok, a bit of a recap....

I have:
compiled asterisk 1.4.33.1 with the func_devstate.c file included
verified the new version is installed and running
installed aastra-iphone-2.6.0-1 rpm
installed aastra-xml-scripts Beta5
verified USEDEVSTATE=true is in amportal.conf
amportal restart
restarted both aastra-daemons
rebooted the 57i phones
core show function DEVSTATE fails
core show function DEVICE_STATE works
core show hints has lines for each exten like this:

20@ext-local           : SIP/20&Custom:DND20   State:Idle            Watchers  0

*7620@ext-dnd-hints       : Custom:DEVDND20       State:Unavailable     Watchers  0

pressed the DND button on the 57i phone
database show now has the DND/20 in it
phone display did not change
pressed the DND button again
database show does NOT have the DND/20 in it
phone display again did not change

checked the /var/log/asterisk/full log file and found the "ERROR[9927] pbx.c: Function DEVSTATE not registered" error message each time the DND button was pressed on the 57i phone.

Hope this helps a little. I am glad to do any and all testing you need to help track this down.

 

[aastra1]

Re: edisoninfo

Ok, a bit of a recap....

I have:
compiled asterisk 1.4.33.1 with the func_devstate.c file included
verified the new version is installed and running
installed aastra-iphone-2.6.0-1 rpm
installed aastra-xml-scripts Beta5
verified USEDEVSTATE=true is in amportal.conf
amportal restart
restarted both aastra-daemons
rebooted the 57i phones
core show function DEVSTATE fails
core show function DEVICE_STATE works
core show hints has lines for each exten like this:
[/code]
pressed the DND button on the 57i phone
database show now has the DND/20 in it
phone display did not change
pressed the DND button again
database show does NOT have the DND/20 in it
phone display again did not change

checked the /var/log/asterisk/full log file and found the "ERROR[9927] pbx.c: Function DEVSTATE not registered" error message each time the DND button was pressed on the 57i phone.

Hope this helps a little. I am glad to do any and all testing you need to help track this down.

Hello edisoninfo,

That definitely helps. The scripts are using:

• core set global DEVSTATE with Asterisk 1.4
• devstate change with Asterisk 1.6

We did that because all the backport of DEVSTATE we have seen in 1.4 was using DEVSTATE not DEVICE_STATE like it does in 1.6.

Can you test this?

In /var/www/html/aastra/include/AastraAsterisk.php around line 4032 (function Aastra_se_devstate_Asterisk)
Replace

[FONT=Courier New]if($AA_ASTERISK_VERSION=='1.6') $res=$as->Command('devstate change '.$device.' '.$state);[/FONT]
[FONT=Courier New]else $res = $as->Command('core set global DEVSTATE('.$device.') '.$state);[/FONT]

by

[FONT=Courier New]if($AA_ASTERISK_VERSION=='1.6') $res=$as->Command('devstate change '.$device.' '.$state);[/FONT]
[FONT=Courier New]else[/FONT]
[FONT=Courier New]{[/FONT]
[FONT=Courier New]$res = $as->Command('core set global DEVSTATE('.$device.') '.$state);[/FONT]
[FONT=Courier New]$res = $as->Command('core set global DEVICE_STATE('.$device.') '.$state);[/FONT]
[FONT=Courier New][FONT=Courier New]}[/FONT]
[/FONT]

Doing this the scripts are sending the 2 commands as there is no simple way to know which one to use. One of them should work.

Let us know if this works for you.

Regards

aastra1

 

[aastra1]

Re:totalimpact

Sorry, guess I should have paid more attention to the devstate setting, but I believe it is not compiled by default on 1.4 systems (unless you are using one of the asterisk rpm distros).

At any rate, with devstate fully compiled and enabled on my 1.4.33 system many buttons do not work, but turning off devstate in amportal.conf is just like you said, most everything works instantly.

I can go live with no devstate on beta5 with all feature keys working.

Thanks for all your awsome work, and listening to all our wining about bs because we didnt rtfm.

Beta6 will fix all your problems as we believe we identified the source of the problems with Asterisk 1.4 and the DEVSTATE backport.
Stay tuned.

It would however be extremely nice to be able to add a key using the webui - is that a remote possibility in the future roadmap?

That will unfortunately never happens because if the configuration change is done via the the WebUI the XML scripts have no way to retrieve this configuration change so that would create a major inconsistencies. Not doable.

Sorry

aastra1

 

[edisoninfo]

Hello edisoninfo,

That definitely helps. The scripts are using:

• core set global DEVSTATE with Asterisk 1.4
• devstate change with Asterisk 1.6

We did that because all the backport of DEVSTATE we have seen in 1.4 was using DEVSTATE not DEVICE_STATE like it does in 1.6.

Can you test this?

In /var/www/html/aastra/include/AastraAsterisk.php around line 4032 (function Aastra_se_devstate_Asterisk)
Replace

[FONT=Courier New]if($AA_ASTERISK_VERSION=='1.6') $res=$as->Command('devstate change '.$device.' '.$state);[/FONT]
[FONT=Courier New]else $res = $as->Command('core set global DEVSTATE('.$device.') '.$state);[/FONT]

by

[FONT=Courier New]if($AA_ASTERISK_VERSION=='1.6') $res=$as->Command('devstate change '.$device.' '.$state);[/FONT]
[FONT=Courier New]else[/FONT]
[FONT=Courier New]{[/FONT]
[FONT=Courier New]$res = $as->Command('core set global DEVSTATE('.$device.') '.$state);[/FONT]
[FONT=Courier New]$res = $as->Command('core set global DEVICE_STATE('.$device.') '.$state);[/FONT]
[FONT=Courier New][FONT=Courier New]}[/FONT]
[/FONT]

Doing this the scripts are sending the 2 commands as there is no simple way to know which one to use. One of them should work.

Let us know if this works for you.

Regards

aastra1

Yes, this fixed it. I checked the output of check_install and it shows Asterisk 1.4 which is why the scripts broke. For my install I commented out the one command so it does not fill my logs with the function not found error.

I don't know what version of the func_devstate.c file I have. I had to Google quite awhile before I found this copy. Maybe include a copy of a certain version, or at least a link to the version you prefer? The xml documentation so very briefly mentions that you need this function manually added on your own. I missed it when glancing through it the first several times. For such an important piece of the puzzle, this should be IN CAPITAL letters or something! Especially since most of the PiAF forum opinion is to use the Asterisk 1.4.x tree so most everyone is going to have this problem. I have a new install with Asterisk 1.6.x that the DND keys are doing the same thing. Unfortunately this client is a very volatile client so I don't know what "testing" access I am going to get with them. I'll try in the next few days.....

 

[aastra1]

Beta 6 now available

Just to let you know that beta6 is now available, the initial post has been updated with all the details.

Thanks again for your feedback.

Regards

aastra1

 

[aastra1]

New firmware RPM package 2.6.0

We just made available on our HTTP server a new phone firmware RPM package which includes the latest GA firmware loads for the Aastra SIP phones:

• firmare 1.4.3 build 23 for Aastra 9112i, 9133i, 480i, 480iCT
• firmware 2.6.0 build 66 for Aastra 6730i, 6731i, 6751i, 6753i, 6755i, 6757i, 6757iCT, 9143i, 9480i, 9480iCT
• firmware 3.0.1 build 2015 for the Aastra6739i

The various release notes are available on our web site http://www.aastratelecom.com.

Installation
On the console as root

# cd /tmp
# wget http://65.205.71.13/2.3.0/aastra-ipphone-2.6.0-1.noarch.rpm
# rpm -U aastra-ipphone-2.6.0-1.noarch.rpm

This new RPM package is compatible and even recommended for the new version of the XML scripts (2.3.0).

Regards

aastra1

 

[TheShniz]

Using the latest firmware via RPM (just posted), Beta6 XML (just posted), on a fresh load of PiaF (Asterisk 1.4/Zaptel/32bit)... I'm getting "cannot display" whenever the user finishes a call. Pressing the Goodbye key returns the LCD back to normal.

 

[dgruhin]

I am experiencing the same thing "Cannot display"

 

[dgruhin]

I was able to correct the display issue by reapplying the 2.6 firmware rpm and restarting my phones.

 

[colman]

Hi,

Bit of an Aastra XML noob, so apologies if the question is a bit obvious

I am planning to upgrade the XML scripts for a customer in the very near future. I'm comfortable with the process described above, but you don't say what the user will experience on the handset after the process is complete? Will the handset retain the existing login information or will they have to enter their ext & vmail pwd again? I'm presuming that the mac.cfg files will remain and that the phones will log in automatically, but I'd rather know for sure so that when I do the update remotely I can prepare the customer for any required actions on their part.

Thanks for your help,

Colman