Skip to main content

The system sends notifications to users and administrators when certain events occur. This can be done by email or by text messages (SMS). Those messages are usually just warnings, however the administrator should check if there is a serious issue causing the problem that needs attention.

Administrator Addresses

Admin email addresses: This setting controls where the PBX sends email notifications. In contrast to many other settings, the addresses must be separated by semicolons. This makes it possible to include space characters in the addresses, e.g. the names.

Cell phone numbers for the admin: This setting contains the cell phone numbers of the admin account. You may use more than one number, separated by spaces. If you are not sure how to present the number, use the +-form like +12341231234.

Text Messaging

In order to connect the PBX to a text (SMS/MMS) provider, please select the provider from the drop-down. If your provider is not listed, please contact Vodia to have the provider added. Because the various SMS providers require different types of authentication, the form will prompt for usernames, identifiers, tokens and passwords accordingly.

For the HTTP GET provider, the username must be used for the URL. The URL may contail variables like {from}, {to} or {body}, for example https://test.sms/send?f={from}&t={to}&b={body}. The password variable will be replaced with stars in the log file. If the variable is not available, the log will a message which will show what variables are avalilable.

Text messaging enabled for domains by default: This flag determines if domains by default have texting enabled or not. You can override the setting in the domain list by editing the domain settings there.

URL prefix for receiving messages: Most providers will POST an incoming SMS/MMS to the PBX web server. To identify that request from other requests, the PBX needs to use a unique name in the URL of the request. Usually the default (recvsms) is okay; you need to make sure that the provider uses the same string. You also need to make sure that the SMS/MMS provider can POST to your server. If you are operating the PBX behind a firewall you will have to make sure that the firewall uses port forwarding or your are using the remote access for the PBX. If you are using the remote access, you can just use the remote access URL for the SMS/MMS provider.

Address for pulling MMS content: Depending on the provider, the PBX has to send MMS content as a link that the provider will then use to pull the content from the PBX. The address should be the HTTP or HTTPS address under which the PBX can be reached from the SMS/MMS provider, for example It is recommended to use the same address as the system managemenet DNS address, so that the certificate for the secure connection is available.

Default ANI for sending SMS messages: When sending out SMS/MMS messages, the PBX needs to figure out what number to use for outbound messages. This setting set the fallback number if it cannot be determined on extension or domain level.

Google Speech-to-Text

You can use the Google speech-to-text API to have the PBX generate a text preview of voicemail messages. The PBX will potentially use the API for other purposes as well, for example to help the auto attendant determine where to route incoming calls.

API Key: The PBX needs the API-key for authentication with the Google API. You get this key from the Google console.

Voicemail-to-text enabled by default: This flag determines if domains by default have transcription enabled or not. You can override the setting in the domain list by editing the domain settings there.

Maximum duration for transcription: This setting determines how long the audio can be. The API that is used by the PBX supports up to 60 seconds, however you can make it shorter with this setting.

MP3 Attachment Encoding

Many email clients support playing back WAV files, so that users can listen to a voicemail from their email instead if dialing into the PBX. However some clients don't support WAV and need MP3 format. Before the PBX sends out a voicemail with the audio attachment, it checks if there is an external service available that converts the WAV file into an MP3 file.

URL for transcoding service: This setting tells the PBX where the messages can be sent with a HTTP POST request. If you want to use the Vodia service (no service levels guaranteed), you can use{key}. The PBX will replace the parameter with the actual key.


Send the midnight email about the CPU usage of the last day: This email contains important information about the resource usage of the PBX, including the CPU load and the packet load on the system. It is send at midnight of the system time zone.

When a call gets rejected because the CPU load was too high: The PBX rejects calls when there is too much CPU load for processing calls. This is important in order to avoid an overload of the system and degradation of ongoing calls. The system may inform the administrators of the system about this important event.

When the status of a trunk changes (if selected in the trunk setting): A status change usually means that the Internet connection went down, or that other critical resources like the DNS server became unavailable. If the PBX is sending a lot of those events out, it means that the PSTN termination is unstable and must be fixed.

When the license will expire in less than 30 days: This email make sure that the administrator takes care about the server license. It is also sent out when only certain parts of the license expire, for example a 30-day trial on a specific feature.

When a registration status of an extension changes: Similar to the notification about a trunk status change, this notification may indicate problems with the stability of the network connection between the endpoint and the PBX or general problems with the endpoint (e.g. repeated crashes because of software issues).

When the system was restarted: After a restart the PBX sends out this notification. It might occur after a reboot, e.g. when power was lost. This notification implies that there was a time when the whole system was unavailable for a few minutes.

When a new recording is available on the file system: This is a pure informational notice that can be used to trigger the uploading of a new recording into a remote location, e.g. for transcription services.

When the allocation of a new CO-line failed and a call was rejected because of this: When this notification gets sent out, the number of available CO lines was exhausted on a SIP trunk. This does not necessarily mean that there is a problem, but in many cases it means that the administrator should consider adding more CO lines to the trunk

.When a trunk failover event occurs: The PBX is able to re-route calls on backup trunks when a previous trunk was rejecting the call or when a timeout occurred. Depending on the setup, this notification may be purely informational or an important indication that the primary trunk became unavailable, and needs further investigation.

When someone dials an emergency number: Calling the emergency number is an important event in many environments. This might be a message that should get a priority treatment in the email client. It may also serve documentation purposes, as it also contains more information about who started the call and the exact timestamp.

When the PBX disconnects a call because of one-way audio: This notification helps to track down hard-to-find cases when there are network problems with transporting RTP streams correctly. The notification contains a timestamp which can help identify PCAP traces that contain the packet data of the call.

When the PBX disconnects a call because it could not be established: This notification is triggered when the PBX was unable to locate the RTP destination for the other side of a call leg, and consequently did not send any RTP packets out. This is usually pointing at SIP protocol problems that need a in-depth investigation.

When a registration changes its address but keeps the call-ID: This case happens when the source address of a SIP registration changes. Although this is allowed in the SIP protocol, it causes gaps in the reach-ability of registered devices and almost always points at network problems. For example, when using routers that have small NAT translation tables with only few entries and drop oldest records in order to make room for new records. The administrator should make sure that those routers are replaced with devices that are able to properly handle NAT.

When the PBX received a BYE message and did not receive media just before the BYE: This message may hint at problems with the network setup. A typical scenario is that the user experiences network problems and does not receive media, and then decides to disconnect the call. Although technically correct, it almost certainly points at technical problems with the network and the extension used by the user.

When PBX blacklists an IP address: If the PBX detects an intrusion, it sends a notification email to the administrator about this event. It may mean that there is a hacking event going on, but it can also be caused by equipment that keeps on registering with a wrong password.

When paging playout fails: When messages are queued for playback from an paging account, they are usually guaranteed to be delivered. However it can happen that such a playback fails, for example because all handsets lost their registrations.

When call failed due to low credit: When using prepaid accounts, accounts can run out of money. In that case the PBX rejects a new call or tears down ongoing calls and delivers this notification.

When the number of trunk calls exceeds the threshold: For each domain, the system administrator can limit the number of calls that can be made on trunks in the according domain. The administrator can also specify a threshold that triggers sending out a notification when that limit gets close. This helps adjusting the value for the trunk call limitation.