Vodia PBX

Do you have anything in the log where we can see what exactly is sent to the PBX? For example turn the logging for Call-related SIP packets on - then we should see what is coming in. Also, do you have a country code set for this domain?

You can always use the ERE for inbound trunk routing, for example the one below !^00([0-9]*)$!+\1! !^([0-9]{6})$!+423\1! 40.

There were a couple of issues with the *58 code. First of all, the initial message was confusing. And it could have been that the database query for the next recording did not look at the right fields. However it is important to dial into the right ACD, the code is playing back only the recordings of a specific ACD or account.

You don't have to worry about the media IP - the PBX does not filter for those. As for the signalling IP, you have two choices - leave it empty and assume that you will never receive a packet from another location except where you registered. That is actually a reasonable assumption because everything else will not work with NAT anyway. Otherwise you can write a little script in the programming language of your choice that produces the list of IP addresses - there is no limit on how many addresses you can list there.

In terms of settings what you could do is provision a phone, and then take a look on how it was set up - kind of reverse engineer what has been provisioned. Instead of using the LDAP password you can then use the extension web password, and this should work.

That sounds like the message was lost? Can you play it from the web interface?

You cannot set the LDAP password - it is automatically generated. This is because many SIP phones don't support TLS or StartTLS or it is simply buggy (e.g. no SNI extension and problems with the certificate). Then it is better to limit the damage and have a separate password just for LDAP which does not have the permission to make calls. But you can use the web password instead. It serves as the "master password" for the account - bear in mind if that password leaks out attackers will be able to make calls using the password.

CO lines in SIP work different than in old key systems, especially when "seizing" a line. In order to seize a line the phone actually needs to make a call to the co-line account. Then you would have to enter the phone number in this call - and there would be no way to delete the last digit and the phone system would have to guess when the number is complete to send it to the SIP trunk. In many cases it is better to just use park orbits instead where there is no seizing of lines, just park and pickup.

In principle a good idea. You can get this working obviously on iptables level right now, though it may take up to 4 hours to fend off an attack. We have an automatic blacklisting feature since ages - what could be interesting is sending that information back to them so that they can consider blacklisting the provided address.

Did you try *58? You need to set the permissions for that feature in the permissions tab of the extension to use this feature. Then you can enter what calls you want to listen to.

This will be difficult to discuss here on the forum - better schedule a hangout with support and go through the details.

There should be a try button - can you turn on email logging to 9 and then hit the try button? Anything obvious in the log?

Well coming from the SIP world this should be easy - do you have an example DNS name that we can use for testing?

That is the image that the user has uploaded as picture for that extension. The background images are problematic. What we (and most customers want) is to upload the logo that is used as co-brand on the phones. What snom and most other phone vendors offer right now is uploading the background image. If we upload the background image, it usually breaks the whole screen look - badly. We suggested to add a feature to load a brand logo, so that the phone can handle the positioning on the various screens with the right resolution and position. We have not heard back about this yet but I think it makes so much sense that it is only a question of time until the phone vendors add this.

Is this "DNS SRV"?

The easiest would be to add an option for a domain or even the whole system that tells the PBX to just copy the From/To headers?

Well are other emails going out so that we can exclude general email problems? Is the email destination in the right format?

Were there any custom ringback tones in the domain before the migration? Maybe the files are not there - this could be fixed by just uploading them again and assigning them again to the domain.

Caching can be an issue here - I such cases I would try to use the incognito mode of the browser or another PC to make sure that this is not a caching issue.

The standard versions have only one trunk, see https://vodia.com/products/pbx-software/

You will have to set the "Profile Rule" manually for operating them in the cloud, but that should be the only difference.

There is actually a video about this

No - Vodia is multi-tenant. You need only one IP address for many tenants. Amazon usually gives you only a private IP address on the local EC2 instance. But that is not big deal, you can tell the PBX to use the public visible address instead.

That problem seems to be resolved in the latest version, the link is https://doc.vodia.com/dns_cache

Yes of course.