0 supports the older phones and allows the config file to list Polycom Timezone Generator Generates Polycom configuration files to set Nov 29, 2019 Step 3. This template uses dialplan functions, expressions, and a couple of variables to generate a config file to instruct the Polycom where to pull other.

Dependencies

1. Python 3.6 or higher
2. pwgen_secure library. Install with: pip3 install pwgen_secure

This package is designed to read a CSV file, and help you generate sip.conf device definitions, which can then be used to generate Polycom config files.

Quick start and Order of Operations

1. Create a CSV file with at least the following information in it: Extension, Mac address, User first name, User last name
2. Run polypy configure to setup the polypy app.
3. Run polypy sip configure to setup your column definition map.
4. Run polypy sip generate all from /path/to/csv/file
5. Run polypy provision to generate the Polycom config files you need.

Commands

configure

This helps setup the polypy environment by telling PolyPy where to find your asterisk config path, tftp server config path and other important stuff.

Local configuration

In many cases, it's useful to keep a local polypy.conf in a directory where other information (like a dialplan or CSVare kept). polypy is smart, and will check the current directory for a polypy.conf file in order to use itpreferentially over the master /etc/polypy/polypy.conf file.

To setup a local polypy.conf file, execute the following receipe:

1. polypy configure set-defaults here to create the default polypy.conf file at the current path.
2. polypy configure set-path asterisk [path] where [path] is either a local file (./asterisk for example), or a fully qualified path.
3. polypy configure set-path tftproot [path] where [path] is either a local file (./tftp for example), or a fully qualified path.
4. polypy configure show to verify the paths and settings.

provision

Command: polypy provision polycom

This command helps you provision Polycom phones and maintain decent security on those phones. You can:

1. Provision one or more extensions as defined in sip.conf to a single phone.
2. Provision all phones defined in sip.conf.
3. List all the devices that are found in sip.conf
4. Show a particular extension
5. Clean a particiular extension
6. Swap two extensions (really useful when Bob and Alice want to swap phones).
7. Audit passwords
8. Reset a password for an extension.

sip

This command generates device entries for sip.conf and (optionally) voicemail entries for voicemail.conf.See command help: polypy sip for more commands and details.

I'm 'the guy' at my company that's in charge of our FreePBX systems. A while back, I wrote a multi-tenant HTTP-based phone provisioning system, and I'm looking to expand its capabilities a bit.Right now, I can generate configuration files for:. Polycom SoundPoint/Soundstation. Polycom VVX.

Yealink T2X. Yealink T4XGenerally speaking, my provisioning server inspects the incoming user agent and the actual URI request the phone is making to determine its model number. It looks up the inbound mac address to determine which PBX it belongs to, and then generates the appropriate configuration files in the expected format. Well, I wrote the provisioning server, or its core, way back when Trixbox was a thing.

ROI time has long come and gone, since it doesn't require too much maintenance, and provides an easy centralized provisioning server. I've done a bunch of other things with it over the years as well, such as integration with our Connectwise software (phones added in the provisioning server appear as configuration items) as well as monitoring of my offsite backups for each PBX, remote log capture, and other features. All of that, as well as the 1500 extensions currently pointed at the provisioning server, are already sunk.

Technically speaking, I don't have to do anything as long as I'm fine with just operating Polycom and Yealink devices, since the system already works, and all 1500 extensions we have are 99% Polycom and Yealink.I was just looking to expand, and one day to perhaps bundle the system up for others to use. Once, about four years ago, I bundled everything up into a CentOS VM and packaged it as an OVA so I could give it to one of our clients. I'll probably do something similar again in the future.It'd be a bit embarrassing to release it widely though, since I am not a professional coder, and am fully aware that I'm likely vulnerable to all sorts of SQL injection or other hacks.

While there may be some slight differences, and earlier versions offer fewer features, the user should have no difficulty adapting these materials to the version he or she has available.Added Accessibility and Increased Problem Solving for a better user experience. Spss 13.0 for mac. NEW! Revisions to the instructions were made to ensure they were consistent with the latest version of SPSS. NEW!

The only page I really put any effort into securing was the initial logon page, since the first line of every other page is 'Are they logged on? If so, great! If not, back to the logon page for you!' When I complete the Bootstrap UI conversion, I'll probably bundle everything up and send you a message!.

Designing, developing, and implementing your own provisioning proxy is wow.just wow. Bravo.Cisco/Linksys/Sipura SPA devices in our environment pull three files: Settings and Lines file, Provisioning Profile and Upgrade Rules, and Physical Line Key setup. You can do this all in one or generate separate files for later troubleshooting. Is Cisco's Provisioning guide.

Is another.I have not worked with Grandstreams in a while, but I remember they all pull from one config file. The may be what you are looking for in Deployment. These phones are actually great for their price.As for Aastra, I am going to use a Latin quote I always use for those phones: Per Ardua Ad Aastra/Astra (Through adversity to the Aastra/Stars).

