SAIL Community Supported PBX

I suspect there's a bug in the Polycom provisioning provisioning code. I don't know php so can't identify the specific error.

The Polycom templates are all there.
Distro: debian
Sail Release: 4.1.0-12
HPE Release: 4.0.0-37
Server IP = 192.168.1.30
Polycom VVX mac = 0004f2afe689
Polycom Version = 4.0.10

This is the output I get:

http://192.168.1.30/provisioning/0004f2afe689.cfg

<?xml version="1.0" standalone="yes"?>
<!-- $RCSfile$  $Revision: 155256 $ -->
<APPLICATION APP_FILE_PATH="sip.ld"
CONFIG_FILES="[MACADDRESS]-polycom-locals.cfg, [MACADDRESS]-polycom-phone1.cfg" />
<!--MISC_FILES=""  LOG_FILE_DIRECTORY=""  OVERRIDES_DIRECTORY=""  CONTACTS_DIRECTORY=""  LICENSE_DIRECTORY="" 

USER_PROFILES_DIRECTORY=""  CALL_LISTS_DIRECTORY=""  COREFILE_DIRECTORY=""-->


http://192.168.1.30/provisioning/0004f2afe689-polycom-locals.cfg

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Our local phone system common configuration in this file -->
<localcfg>
<server voIpProt.server.1.address="192.168.1.30"/>
<SIP>
   <outboundProxy voIpProt.SIP.outboundProxy.address="192.168.1.30"/>
</SIP>
<TCP_IP>
   <SNTP tcpIpApp.sntp.resyncPeriod="86400" tcpIpApp.sntp.address="192.168.1.30" tcpIpApp.sntp.address.overrideDHCP="0"

tcpIpApp.sntp.gmtOffset="0" tcpIpApp.sntp.gmtOffset.overrideDHCP="0" tcpIpApp.sntp.daylightSavings.enable="1" />
</TCP_IP>
<call>
         <call.directedCallPickupMethod="legacy" call.directedCallPickupString="*8" />
         <missedCallTracking call.missedCallTracking.1.enabled="1"
          call.missedCallTracking.2.enabled="0" call.missedCallTracking.3.enabled="0"
          call.missedCallTracking.4.enabled="0" call.missedCallTracking.5.enabled="0"
          call.missedCallTracking.6.enabled="0"/>
</call>
<!-- Registration info -->
<attendant
          attendant.uri=""
          attendant.reg="1"
          attendant.behaviors.display.spontaneousCallAppearances.normal="1"
          attendant.behaviors.display.spontaneousCallAppearances.automata="1"
          attendant.behaviors.display.remoteCallerID.normal="1"
          attendant.behaviors.display.remoteCallerID.automata="1"
/>
</localcfg>


http://192.168.1.30/provisioning/0004f2afe689-polycom-phone1.cfg
Not Found (404)

Whatever section of code is supposed to generate the [MACADDRESS]-polycom-phone1.cfg is failing.

Here are the var/log/messages:

May 18 19:14:40 asterisk apache2: 192.168.1.10 sending config 0004f2afe689-phone.cfg
May 18 19:14:42 asterisk apache2: 192.168.1.10 sending config 0004f2afe689.cfg
May 18 21:05:02 asterisk apache2: 192.168.1.10 sending config 0004f2afe689-polycom-locals.cfg
May 18 21:05:49 asterisk apache2: 192.168.1.10 sending config 0004f2afe689-polycom-locals.cfg
May 18 21:06:18 asterisk apache2: 192.168.1.10 0004f2afe689-polycom-phone1.cfg Sending 404 because creds already sent
May 18 21:10:46 asterisk apache2: 192.168.1.10 0004f2afe689-phone1.cfg provisioning data not found in db.  Sending 404 and giving up
May 18 21:12:26 asterisk apache2: 192.168.1.10 0004f2afe689-polycom-phone.cfg provisioning data not found in db.  Sending 404 and giving up
May 18 22:17:11 asterisk apache2: 192.168.1.10 0004f2afe689-polycom-phone1.cfg Sending 404 because creds already sent
May 18 22:19:03 asterisk apache2: 192.168.1.10 0004f2afe689-polycom-phone1.cfg Sending 404 because creds already sent


Thanks,  that's enough info to start troubleshooting.

I will probably have to add specific phone model folders under the polycom directory, customize the rewrite rules and device.php code to accomodate the different polycom phones. Polycom file names are identical between versions and phones but are not compatible with each other. 

I will post the mods once I have them working.

I never had issues with the older sail versions using legacy polycom phones. I just upgraded to 4.1 on debian and I have not been able to get either older IP550(ver3_3_5) or newer VVX 500(ver4_1_8) to receive the provisioning files from the http /provisioning directory.  I manually upgraded both models to the recommended software using the http://voipt2.polycom.com website.

