Vodia PBX

You can put multiple identities through provisioning only within the same domain (you can still use multiple domains manually through classic SIP registration). For this you need to copy & paste the MAC address from your first account into the other accounts and re-sync the device. The order is kind of random, not sure if it is sorted by MAC or by first addition and there is frankly not much control over it. But in many cases you don't need that. The ACD has a feature for virtual offices, so that the PBX can indicate the called number on the display or even through a small announcement at the beginning of the call. Your setup sounds like it should work. I would double check that the address did not get blacklisted. In the button profile, you can select the "identity" it should use when assigning a button. This should be important for the phone, so that at least one line is available for each registration.

One thing that is (and probably will remain) a problem is if your PBX is in the LAN and the app is not. Then the wakeup from Apple will still work, but the app cannot contact the PBX and then you will have that effect. The solution for this is to make the PBX available from anywhere (AKA public IP), either by putting it into the cloud or programming your firewall to make it look like that.

If there is a "green" icon next to the address and your PBX operates on a "routable" address, it should work with all browsers. Some browsers have special flags that allow exceptions, for example to allow WebRTC on insecure connections like http. After uploading a X.509 certificate, many browsers still keep the old certificate in the cache. In such cases "F5" is often not enough to refresh the cache. If the iOS also rejects the certificate, well then there must be something wrong with the import or the name of the certificate. The internet is full of forum questions around certificates (not only on the Vodia PBX)... The easiest is to use a lets encrypt certificate where this is all done automatically for you.

The PBX just calls the number that was visible. That is okay in most cases. But I agree, we should confirm the number to avoid accidental call backs. The other thing that we are working on is a virtual hold, where the caller gets called back at a time when the caller would be waiting in line.

We have that in the latest (beta) image.

It is not a simple topic. Generally speaking, "never change a running system". This applies especially for older models where is it sometimes better to leave them running with their version, even if there are know bugs instead of taking the risk of upgrading them with new problems. Apart from that, it makes sense to use the latest official releases. If you feel you need to use a different version, I would try those versions. You can do this specifically for one extension, just change the firmware link in the parameter section for the extension (in the provisioning tab).

This is usually a problem for the ATA—I assume that you are using one? On the PBX, you would have to assign a "dial plan" for the extension where the ATA is registered. Then you should be able to dial out.

The first one (whatever that is). If you put the DID on a ACD, it will try to route it to an agent that is available on the app and if there are several available, it will send it to the one that was in the conversation.

I would make a PCAP trace for the call and see what happens in terms of SIP and RTP. You can open a ticket and attach the PCAP there so that we can take a look in private.

Thanks. We actually fixed a similar problem recently with initial DTMF coming in after a transfer from another system.

You can assign as many DID as you want to an extension. For example, you could assign one just for conferencing purposes. Depending where you are coming from, this "DID" can also contain also alphanumeric characters. So for example, you could use the alias name "conf-5434634564" as DID/alias name for the extension and then call in from a trunk that goes directly to the conference server, so that there are no carriers involved. The PBX will then take care about ringing the user up, including desktop phones, cell phones and apps.

We are not against it at all, actually believe that this is a great step into reducing SPAM and increasing office productivity. There is a nice description on the Bandwidth web page (https://www.bandwidth.com/glossary/stir-shaken/) that explains the call flow. The PBX is either the "calling party" or the "called party", authentication is done through username and password. So the PBX would be the "end user"—even if the PBX is not physically on the end user premises. Do you know any SIP trunk provider that would parse STIR/SHAKEN headers?

Short-term we can only offer a MSI that does not come with a trusted certificate. You would have to do some changes in the registry to be able to install it. We are working on this.

We checked the topic some time ago—as far as I can see this is a topic for the service provider. Even if we would support it, I am not aware about any service provider where we would even have the chance to use it.

You can show them on domain level. On system level I would just grep in the macs directory. There is actually a script on https://doc.vodia.com/shellscripts that would show it on command line level if you are on Linux. I think this script should still work.

Subdomains are usually for free if you already have a domain for your company.

Ok, after some searching it looks like LetsEncrypt does not issue certificates for this domain name: https://community.letsencrypt.org/t/policy-forbids-issuing-name-for-aws/95246

There is a log level "Log ACME certificate processing" to 9 in the system log—I would turn it on and see what the PBX has to say. One of the key questions is if the robot is trying to validate the certificate. That would mean that port 80 is available.

Yea certificates are actually a very complex and confusing topic. The EC2 DNS name should work, but of course you need to make sure that the Amazon firewall passes requests to port 80 through to the PBX (also you should open port 443 for the actual HTTPS access).

The field can contain variables: $f: The "from" caller-ID $t: The "to" caller-ID $F: The original "from" caller-ID before the PBX reformatted/changed it (e.g. during a transfer) $T: The original "to" caller-ID $g: The group name $c: The CMC code (if available)

Well... Do you own that domain? If not, it would be quite a surprise if the robot would issue you the certificate! You prove that you own the DNS address by pointing it to the IP address of the PBX and make port 80 available in that address. I mean, if you try pbx.google.com it will most likely also not work unless you work there and have good relationships with the management.

We have added another option in the dropdown for the "what-to-show" option which will show the calling and the called number in the same header (in the next build). It does actually not require a code change, just another option in the dropdown, so you can also just to it by changing the template e.g. for the dom_hunt.htm web page: <option value="cmc2">[[dom_acd.htm#from_cmc2]]</option> <option value="$f ($t)">[[dom_acd4.htm#from]] ([[dom_acd4.htm#to]])</option> <option value="original">[[dom_acd.htm#from_original]]</option>

For hunt group and ACD, you can select what you want to see on the display (its called "From-header"). It can include the group name, which is often better than the number. In theory you could give the group the DID as the name. Then it would show the DID and the caller-ID.

There is a "reset" button on the page that will bring back all the default Root CA. Just press it and then the PBX should be able to fetch the lets encrypt certificate for you.

You can assign multiple names to a single domain, e.g. "bla.pbx.com" as primary name and "bla2.pbx.com bla3.pbx.com" as alias names. The problem seems to be that the PBX does not trust the letsencrypt server. Did you delete the certificate in the list of default certificates? I think it was "DST Root CA X3".