Vodia PBX

Vodia also has an app - for Android. But it is not as good as other soft phones. Like with the hard phones, there is a market place for soft phones. Especially when it comes to small native apps, it IMHO is better to look at those apps. Customers are not stupid, they can search the Internet in one second what a good soft phone is and it can be hard to sell them the (only) one that comes with a specific PBX.

Maybe you had translations turned on? That cuts you off from changes in the texts - maybe check if you have a translations.xml file and (re-)move it.

... keep in mind there is a market for SIP soft phones that is becoming as competitive as for the hard phones - giving you a great choice in terms of OS, pricing, look, integrations and so on. We are increasingly focusing on integrating those. CounterPath and ZoiPer are already well integrated with provisioning, and future versions will add more of their features as well.

Looks like the link is not working any more?

We will just not touch the SSH files unless this is a IOP in the next version - stay out of trouble!

Well we have a Chrome extension - no idea how much different that is from Firefox. We could share the code with you if you want to take a look.

When you set up the trunk, did you use the easybell drop down? That should contain all the headers the right way. The important part is this: hf: <sip:{trunk-account}@sip.easybell.de> hpai: {from} hru: {request-uri} ht: <{request-uri}> hpr: {if clip true}id{fi clip true}

We would love to remove that feature, but we tried a year ago and there were still people using it. We even tried to hide the field which resulted in another uproar... Taking things away that are used for years is not making friends! Anyway for new installations I would not recommend to use it any more.

Well, is there a difference on that we should have for IOP (which is Rasperian) and a Raspberry Pi 3 Model B+? Originally we did not really change the SSH files, just patch them - however the problem was obviously that the OS upgrade wiped out SSH and now we had to write the complete file to get this working. Maybe we have to do this depending on the SSH version? IMHO it is a big deal, because IOP users should have shell access when they enable it from the GUI. Actually the script even restarts sshd, so it would not even require a reboot.

The "additional agents" are just put on the list as if they had logged in. The typical case is to include additional resources, e.g. managers or sales personell when agents are not picking up calls. The algorithm to choose the next agent is then done as if they had logged in. Ehen using the "longest idle first" that would usually be a manager, so it might make more sense to choose the random logic. It does not really help to get the waiting lines shorter. Maybe we should have another setting that says if there are more than so-and-so many callers waiting include the following agents.

In this case the URL checking is actually correct - in this field you can only use HTTP or HTTPS. The content is always "SOAP" there is no JSON. It is a very old setting, for those who still remember what SOAP is.

Scheint jetzt zu klappen, jedenfalls auf unserem Test IOP. Wir sind immer noch bei 62.1.

Die SSH Konfiguration da oben scheint nicht zu funktionieren. Wir werden wohl ein anderes Template verwenden müssen...

You can still install the Vodia Chrome extension that allows you to dial from the web browser - this is a general tool not limited to HubSpot. Apart from that we did not find anything else, e.g. pop-up on incoming calls to be possible with HubSpot.

There not not really any more tags than used in the templates. It is somewhere on our to-do list to have this a lot more flexible, but it has not been done yet.

It's in the domain, under "Advanced". The CRM integration requires a hosted or enterprise edition license.

As far as I remember POTS this is a standard feature of FXS - yes you can connect two phones and then who ever is picking it up will get the call. However when the one line is busy you cannot have another call - that is why they probably invented digital telephony!

Well there is https://doc.vodia.com/pnp_yealink and also we'll do a free training next week in upper state New York in case you want to quickly come there. If you are setting up phones n the LAN, there is https://doc.vodia.com/pnp_lan_prov - if the T46S was factory reset you should be able to assign it to an extension literally with one click.

So we tested this in the lab - in the 62.1 version there was obviously a bug that was causing problems looking up the email of the agent. This should be fixed in the latest 62.1 (beta). Also make sure that the one who calls has an email address in the extension settings - this is how we correlate the caller with a HubSpot account.

Well while we are trying to keep Chrome from filling out password that it should not fill out, obviously a few areas went over board. At least the admin password seems to save again... Hopefully we can close this chapter soon. Sorry 62.1 is still "beta".

Wir haben mal ein neues 62.1 gemacht wo diese Dateien nach einem Neustart geschrieben werden.

Das "ExecStartPre=/bin/mkdir /var/run/sshd kommt" von uns, und wir machen auch das "PermitRootLogin yes". Das IOP muss die Datei ändern wenn man vom Web-Interface aus SSH einschaltet. Ohne die Änderungen ist es uns auch nicht gelungen SSH einzuschalten. Vielleicht sollten wir das ganzer rumdrehen und mal versuchen raus zu finden was denn in den beiden Dateien richtigerweise stehen sollte?!

We just tested this again - there was a lot of chaos around the browser actively putting in passwords. It should be better now - latest 62.1 (we are still beta).

Was ist denn in /etc/ssh/sshd_config und /lib/systemd/system/ssh.service? Das Rasperian hat da auch seine Finger drin... Wir haben gesehen dass ein Update von Rasperian SSH abgeschaltet hat wegen alter SSL2.0 Unterstützung.

Ok that problem should be fixed again in the latest 62.1. Hopefully Stripe and Freshbooks are not interfering any more...