Vodia PBX

The problem is that once the call hits the "dial plan", the call is considered to be out of the PBX (trunk call). Getting it back in might stir up some new problems (like technically you will have two calls, the RTP will have to run once through the network and back to the PBX) and it will definitevely need a code change. Would it be a possibility to assign an alias name to the hunt group that serves the same purpose? Then the call would just stay inside the system and this can be done today.

Your service povider is probably just using a "naked" SIP proxy (no SBC) and does not change the Call-ID for the SIP call. The PBX must be very careful with such calls, as they can easily create a loop or avalanche and eat up all resources immediately (http://tools.ietf.org/html/rfc5393, paragraph 3 is worth reading). That is why the PBX does not accept looped calls by default. When you allow it, the PBX is "picky" with the proper handling of the From/To tags, they must be used strictly according to the RFC.

Username und Passwort werden über die PBX provisioniert. Das sind die Einstellungen die man bei der Domäne findet (PnP-Einstellungen). Damit hat der Admin Zugriff auf alle Telefone der Domäne ohne dass er sich die Passwörter der einzelnen Nutzer merken muss.

The motivation to provide this feature was to be able to call into PSTN gateways behind NAT, typically for E911 service. The "dial plan" is not the center piece like in Asterisk systems, it is just a description on how to route outbound calls through trunks. If you want to send a call to the hunt group, you would 99.99 % of the cases not even touch the dial plan and jus tkeep the call in the domain,

When using a search engine, you can also include the word "pbxnsip" to narrow the search range down to the PBX (that was the old name for it)

I would not use the word presence. Presence is more like "I am out for lunch" type of information; but what you can see on the PBX is that a user/extension is on a phone call. Of course this only works if the call goes through the PBX. If a user takes the cell phone and (directly) calls someone through the cell phone network, there is no way the PBX could be aware about this. But when the cell phone user makes a call through the PBX (using the DISA service), then the PBX will show that this user is in a call.

The other thing that should not get forgotten is that T.38 can also be run over TCP (or even TLS). This will also be very reliable. At least the Ricoh in our office does that.

Well, now it does not make a difference if the call went to the extension on a SIP phone or on a cell phone. We also added the feature so that users can toggle between their cell phone and their SIP phone. E.g. when you are talking to someone in the office and you feel the need to leave the room, you can put the cell phone button on your SIP device and transfer the call to the cell phone (one push of the button); then later when you are back you can pick the call up from the cell phone and continue on the desktop phone.

Chaining conference rooms is not a good idea. There are a couple of problems with that. First you are piling up delay. That is probably the least problem. Second, you are piling up "noise" as the conference trunk will always be busy and the PBX has no more chance to cut out silent speakers. Unlike real conferences, there is no concept of "ditance" in the PBX conference room, so everyone even breathing will be mixed into conference and this creates to much background noise that the conference will not be fun any more. Third, when you have a large number of conference participants, you need to have some way of moderating who is talking. Otherwise, everyone caughing and putting the call on hold (music on hold from the cell phone provder) will easily disrupt the conference to the degree where this is not fun any more. I would say the max conference participants is somwhere around ten persons. This will be okay for most CPU, so this is not so much a CPU problem, the problem is more on the "application layer".

Maybe this is a misunderstanding. The way SIP works is that the first request gets "challenged" with a 407 response code, but then the PBX will try again with the encrypted password and then it should receive a 200 response code.

I did a very quick research and found only AudioCodes supporting this right now. AC is a great company, but it would make me feel a little bit more comfortable to know that other vendors also support this... Depending on how it exactly works, it could be very simple to implement this also in the PBX.

One of the common problems that we see is that the operating system prefers the private IP address for routing traffic to the public internet. This is typically because it has the higher bandwidth and the OS thinks this is the faster route. You might have experienced the same problem, and the way to fix it is to mingle with the route command. The problem is so bad because incoming TCP connections (HTTP) work beautiful, but UDP (RTP) does not--because it is not connection oriented.

If you run the PBX in the "cloud" jitter is much higher than on CPE, so the virtualization overhead is probably neglectable. But I would be careful that the server is not too virtual, the service provider must not move the VM around from one phsical host to another all the time as this will create major service interruptions for your users. 150 extensions should be okay. The more important number is how many calls you expect. I think the important point here is that you have the option to add more CPU horsepower if you need it (relocate the server on a different physical device if you run short on resources). And you are right, FAX is something important. Apart from using the PBX and T.38 for FAX, you can also consider using HTTPS for the FAX and bypass the whole FAX problem. PAP2 is an option, but I think you can also take a look at AudioCodes and Mediatrix, especially if you are interested inthe HTTP solution.

You can at least use the text-form for the dial plan to speed things up. It is not cascading, but at least if you have a lot of dial plans, it does speed things up.

If you use auto provisioning, you will automatically get SRTP.

There is still the good old "kiwi" available at http://kiwi.pbxnsip.com/index.php/Domain_dial-plans, take a look.

If you dont want to really open the service to the public, consider using a different port than port 5060 and telling your users about it. It just makes attacks 64000 times more difficult. And if you PnP your devices, they get the port number automatically.

You can bind the HTTP port with a settings like this: 192.168.1.2:80 if the private IP address is 192.168.1.2. If you multiple IP addresses that you want to bind to you can list them (seperated by space, for example 192.168.1.2:80 10.10.10.123:8080).

I believe you make life too hard here... Maybe it is just easier to get a VPN-enabled router which does the same job. I have to defend the phone here, it is not a router. Having a WLAN routing functionality here is pushing it a little to far IMHO.

I believe that the automatic detection of extended regular expressions is the problem here. xx[2345678] is not a simple expression, that is why the PBX switches to complex mode. The expression is a valid ERE expression, and it says two digits followed by 2-8, ANYWHERE in the string. The input is in the format user@domain. Maybe you wanted to use this one: ^([0-9][0-9][2-8])@.*

Looks like you have to enter the right password in the trunk settings...

Right now I believe the next step is to provide a software update for the Windows version... A lot of bugs and improvements were done on the m9, so should be on the m9 soft phone.

The 821 supports the option to use a WLAN stick, and then it acts as a router. Maybe this is a way to go... (Sorry this is the PBX support... But I like the idea to use VPN, it might also help settings the QoS bits right inside the VPN tunnel which will give you real QoS for remote users)

The next version will make life easier when ports are blocked. As for right now, I agree this version is bitchy about unavailable ports and you need to fix it either by turning off the other services (especially the LDAP port comes as a big surprise) or manually editing the XML file.

The problem is that the TCP connection does not register anything. Unless something is registered on the connection, the PBX keep the connection alive only for 8 seconds and then disconnects the TCP. Then when it wants to send the 200 Ok, the connection is already gone. In order to solve this problem, we need to give you another version with a fix. Please contact support (private message to pbx_support in this forum will do) to spin you a new build, please indicate the OS that you are using.