Jump to content
Vodia PBX forum

Vodia PBX

Administrators
  • Content Count

    9,367
  • Joined

  • Last visited

Everything posted by Vodia PBX

  1. When you provision the phone for the first time, it sets the address for the PBX - including the port number. If you change the port number, well, it will become unavailable. What you can do is to keep the old port open (e.g. use "8080 80" in the HTTP port settings). You can change the templates from the web interface (/reg_texts.htm): You can do this on system, domain and extension level. But usually you don't have to do that, just set the general parameter for the phones (reg_pnpparm.htm). When you change buttons the PBX automatically sends a re-provision request to the phone. You can manually trigger that by going to the registration tab for the extension (dom_ext3.htm) and there click on the re-provision or the reboot button for the registration.
  2. What you could try to do is to set the "Label template for private lines" from "{user} {name}" to "", so that the label sent to the phone is empty:
  3. Yes if you want you can try the 63.0.2 build available for CentOS64 and Debian64.
  4. Did you set the country code for the domain, so that the PBX can automatically convert the numbers into the same format?
  5. You find that on https://doc.vodia.com/releasenotes - the IOP were produced on a version that did not list the available options yet. The newer version show you right in the update page what is available.
  6. Its clear where the message is being generated, but not clear why there is now a list... It will take a few more days to figure that out.
  7. Next training will be in Texas - if you like we can share the slides with you.
  8. The scope would be within the ACD, not on domain level but it would send calls away if there is anybody else in the ACD. Maybe you can elaborate a little bit more on the use case, and then we can take a look what we can do to get as close a possible.
  9. Do you have a frame so that we can say exactly where the problem is?
  10. You can do this in the ACD - there is a setting on how many calls may be in the ACD and then redirect the number. But for the auto attendant there is no such setting.
  11. You can limit the number of calls in the domain settings on system level. Would that work?
  12. We had G.722 support for a long time. My estimation is that less than 0.01 percent of the calls were using it, even though most phones support it. There are a few things to keep in mind here. First of all, we have to keep in mind that every kind of transcoding reduces quality. Audio quality never goes up, even when using a great codec. If you are on Opus and then the call gets transcoded to G711, it sounds not as good as everybody using G711. That being said, there are very few (no?) SIP trunk providers that offer anything better than G.711. Internal calls may have great quality. The problem is that they are usually not the call generating revenue in businesses. Most modern HD codecs were written for client devices, meaning that CPU usage is not a big deal. However when you want to have 500 calls going on in the PBX, it is a big deal. It is debatable, but IMHO there is a certain user expectation about how a office phone system should sound like. When IVR sounds narrow band, callers have that warm fuzzy feeling they are talking to their good old (and reliable) phone system. From a sales point of view, Opus and HD are indeed a great way to wow new customers. That is currently probably the most important point. We have added Opus to the development branch, however this needs to be tested first and made sure that it does not cause any harm. We need to change the default priority of the codecs and put HD first. Otherwise nobody will ever experience HD audio on the Vodia PBX. We found only a few Cisco and Polycom models support it today. Its a chicken egg problem obviously, and the PBX should take the first step.
  13. 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.
  14. 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.
  15. ... 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.
  16. Looks like the link is not working any more?
  17. We will just not touch the SSH files unless this is a IOP in the next version - stay out of trouble!
  18. 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.
  19. 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}
  20. 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.
  21. 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.
  22. 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.
  23. 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.
  24. Scheint jetzt zu klappen, jedenfalls auf unserem Test IOP. Wir sind immer noch bei 62.1.
×
×
  • Create New...