Vodia PBX

There were some issues with the proper CDR reporting, it would be great if you can move to 56.0 or even 56.5 (CentOS64 or let us know what build you need).

You mean the window.location.hostname there? Or the general idea that users should use a secure transport layer? You can also edit the welcome js, just create a html folder in the working directory, put the content of the welcome.js there and you can happily edit it right there.

Well in the CDR there is no such thing as an agent, there are only extensions. Even when calling an extension directly, it shows up as Auto Attendant because behind the scenes, the Auto Attendant takes care about redirecting calls after some time, screening callers and other things. Are you sure it went through the ACD and not an auto attendant? The "undefined" in the extension legs raises my attention. There should be no undefined.

That is one of the major problems with SIP on UDP. The INVITE packets come dangerously close to the MTU size, e.g. if you have a long name and many codecs, you easily hit the 1500 bytes. If the provider goes down to 1200, then the probability dramatically increases. The answer is, use TCP or better: TLS. SIP/UDP was a major mistake anyway.

This should work. Don't log in with the user@domain, just the user. Do you see a green lock? Actually what version is this?

So you are navigating to https://that.subdomain? Not to https://12.23.34.45 right? The browser might have a problem redirecting to another domain, that is what happens when you log in through the main portal and then the PBX figures out that you actually want to log in to a domain.

Certificates are generated for a specific DNS address. If you go to another address, the web browser will reject the certificate (otherwise everybody could just slap any certificate on any server and pretend to be google.com). You might need a wildcard certificate if you want to have multiple domains on that server, or at least one certificate for each domain.

There is definitively something not all right. Anything in the log of the phones? Do you see the INVITE hitting the PBX, e.g. in the log? Maybe something with DNS? I guess there was no software update on the phones or the PBX?

Yes. Definitively.

It is set by the system and domain. There is also a way to set this by the license key, but AFAIK we used that so far only for demo codes.

The BYE (at the end of the 50 MB) says Preemption;cause=3;text="Maximum Call Duration" well there must be a maximum call limitation. Remember that there are several places where you can set it, globally but also per domain.

You could use the regular CDR mechanism to report what calls have been made and then filter for those calls that would be billable, see https://vodia.com/doc/cdr for the possible ways to report the CDR. The most simple way of getting it done could be writing the CDR to a file.

Hmm as far as I remember our compilation engine should be on the latest. At least we have upgraded the browser to the latest. We can check on Monday.

Right now it is checked regardless of who is trying to set it. We regularly run in the same problem on our test systems. In theory what we could do is check if the session belongs to a admin and then skip the check. Interestingly nobody else complained about it yet.

We try to keep the templates up to date for most phones that are in the market. If there is a phone that you would like to see, well just let us know. Alternatively you can make a template yourself, we have added the description for that recently to the documentation: https://vodia.com/doc/pnp_template

Yes. Use a space character to separate the destinations. They are independent. You can use this to have some kind of "redundancy", or to use different schemes at the same time, e.g. send into MongoDG and into a CSV file. You can set this up on domain level and system level. If you use the domain level, then this will "filter" only for that domain. But we don't have any other filters.

Next version will have it.

We can add a logic parallel to the user call back that calls a list numbers if the message was not retrieved. That should not be too hard, given the fact that we already have the logic that deals with the user's cell phones.

You could use the cell phone callback to deliver the voicemail. It will try to deliver the voicemail a couple of times, I think that comes close. We could add a function that shoots out an email if the delivery failed.

Yes it is. You need to be logged in, then there will be a link where you can add it. If you need help, send an email to sales and they will take care about it.

That will be quite difficult. The Vodia PBX has the support for an external voicemail system, but this was primarily done for Microsoft Exchange. Then Exchange would take care about notifying the user, e.g. through email. If you want to notify the user's phone with a MWI subscription, that subscription would have to be sent to the external Asterisk, which would mean that you need to share usernames and password with the external system and you would have to have the phone subscribe to another address that where the phone registers (I am not aware about a phone that supports that). Why would you want to do that?

The mailbox plays the language of the caller, not the languages of the called person. That can be confusing, but makes sense: The one who leaves the message needs to understand the announcements.

You don't have to make a backup from the web interface. The easiest way to upgrade is like this: Make a backup of your current 4.5 PBX working directory, including the PBX executable Log in to the PBX web interface and do a software upgrade e.g. with the link http://vodia.com/downloads/pbx/version-56.0.xml Try rebooting the system, if it comes up with 56.0 you are all set Otherwise take the software upgrade XML link, and manually download the .dat file and the right executable for your server, put them into the working directory of the PBX, rename them to pbxctrl.exe (Windows) or pbxctrl (others) and pbxctrl.dat, make sure that the pbxctrl is executable (chmod a+rx pbxctrl). If the old installation was using the name snomONE make a symbolic link so that the snomONE points to pbxctrl (ln -s snomONE pbxctrl). Alternatively, you must edit the startup file in /etc/init.d and change the executable name there. The other way to upgrade is to make a new installation and then copy over the data from the 4.5 installation, but without the pbxctrl or pbxctrl.exe file and restart the service. If you have only the tar file from the backup, you can un-tar it from the command line. This will also give you a backup of the working directory.

Well the logic is indeed very hard to understand. The best way to see what happens is to look at the service flags list in the domain account view, it contains the current state of the flags. We have flipped the text in the HTML I think like a year ago, not sure if the 5.5.6 was already affected.

Ja. Das Thema lautet "Anklopfen" (Call Waiting). E gibt bei den Einstellungen für den Nebenstellen unter Verschiedenes das Setting "Anklopfen erlauben", wenn das ausgeschaltet ist wird die PBX nicht mehr anklopfen. Das hat allerdings zur Folge dass Anklopfen wirklich nicht mehr geht, auch nicht auf dem Gerät wo gerade gesprochen wird.