Vodia PBX

First of all, I would suggest to use a audio editor to put these file together so that the PBX does not hop from one account to another... So far. the strategy was to provide one tree for each language path. The PBX was actually not aware about a language in this case, just dumb playback of the WAV files. The trick to have the language stick at the end would be to route the call finally (possibly after pressing a key) into an auto attendant which can set the language. In the next version we'll make a new setting available that makes it possible to explicity specify the language for the call from the IVR node. That would avoid having this workaround.

The only thing that could explain this is that the phone seizes the outbound line when dialling. Then the PBX would restrict the call to that trunk only. Could you check in this direction?

Every call has a field that tells the PBX what language it should play for this call. In the beginning, that field is empty. As soon as the PBX has to play back a message, it needs to make a decision what language to use. Once that decision has been made, the PBX does not change it any more. Exception: The auto attendant may change the language. In other words: When selecting the language for the extension, this will influence the playback when that user calls his/her mailbox. But when someone else uses the mailbox, it will use either the other extensions language (when this is an internal call) or the language for the domain (trunks dont have language settings) or the language that was selected when the call goes through an auto attendant.

Right version 2 and 3 were "okay" if some other process was stealing traffic from important ports like 5060 or 80. We changed that behavior in 4, because yes it might be a pain during startup but later you dont have to scratch your head why not all packets actually make it to your PBX (some get routed to other processes on the same server!).

Right, it times out like a registration. I think it is not generous more like realistic that customers must have the possibity to restore a backup quickly if their PBX host catches fire and they need to resume service. Well, in such a case the admin is the one who does it! Also it is not so easy to really detect the situation. For example, when the public IP address changes every day, you dont want an email about this.

Yes, that is really very strange. The same dial plan returns different results for the same input. So again, it makes a difference if you dial via the speed dial or directly from the phone? If that is reproducable, any clue from the SIP packets (INVITE)? Maybe there is a local dial plan on the phone that could cause this. Do you have multiple identities on that phone? Did you try the dial plan simulator (at the botton of the dial plan web page)?

Are you using a country code in the domain? That might cause problems if you are dialling non-telephone numbers.

AFAIK yes.

"192.168.1.0" with 24 bits would the okay here.

You can activate it from another server. But then you cannot use it on the previous server any more (obviously). We intend to support two cases: Changing public IP addresses for PBX behind firewalls and hardware failover when customers loose one box and need to resume service on another one. The license activcation should minimize the problems getting it working. However if the same activcation key is used in multiple locations, the activation key would obviously eventually get invalid. As per the license agreement, the license is valid only for one site.

Right, for SIP sockets the PBX should use the right socket; however for TFTP it is a bit tricky because TFTP requests that the respones must be sent from another socket, so that the PBX essentially asks the OS what local IP address that socket would use. That's where it essentially asks the OS for the local address on an unbound socket. For configuration data that would be a kind of problem; especially if you plan to run several instances one for each IP address (multiple cores).

I would make sure they are all running the same firmware version.

Well, this one should work! There is something fishy here. Maybe some "invisible" characters here like a space?

CentOS32 http://pbxnsip.com/protect/beta/centos32/pbxctrl-centos5-4.2.0.3966 CentOS64 http://pbxnsip.com/protect/beta/centos64/pbxctrl-centos5-4.2.0.3966 CentOS32 http://pbxnsip.com/snomone/beta/centos32/pbxctrl-centos5-2011-4.2.0.3966 CentOS64 http://pbxnsip.com/snomone/beta/centos64/pbxctrl-centos5-2011-4.2.0.3966

This is not directly accessible. But you can use the trick in http://kiwi.pbxnsip.com/index.php/Global_Configuration_File to write the setting without restarting the service.

There is also canonical format for ROW. International numbers (outside of 0032) are represented in 00xxxx format, national numbers in the format 0xxxx. If you set the domain code, you also get numbrs without 0 prefix for local calls. This number is put into the dial plan. You can see what is fed into the dial plan on log level 9. That is very useful to debug problems like the one that we have here.

Not sure if the keep alive is the problem here... There was two-way media obviously, for about 17 seconds. Dropping the call at that time is very unusual. Can you try another service provider or a PSTN gateway so that we can be sure that this is a problem with this service provider? Also, the SIP packets should be in the attachment of the email, they would be of great interest as well.

That sounds like a major problem with the SIP trunk. Are you using a PSTN gateway or a SIP service provider? When does it frop? 30 seconds are typically a sign that there is something wrong with the signaling. If you can, get the SIP messages that the PBX exchanges with the termination device/provider.

That would be what I would be looking at... Other possibilities include the web password for the provisioned user and the SIP password. If it all does not help, factory reset the phone and provision it again.

What OS do you have? There was a fix for BLF recently (withourt knowing the datails), it might be worth an update. We still have the issue with the renewal of the subscription where the phone does not accept CSeq numbers going back after a PBX restart. The the BLF logic should be working fine regardless.

If you have access to the file system check the domains directory. There should be the XML file for the domain, which also contains the username and the password.

It could be that you got a old version. What is the version number (and OS)?

You need to log in with the domain provisioning username and password. As soon as 8xx devices support multiple login accounts we can provision also the user login credentials.

What was the release date of the firmware for the devices?

I believe depending on your version and the event triggering MWI there were problems with the MWI lights. Did you try to update to the L&G?