In Latin it really means that nothing far is easily reached or that difficult things require difficulty. Is a great place for talk about PBX manual configs for Aastras. But as one fellow to another, Aastras are not worth the troubles they cause.

They have problems with firmware and config corruptions at random intervals. They die quickly (cheap hardware). They are temperamental and reboot often (memory issues). As pointed out, it's not too hard. Especially if you 'work backwards' like I did, starting from a completed configuration file and then 'template-ifying' it into something built dynamically out of data coming from a database. We had Trixbox and its built-in provisioning system at the time, so that was a pretty low bar to hurdle, and I've added tons of stuff in the last decade or so.Thanks for the links, I'll take a look. I actually have a Grandstream phone I can test with, the others are all hypothetical.

I gave a stab at the Grandstream process before, but ran into difficulties getting the password included into the configuration file, but honestly I didn't put much effort into it at the time. We currently support Digium, Snom and Yealink for our PBXs. One issue that bit us recently was that the older Yealinks (T21p etc) which are EOL didn't like the change to a newer SSL certificate style on the SSL refresh so silently decided not to talk to the provisioning server. We had to unlink our http to https redirect for a provisioning cycle in order to push a config change that says to ignore the certificate errors on the old handsets and to update the firmware on the newer handsets which fixes the issue (the firmware not being available on the older handsets). In case anyone is curious, is what the provisioning server UI looks like.First there is a list of PBXs, along with a summary of extensions, PBX version, etc. The Manage link provides a proxied connection to the PBX management GUI, since the web GUI for the PBXs themselves are locked behind a firewall.Clicking on one of the clients gives you the next page, which is in two parts- provisioned phones and active extensions. Provisioned phones are extensions I've already programmed.

Active extensions is a list of extensions queried from the PBX, and then highlighted green if they're already programmed to a phone. If not (as with extension 102 in the example) I can click the No link, and it auto-populates everything but the MAC. If I have a lot of phones to program, I typically use a little USB barcode scanner to save even on that step.The next page is what you get when you click to view an extension. I get a list of contact times with the provisioning server (nightly, assuming all is well), any recently captured logfiles, and in the case of Polycom phones a copy of the phone's contact list.

We've been getting the last attempt to get current provisioning and firmware from the nginx logs, with the source IP provided by the registration info in Freeswitch (which FusionPBX has a nice UI for). Thus far we've avoided the need for on-prem PBXes, TLS w/SRTP allows us to bypass SIP 'helpers' and look like regular traffic, while using the Opus codec handles situations with minor to moderate packet loss.Been meaning to set up Logstash, Elastic Search and Grafana along with an OpenVPN server for the phones/ATAs to connect back to since that seems to be the only secure way to get syslogs for Grandstream devices. Advanced 'features' on my system that I find useful:. Contact times for the phones.

This is mega useful, because talking to the provisioning server happens over HTTP, and it's a different server than the actual PBXs, so when folks power cycle a phone I can determine if the phone has internet access separately from if it can connect to the PBX via SIP. Backup monitoring. The PBXs take local backups via FreePBX's backup module, and the Provisioning server has scheduled tasks for them that retrieves those backups and stores them locally. The web GUI then shows the date of the most recent backup. The provisioning server is also off-site from any of the PBXs, so that's handy for DR purposes. Proxied HTTP and SSH access to the PBXs.

Each PBX sits behind a firewall that is pre-configured to allow the provisioning server to get through. When you log into the provisioning site, you're added to the firewall on the provisioning server and allowed access to port numbers that are proxied and connect to HTTP and SSH. This allows folks to manage those PBXs without having to VPN onto their local network, as well as not having to muck with the PBX firewalls to allow that to happen. PBX IP override. When phones connect to the provisioning server, I can keep a list of incoming WAN IP addresses and, depending on which WAN IP the phone is coming from, send back different results for the PBX server IP. This is useful for clients that have an on-premise PBX, or a VPN, and want to connect via the internal IP address, when people outside that known location want to connect via the WAN IP. This can also be accomplished via DNS if the client has an internal DNS server, but not everyone does.

Built in WebApp directory including presence data. I've got a Polycom and Yealink compatible web application running that gets programmed into a softkey on each type phone that displays all the extensions on the system and their status via the webapp. It's useful!.

The middle three we don't particularly have/need, its one of the nice aspects of running a hosted PBX. For contact times I've found it useful for the odd non-TLS device in the past, as it lets me confirm I can push new firmware and flip the device over to TLS/SRTP without the user doing much beyond rebooting it.How are webapps on the Polycom and Yealinks? We've written a couple for Grandstream's GXP2140 and such, but the status and live call queue app needs the end user to press a button to hit our server and ask for an updated list. Not the best architecture, seems Grandstream really only thought of using it for simple CRUD apps like changing caller ID, taking a survey or similar.