SAIL Community Supported PBX

We've just completed the certification process for two new phone model ranges.     The new KX-HDV range from Panasonic and the new VSP range from Vtech.  Both ranges can do PnP, zero touch provisioning (ZTP) with SARK and the HDV Panasonics can do on-the-fly function key setting and provisioning.  We've added them to the provisioning section here

http://www.sailpbx.com/mediawiki/index.php/SARK_V4.0.1_Provisioning

There is also a new Discovery and Adoption feature in V5 which is also briefly covered in the wiki. 

If we are talking about the same thing then the latest GA SIP firmware, according to the Polycom matrix is 4.0.10.   Most of the testing we did in 4.1 SARK if I remember correctly used VVX phones on 4.0.4.

The templates can be found in the template tab under end-points in 4.1.   You should have templates for Polycom, polycom-locals.cfg, polycom-phone1.cfg and polycom.Fkey.  4.x uses a new provisioning engine based upon a simple pseudo language to synthesise provisioning streams on-the-fly.   It's easy enough, at least locally, to see what is being sent simply by entering the same URI's the phones send, into your browser.    The provisioning server will send you the stream.    So, for example, in the case of a Polycom,  if you entered

http://ip.,address.of.sark/provisioning/0004f2afe689.cfg

...then it will present you with the same stream it would send to the phone.

The provisioning server recognises only a few Polycom filetypes (as described above).   Anything else a Polycom asks for is automatically redirected to the Polycom public folder via mod_rewrite.   If the file is there, it will be served, if not, it won't.   Polycom, suggest you unzip the entire Polycom firmware pack into the provisioning folder, which in our case is /public/polycom.   We've followed the standard Polycom guidelines in terms of naming conventions, file structure and the bootstrap XML techniques they use.   For avoidance of doubt, we don't supply, ship, touch the base Polycom firmware.   There is nothing in the public/polycom folder put there by us.   It is up to the user to licence, choose, download and unzip the correct firmware into that folder. 

Hope this helps get you on the road.

It has been up on GiT for a long time.  Look for aelintra or SAIL.

There are a few of tools at your disposal for handling these issues.   You'll need to decide which is best for your situation.   You can use either

*Transformation masks
*Custom routes
*Tenant dialplan/area code

Transformation masks you already are familiar with.   Masks are great at pattern match/replace but they have no concept of number length so if that is an issue then you will need to resort to custom route(s), except for one general use case (see below). 

The way SARK/SAIL manages routes is to generate them as a list in the relevant context.   Here is an example


[qrxvtmny]
        include => internal-presets
        include => extensions
        include => utilities
        exten => _XXXXX.,1,agi(sarkhpe,OutRoute,DEFAULT,,)
        exten => _00XXX.,1,agi(sarkhpe,OutRoute,Internat,,)



By creating a custom App we can add our own route dialplans which may be more interesting.  Custom Apps with a span of internal are included into the outbound context so they can operate as routes if you wish.   Let's imagine we want to catch 6 digit numbers beginning with a 3,  prepend a 4 digit prefix of 01484 to them and then recursively hand the new number back to the router for onward dispatch, then we might create an app like this


exten => _3XXXXX,1,GoTo(01484${EXTEN},1)


You can be as imaginative as you like with this because you have the whole Asterisk language at your disposal.

Which brings me to the final transformation option; the areacode and dialplan in the Tenant record.   When you add this any dialled number which matches the dialplan will have the area code prepended automagically by the router.   This is very useful to allow users to dial local short numbers but have them auto-prepended for carriage over SIP.

Hope this helps


 

     

Hi apmuthu

To answer your points. 

The truncation is deliberate because without it the tables can be thrown out of alignment.   However, you can still see the full name by hovering your curser over the cell you wish to inspect.  It will appear in a speech bubble above the cell.

The requirement for a sleep patch seems to be a quirk of OpenVZ since we don't see the issue in either KVM or LXC.  Being primarily a Debian distro, we don't test with OpenVZ because its use is discouraged by the Debian maintainers, in fact I think it has been removed from the Debian libraries since 7.0.   However, on the face of it, a one second delay is no big deal so I'll look at taking it into the mainline.

Kind Regards

Hi

Thanks for this.  The blank page (with just the navigation bar) is standard on both the free and commercial releases of 4.1  The support.htm page you mention has never actually been used, either in the commercial versions or the free ones.  It was planned but never implemented and then forgotten, until now.  :-). 

I'll make a note to have it removed completely in the next point release. 

5.0 will display the Globals panel initially for admins or the userphone page for non-admins.

Kind Regards

The package has been sorted.  If you are running 64 bit and you see this issue do the following


apt-get update
apt-get install sailhpe


That will install the corrected package

OK, I think we've found it.    It looks like a packaging error on sailhpe-5.0.0.1 64 bit for Debian 8 (jessie).    We're working on it now and should have a fix shortly.   

Rsmith - which release of V5 has it installed and which architecture please?

It's deliberate.   There are so few IAX capable phones it wasn't worth taking the code forward.   Aside from the odd soft-phone I don't actually know of any IAX capable hard-phones.  You can still hook up an IAX device by defining it in the trunks section if you wish.       

V5 is now available to install from the repos.  Please follow the instructions here

http://www.sailpbx.com/mediawiki/index.php/SARK_V5.0.0_Debian_install#SARK_5.0.0_Debian_Install

The product is still early Beta so you should not run it in production.  We managed to get some extra features into the product over and above the ones listed above but you can discover them for yourself by spinning it up and playing with it.   

If you are working with a SARK200 then as long as it is 4.1 or better, LDAP will be already installed when you take it out of the box.  For a self install then you must follow the instructions on the wiki.  For LDAP to work you must add an OU with a dc of "contacts" (as detailed in the wiki).   You must also set the LDAP base in Globals.   You can verify the base by running slapcat from the Linux console.   The first line of output gives the base.  In the example below the base is 'dc=aelintra,dc=local'.  Whatever is in your base is what you should put into Globals.

slapcat
dn: dc=aelintra,dc=local
objectClass: top
objectClass: dcObject
objectClass: organization
o: aelintra.local
dc: aelintra

 

From memory, there is nothing to do.   It will simply fetch the 3.x db up to 4.x.   Login is different because you need to login on port 8443 but I think that's about it.

As always, back everything up before you do the upgrade so you can go back if needs be,

You can move the 3.1 database.   Take a copy of the existing db (/opt/sark/db/sark.db) and any other things you may want, such as usergreetings.

Do a clean install on Debian Wheezy following the 4.1 install notes.   Once you've done that take a copy of the newly created database (just in case) then move the 3.1 database to /opt/sark/db/sark.db.   Finally, run

sh /opt/sark/scripts/srkV4reloader.sh

This will rebuild the 3.1 db to 4.x.

That's it, you're done.


Kind Regards
   

We will release it internally next week.   You should see it appear on the deb list in sailpbx.com/sail.   I'll probably put up a dependencies list onto the wiki at the same time.   

Kind Regards