Vodia PBX

C is for "user must enter a client matter code for this outbound call", P is for "user must enter his PIN code for this outbound call".

When the phone seizes a shared line for outbound calls but it turns out the call is internally, the PBX did not release the line immeidately (only after the 60 second timeout).

There are other products that use STUN to allocate a public IP address automatically. Good luck with that... We had STUN in the first version and it was simply a cash cow for support calls. A PBX is a server and it must run on routable IP addresses. All kinds of workaround just create a lot of work and a lot of grief, especially when it turns out things are not 100 % stable. However, I agree we should have more documentation about this. Use cases and templates on how a PBX can be installed in an office enviroment and the pro/cons of not having a routable address for the service.

The topic was probably moved into another section; in this case maybe the CDR forum. We try to sort the topics into the folders that match best (especially those in the General Setup section). This should make searching easier. Usually you can reference the post with the topic number. Then it does not matter in which folder it was moved.

Yes (you can specify multiple email addresses by using semicolons, for example "fred@domain1.com; carl@omain2.com"). That is a known bug.

Well, just set the 2nd account to the name of the 2nd domain. I prefer the usage of the outbound proxy, in this case then you don't need to set up a DNS entry for the domain. Generally speaking, using a IP address as a domain name is not a good choice if you want to have more than one domain on tha tsame IP address. You must choose a DNS name for the domain, that's the way it works in SIP (that is where the name "domain" is coming from, after all an explanation why we picked this name and not tenant). Web hosting works pretty much the same way.

I guess the CDR directory also does not show any change... Is there any other hint the call went through the/this PBX? Do you see the SIP traffic for the calls in the log of the PBX? Is this for extension to extension calls maybe? The call history (in version 4) shows the trunk calls, not the extension calls.

You can have a list of service flags and a list of destinations like this: Flags: 123 #R 124 Destination: 456 457 458 Then when flag 123 fires, the redirection goes to 456, else when flag #R fires, the redirection goes to 457, else when flag 124 fires, the redirection goes to 458.

A known problem is that when you send the email multiple times, the delete action already happens on the first emails.

There is still a problem with the compilation. FreeBSD is not Linux!

Is that a problem with the Polycom phone or the service provider? The PBX is a B2BUA, so it does not really matter what the Polycom sends when the INVITE goes out to the service provider. I know we have some customers using Level 3; there must be a way to set up the trunk so they eat it.

Those who can deal with bash, sed & Co can save a lot of time! For large installations, that can really make sense.

This is a flaw in the default config. We need to change this.

Unfortunately, certificates are very complicated... Yea, the good old Wiki! I still don't understand why we had to turn it off.

At least someone barged into my call yesterday. But I believe this was on G.711. G.729 works if the jitter is not too much. Unfortunately, in hosted mode that assumption is not always true... We need to add a jitter buffer for these features; something we don't want to do in 4 as it would screw a lot of the media subsystem up and that is the last thing we want right now!

You mean the phone displays "Bad Request"? Can you see that also in the SIP log of the phone? Is there anything between the phone and the PBX (e.g. a SIP-aware firewall)?

Hehe. This is "just" another Linux distribution. In other words, you need to log in, copy the new executable into the file system, change permissions and then give it a quick try. We are building the latest versions (4.0.1) also for sipjack, and that should be the best ever!

Yea, this typically happens when systems get upgraded and the new version have feature codes that were not present in the old system. We don't automatically fill the gaps because they might overlap with speed dial entries and we want to make sure the upgrade does not screw anything up. If you want to use the new codes, you have to log into the domain admin mode and manually add them.

By default it comes with a self-signed certificate. I believe it might even have expired... In version 4, you can load a certificate either globalls or for a specific domain. If you want to load a domain certificate, then the client must support the TLS extension that tells the PBX which domain the request goes to. So if you have just one domain, it is problably easier to just load a global certificate. With the certificate you must also load the private key. The certificate may contain a certificate chain; so that you include the certificate that the PBX should use for encryption, but also the other certificates that signed the certificate. For example, if you buy a certificate from Verisign, then you can include the Root CA from Verisign (which practically everybody trusts), maybe some intermediate certificates and finally the certificate of the PBX. Everything in this ----BEGIN---- base64-encoded form.

It essentially works like a service flag. But in difference to a service flag, the event that triggers it is the registration status not a time event. So where you would put the service flag account number (e.g. "123") you would put the "#R".

Very strange... Does hitting F5 (reload, clear the cache) make a difference? What if you look at it from another computer?

Windows 2000 does not support IPv6. You should use Windows Server 2008 or Vista or Windows 7.

Well, it is not in the web interface yet... Therefore, the hack with editing the XML file.

There is a setting called "readpos" in the ACD settings (check the XML in the file system). If it is set to true, then the PBX starts reading out the position. This feature is available in version 4. Not sure why it is not available in the web interface. Maybe change it in the XML, restart if you can and then see if it does what you want.

Did you set the list of agents that are allowed to login into the ACD? I assume the feature codes are not changed in the domain settings. Maybe attach a screen shot of the ACD web page here so we can take a quick look.