Where are the specific [MACADDRESS].cfg, [MACADDRESS]-polycom-phone1.cfg , [MACADDRESS]-polycom-locals.cfg files being placed? They are not in the /public/polycom folder and I can't see them in the sark.db sqlite3 database.

This is what /var/log/messages puts out on a provisioning attempt:

May  8 23:21:52 asterisk apache2: 192.168.1.55 0004f2afe689-calls.xml provisioning data not found in db.  Sending 404 and giving up
May  8 23:21:52 asterisk apache2: 192.168.1.55 sending config 0004f2afe689-directory.xml
May  8 23:21:52 asterisk apache2: 192.168.1.55 0004f2afe689-calls.xml provisioning data not found in db.  Sending 404 and giving up
May  8 23:21:52 asterisk apache2: 192.168.1.55 sending config 0004f2afe689-directory.xml
May  8 23:21:53 asterisk apache2: 192.168.1.55 sending config 0004f2afe689.cfg
May  8 23:21:53 asterisk apache2: 192.168.1.55 sending config 0004f2afe689-phone.cfg
May  8 23:21:53 asterisk apache2: 192.168.1.55 0004f2afe689-web.cfg provisioning data not found in db.  Sending 404 and giving up
May  8 23:21:53 asterisk apache2: 192.168.1.55 000000000000-license.cfg not found in db(RowCount).  Sending 404 and giving up
May  8 23:21:53 asterisk apache2: 192.168.1.55 0004f2afe689-license.cfg provisioning data not found in db.  Sending 404 and giving up
May  8 23:21:53 asterisk apache2: 192.168.1.55 Ignoring PUT request - Sending 200 and giving up
May  8 23:21:55 asterisk apache2: 192.168.1.55 Ignoring PUT request - Sending 200 and giving up


The polycom logs are long and not very descriptive, This is a sample of Minor Errors:

000036.338|clist|4|00|dbSet::startLoadLocalSet:No local copy, requesting backup from server
000036.484|clist|4|00|dbIO::processResult:copy error
000036.484|clist|4|00|dbSet::srv2mem:transfer failed
000036.593|clist|4|00|dbSet::startLoadLocalSet:No local copy, requesting backup from server
000036.593|clist|4|00|dbSet::load:cleared load error state m_sync=<0x40>
000036.629|clist|4|00|dbIO::processResult:copy error
000036.629|clist|4|00|dbSet::srv2mem:transfer failed


If I look at the Polycoms through their direct web interface they are all at default settings after booting up so the cfg files are invalid or not being accepted. Additionally each Polycom model family have different cfg formats but require identical file names so there would have to be distinctive folders under the public share to accomodate this. Looking at your sark.conf and device.php it that you are just pushing them out which means a wireshark packet trace is the only way to see what is being transmitted.

Do you have documentation posted on how the .cfg files are built?

Are there any specific references are you looking for? There are forum posts all over google about images not being displayed properly in Apache that are not SARK/SAIL specific. Some are permissions related but a large percentage of them have solved the problems with the "EnableSendFile OFF" and/or "EnableMMAP OFF" directives. I just needed the EnableSendFile directive.

According to the Apache Core Documentation:  http://httpd.apache.org/docs/2.2/mod/core.html#EnableSendfile this has to do with the build system not detecting the platform's SendFile support properly. This installation was on a Jetway NF96FL-525-LF Appliance so may not apply to other hardware.

I can tell you that it's an odd problem to troubleshoot. After multiple scratch re-installs I finally uploaded some test images to the /opt/sark/www/sark-common/ folder, see it they displayed in the web page - they didn't,  then downloaded them back again. A binary inspection of the received file showed that it was no longer an image file but a string of error messages truncated at the original file length. Since you never know what hardware SARK/SAIL is being installed on it would save some people a lot of time by noting it in the wiki even though it is not a SARK/SAIL specific issue.

I recently installed Debian/Sail using the wiki guide. After the install I noticed the Sail web pages would not display images but functioned correctly. I tried several different installations methods from scratch using Sail 4.0, 4.0.1, and 4.1.0-7 and none of these versions corrected the issue. Other web pages on the server, like Webmin, displayed properly. After some research I found there's an Apache2 issue over the way some sites are structured.

This turned out to be the fix:
echo EnableSendfile off   >>  /etc/apache2/apache2.conf

These are the platform specifics
Linux asterisk 3.2.0-4-686-pae #1 SMP Debian 3.2.68-1+deb7u3 i686 GNU/Linux
asterisk 1:1.8.13.1~dfsg1-3+deb7u3   i386   Open Source Private Branch Exchange (PBX)
sail 4.1.0-7   all   SARK  Asterisk Integration Layer (SAIL) - A fast, lightweight switch for Asterisk
apache2 2.2.22-13+deb7u6   i386   Apache HTTP Server metapackage

You might want to note it in the wiki.