Vodia PBX

Try using the sort by name feature of the task manager. Maybe the refreshing makes it difficult to find the process. It should have the name pbxctrl. BTW the process set the priority on it's own already. Usually there should be no need to change this.

I think so. Should be easy to find out!

Did you check out the EPID feature? Do you have an example of what the PBX is supposed to do?

If you are offering the service I would not allow customers to change or even see the trunks; not even the dial plans. As a rule of thumb: If your trunk can send out any ANI number in your system; make it global. If you need to register the trunk for each DID, make it a domain trunk. If BroadVox uses the IP address to identify the host, then you can only have one trunk. The problem then will be if they accept several ANI numbers; they have to! Otherwise you could have only one ANI per system. That would limit their revenue potential and they will fix this very quickly!

You are probably hitting the problem that the number that you register with is a telephone number. Then the PBX compares 9254185059 to +19254185059 and finds no match. Try registering +19254185059, that might solve the problem. This is a kind of a bug; we probably have to change this behavior. Workaround is to use the + format for right now.

Yes it is like having two layers. One layer for the phones, and another layer for the agents. If you don't mix them up, it should be clean. And it should also avoid the login.

Well, that means that phone does not accept the call and requests the PBX to send it to another destination. However, the hunt group does not follow redirections. That is a very good and indended feature! If the user set the redirection on the PBX, the behavior would be the same.

Well, that means that phone does not accept the call and requests the PBX to send it to another destination. However, the hunt group does not follow redirections. That is a very good and indended feature! If the user set the redirection on the PBX, the behavior would be the same.

Right. If you have a global trunk, it is able to switch the domain if it finds the telephone number in another domain and send the call there. Make sure that the number has 10 digits, so that the PBX can detect that this is a telephone number. You can also write the telephone number starting with a "+", for example "+19787462777" for (978)747-2777.

Well, the point is that the PBX monitors the calls to an extension independently from the used IP address. For example, when using static registrations, the PBX also does not realize there may be another call going on to that IP address. Same with hot desking. If you send the call to a hot desk phone, the PBX tags this call with the called extension. When you call the hot desk phone directly, it does not have a call active for the original extension number and the call gets put through. If that behavior is a problem, then I would suggest using "agent" extensions and "phone" extensions. For example, you use extensions 4xx for agents, and 5xx for phones. Only 5xx extensions have phones registered, 4xx does not register a phone. Only 4xx extensions are in agent groups. Then when an agent logs in, he or she needs to perform the hot desking in order to log in. The good news is that there is no need to log in as agent any more; hot desking will be enough.

Well, if the phones don't find the PBX then there will be no PnP. You can also turn off the TFTP server by clearing the TFTP port in the Ports section.

This is a complex topic. But yes you can. The domain name "localhost" is used as a wildcard to match all (remaining) domain names. So it you want to have multiple domains, you might have to give up that domain name. That also means that the SIP phones must use the exact domain name (string must match). You cannot address the domain with the IP address string, obviously. On the trunk side, you can have trunks in each domain. That is another complex topic. But you can also have global trunks in a dummy domain that can be used in all dial plans of the domains. You can even have global dial plans.

That is the license server. It performs the online check for the supplied license (depending on the license type). Obviously it was down during that time. mk@felephel:~$ host license.pbxnsip.com license.pbxnsip.com has address 75.150.83.3

Have have switches the wiki pages over to the support web site. While the wiki was a good start, we needed a more flexible system that can have more support people "behind" the web page and switched the document management system. We moved the content of the Wiki into the new system, so all the content should be still available. The forum will stay as it is. Feedback is welcome!

Software engineering is when it works and nobody knows why!

At the moment (version 3), the sharing is for the MWI. The message itself remains in the mailbox that is to be shared. That works; however has the "disadvantage" that probably all SIP phones that I know are not able to subscribe to this MWI in a non-random way. Therefore we have to change this behavior on version 4 and really copy the message into all mailboxes.

The snom phones need some provisoning files in HTTP format. This is because for these cases, the HTTP authentication does not work with HTTPS. Therefore you need to have both HTTP and HTTPS port open.

Hmm. Holding a call to the mailbox raises a question anyway. Typically that happens when the guy that you are calling calls back. Maybe it makes sense to just forget about the mailbox call in this case.

Yes that is absolutely right. We need to update the Wiki!

Well, that does not mean that the registrar is RFC compliant. I don't see why the REGISTER should be a Bad Request. So far the pbxnsip trunk was able to register will all popular SIP providers. Maybe SPS EUT can tell what is bad in the register request... I don't see it.

Not sure, but it seems that this is not the first request that the PBX sends to the provider. I never heared about a server with the name "SPS EUT GW 01", maybe they have written their own little SIP software.

Hard to say. Microsoft is a large organization and they need to generate a lot of revenues with a product like OCS. If I would be a manager in Microsoft, yes I would go for the PBX functionality and try to get this center piece of the market as well. The problem is: the way OCS is designed it will be hard to get some core PBX functionality working. I understand that if you want to serve large companies, you better stay out of the media path. However, the way PBX work is that they are in the media path.

Hehe. Not sure if that is the answer! IMHO we need to see what causes the problems and then look for a workarond. Maybe it has to do with the used HTML standard: I could imagine we have to use something like this: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd> <html xmlns="http://www.w3.org/1999/xhtml>

Well, it is a lot of work. Paperwork. We did the certification with Exchange; it is nice to be listed there. OCS is changing fast. Not sure how much value the certification of an IP-PBX has here.

In the old days when the phone system even came with the cable for the phone, the only risk factor the vendor had was the PSTN lines and the stability of the power supply. You could take the TQM manual from the 1970s and make sure that this system does what is written in the manual (which was of course printed and did not change for years). The good old days! The world of today and the world of interoperability with cell phones, ITSP, VPN and MPLS is different. We don't hold beta images back (like some others do). Yes, that is part of the QA process. It is unrealistic to test all this in the lab; especially because we are open to anything that talks SIP. There are many network environements, operating systems, SIP devices, and user requirements. Beta images are the key to get that stable. For customers it might be better to stay with the release images. I agree; customers usually don't want to be part of the "community". They just want to get their difficult job done. Usually it is better to offer them a workaround than to give them a new image. That's why sending out an email might not be the most beautiful solution; but it will help them to get their job done.