Vodia PBX

The other thing to keep in mind is that the PBX keeps the history of the passwords. If the password that you want to set was used before, it will not set it. The history goes back to the last 3 attempts. Please make sure to set a "random" password. This might be confusing. The web front end is supposed to inform you about this, but maybe there was a glitch that this did not work.

That was the idea already. The point is that the conversation belongs to the ACD, not just to an agent. I that agent is not logged in, the PBX will try to assign it to another agent that is logged in when the message arrives. However there is no explicit control over this right now.

That is very high indeed. We have addressed some issues with unnecessary network messages in the next version of the PBX, however those messages should be a problem only if there is a domain with a lot of calls. The app largely ignores those updates anyway, so we cut them out on the PBX side. How to test if this is the problem: If you put the phone into airplane mode, those notifications should not bother the app any more. If that is the case we could assume that they are really network related.

Yes on hold the user can press a key and then the PBX will send a SMS to the user phone number. The MoH should contain some text that tells the user what key to press. A typical example would be "la-la-la If you press 4, we will text you a link to our menu la-la-la If you press 5, we will text you a link to our partner page la-la-la ..."

Maybe your browser auto-filled the passwords in error, so that they ended up being the same?

My guess there is a problem with the certificate: % curl -vv https://techguysio.pstn.umatilla.twilio.com:5061 * Server certificate: * subject: C=US; ST=California; L=San Francisco; O=Twilio, Inc.; CN=*.us2.twilio.com * start date: Feb 18 00:00:00 2021 GMT * expire date: Feb 22 23:59:59 2022 GMT * subjectAltName does not match techguysio.pstn.umatilla.twilio.com * SSL: no alternative certificate subject name matches target host name 'techguysio.pstn.umatilla.twilio.com' * Closing connection 0 * TLSv1.2 (OUT), TLS alert, close notify (256): curl: (60) SSL: no alternative certificate subject name matches target host name 'techguysio.pstn.umatilla.twilio.com' More details here: https://curl.haxx.se/docs/sslcerts.html curl failed to verify the legitimacy of the server and therefore could not establish a secure connection to it. To learn more about this situation and how to fix it, please visit the web page mentioned above.

Its probably more important to know that there is someone waiting in a park orbit than showing the caller-ID. We could make that an option for the park orbit, so that we don't loose the functionality to show the original caller-ID, e.g. for VoIP phones with a small display. But we should have an option to just show the name of the park orbit for that call and then when the user accepts the call, we can change the caller-ID back to the original caller-ID.

I noted something in the 13-Numbers. Starts with "611300" seems fine with me, however starts with "613" would conflict with Victoria. Is this just a typo? Should this be "6113"? Maybe the problems with 61300xxxxxx are related?

PING is the #1 tool for robots to find SIP servers in the Internet. That is why the PBX by default ignores PING if it comes from an unassociated address. What you can do: Set up a dummy SIP trunk that has the outbound proxy set to the address of the monitor Use SNMP instead of SIP. Then PRTG can also report additional information like how many calls are active. Use HTTP instead of SIP. Then you can just pull e.g. robots.txt or you could also pull a REST API statistics that shows e.g. how many registrations are on the server.

Thanks for that detailed overview. The reason why the PBX is using hyphens is because spaces are used in many forms in the web front end to separate list entries, including the forms for the DID numbers. In the USA, phone numbers are often written like (617) 399 8147 which is even "worse" than Australia! Other countries like Germany also prefer spaces, and they also include extra characters for the area code, e.g. (030) 55578992 or (030) 5557 8992 depending who you ask. One way of solving the problem would be a different presentation in the user front end and the administrator web interface. OTOH there are only a few places where there are multiple phone numbers in a form field, and we could as well JavaScript that form element to present and accept the human readable format as well. Then we don't have to do any assumption on what characters may be used and format the number in the best human readable form. Another problem is that users actually really dial those strings as phone numbers, maybe because of copy and paste or maybe because they like to enter them that way. However we already have a PBX settings that defines what characters are removed from the dialed string. That setting should already be compatible with all human readable formats.

That feature is available when the user is on hold. It makes sense to put that also into the auto attendant, we'll have to put this on the to-do list!

It looks to me like the number is not set up for sending SMS. There is a checklist on https://developers.telnyx.com/docs/v2/messaging/quickstarts/portal-setup that might be helpful. IMHO the message itself looks okay. They might have change the authorization header, but it does not looks like they broke the previous version.

New York should be really easy. You can just select the East coast time time. Actually the PBX does that automatically for you when you install the PBX.

I would use 67 for that. Only key "aha" is that the PBX needs to find the right certificate. When you upgrade to 67, make sure to reset the certificates then this should be working without problems.

Well, the idea is to follow https://en.wikipedia.org/wiki/Telephone_numbers_in_Australia and present phone numbers in the format that the Australian human would be able to read it properly. Right now you could take the country code out, however that has a lot more consequences that just adding the hyphens for readability. We could add a setting that suppresses the re-formatting, but before we do a step like this it would be great to understand what exactly the problem is. Is the formatting incorrect?

The hyphens are inserted in the "display" name, the number itself should not contain hyphens. E.g. "030-55578992" <sip:03055578992@vodia.com> it depends on the country code. It should help with the readability of the number. If there is a name already available or the number is in the address book, then the PBX should not do that replacement. What country code are you using?

Is there a link to the API description? Or is this your own API?

Go to the status web page on the system level (the version actually is also available on the domain level status screen).

Are you trying to import this in the domain or on the user portal? What version are you on?

The preview is really just the preview. If the other records are not getting imported that sounds like there must be some problem with line 6? Did you try to import e.g. from line 10 onwards?

Not really. The workaround for now is to create a SMS account for each domain and then have the billing from the SMS provider. We are a little hesitant with changes in this area because there are more topics coming up which essentially need the same kind of flexibility like for regular DID and we first need a clear understanding on how to properly address this in a bigger picture.

This is what we are using for Twilio right now Twilio.prototype.send = function(obj) { var body = "From=" + encodeURIComponent(obj.from); body += "&To=" + encodeURIComponent(obj.to); // Do we have an attachment? if (obj.url) body += "&MediaUrl=" + encodeURIComponent(obj.url); else if (obj.wav) bbody += "&MediaUrl=" + encodeURIComponent(obj.wav); else body += "&Body=" + encodeURIComponent(obj.text) system.http({ method: 'POST', url: this.base + '/Accounts/' + this.username + '/Messages.json', header: [ { name: 'Authorization', value: 'Basic ' + toBase64String(this.username + ':' + this.token), secret: true }, { name: 'Content-Type', value: 'application/x-www-form-urlencoded' } ], body: body }); } The settings are also available on domain level. this.base is 'https://api.twilio.com/2010-04-01' but it can be overwritten if needed.

Most most environments it is much easier and faster to just make a backup of the working directory of the PBX. You can even schedule that, e.g. daily backups.

The PCAP shows two-way audio. This looks like a problem with the audio path on the device.

Bottom line: Use a virtual machine. That will give you great redundancy within the data center. Using the PBX failover makes only sense if you want to do a geographic failover ("nuclear strike"). Make backups in case you loose access to the VM, e.g. forgot to pay your bill.