Vodia PBX

There is some documentation now at https://doc.vodia.com/hubspot_crm

For buttons it really makes sense to move on to 62, maybe 62.1 if you want to convert your button profiles automatically. Especially for the Polycoms where we have changed the template, so that the button layout works properly.

There was a problem on some older versions - however in the 62 version that should be solved?

Sounds like some timeout is too short. Are you able to call a call phone of a user from an extension e.g. using the *00<ext> star code and does that connect fine?

The HubSpot API integration of Vodia would not go to https://api.hubspot.com it would go to something like https://api.hubapi.com/contacts/v1/contact/ and provide the API key. If you are trying to use this with an ActionURL this will be difficult/impossible because this cannot be done with just a single HTTP request. If you really want to code this yourself, there is a lot of information on HubSpot on how to write the integration, e.g. https://developers.hubspot.com/docs/overview

As far as I can tell the basic Hubspot account can do the integration. You don't need to use the ActionURL in the PBX - it is all done for you. What it does is after a call look up the phone number, and add a log entry for the contact about the call. If the number does not exist, it creates a new contact and then adds the log (optional). A problem with Hubspot is phone numbers are used just as strings, on other words 212-123-1234 is different that (212) 123 1234 or +12121231234. So if Hubspot users manually enter phone numbers in their own format, they cannot be found through the API. The other thing is that there is a log entry for calls, but there is no way to indicate the direction of the call (which is kinda important IMHO), this is probably because Hubspot assumes only outbound calling. We tried to raise the issue with Hubspot, but we were not able to get an answer.

You can generate the test invoice in the admin edit domain view (where you would set limits on how many account that domain can have). There you can also assign what plan to use. There is still the issue that the PBX needs at least a day of history to calculate use data. However fixed cost will be billed immediately. Also if you make a few calls, the cost for those calls will also show up on the invoice.

If the snom works fine that means that the LAN setup is not the problem. Cisco SPA 508G is currently not on our list for LAN provisioning. So if you see the Grandstream in the list that means is has discovered it - if it has the default username and password then the PBX would try to reach out to its webserver and set everything up for you. Grandstream has a large variety of devices and firmware versions; what could have happened is that something has changed in the web server.

Well that is good news - however it should show up. Apart from being in the same LAN, the phones should be factory reset (have the default username and password). And the MAC should not be in the PBX listed yet, so that it can recognize it as a fresh want-to-be-provisioned phone.

No you don't need a third party. The PBX talks directly to the hubspot API. Too bad hubspot did not list us yet - we see them practically every day on the commuter rail LoL.

You have to put this into the dom_crm.htm page:

If the phone is already provisioned e.g. through the cloud you cannot provision it from the PBX "zero touch". Otherwise the phone would have obviously a bigger security problem... Is there a way you can un-link it with the cloud first? Then you should be able to factory reset it and provision it through the PBX web interface. Also if you are not using the system yet, try upgrading to 62.1 which has the latest features.

For that to happen the IOP needs to be in the same LAN like the device - otherwise the IOP cannot receive the multicast packets.

It is still in beta - for now I would put the sk_test and pk_test keys there. We need to update the documentation before we can release this.

HTS 32? What vendor is that again?

Yes Opus made it pretty much to the top of the list now. It is a awesome codec we were wishing for for years, and more and more products can use it - maybe one day even SIP trunks can use it!

Hmm, did you also explicitly list the addresses for the trunk? In the access list you should see in the comment column the name of the trunk - that would be the indication that the PBX has added that address for the trunk. If you do a trunk-trunk you need to do that on both systems.

Yes this is probably the fastest way to get this resolved.

For licenses you need to go to portal.vodia.com - the PBX itself goes to license.vodia.com (which uses a Vodia-signed certificate). In such cases open a ticket a vodia.zendesk.com and we'll take a look.

It seems that this issue was found and fixed on the latest 62.1 build.

We keep making versions for those who need the latest and greatest version - usually most customers are okay to run a little bit older versions. Those versions have a "round" number and they have the release notes. Most of the action is of course happening on the latest and greatest builds, we invite partners to use it so that we can quickly improve it. There are probably books written about this approach; we want to make sure that we are not falling asleep releasing versions only every few months or even years. You find the working directory in the status screen of the PBX, it is usually /usr/local/pbx on Ubuntu systems. All you have to do is tar this directory and put it somewhere - then later you can move back to that version if you have to.

Yes, actually many models are straightforward with this. Grandstream unfortunately needs many different provisioning templates, which make it a lot more work for us to support each model. snom needs another identity for the failover which is difficult to provision.

Win64 is also available for 62.1 now.

I would first of all see what the web client sends to the GS RPS - maybe a simple authentication issue. We had many issues with browsers filling out the password fields, which overwrites the RPS passwords. The other thing is that the vendors keep changing APIs and we have to change this on our own backend as well... Please open a ticket and attach the web client logs - then we should be able to see what the problem is this time.

There must be something fundamentally wrong with the "feature is not available" - can you call into another extension mailbox successfully? This should be really a fundamental function that should work.