Vodia PBX

He should pick it up with *86301 if he wants it only from orbit 301. Or put "*" into the setting "Explicitly specify park orbit preference". Then the PBX will prompt for the orbit on those extensions where you put the "*". So maybe for the one who usually parks the calls put the orbits there, and all others who usually pick calls up put a "*" there.

It should be "dst_start_week_of_month" that is set to "2"... ?!

Yes, you can still put extra files there, but now the name must be snom_320_custom.xml (replace 320 with the model). I guess I should just try to provision a phone in Dutch and see what happens...

Okay, I tried that out here. That setup is what also used and that is what I would also recommend. For me it worked. I had some trouble with the VLAN setup, the Ethernet switch was a little bit bitchy and I forgot to bind the tftp port also on the VLAN interface. But then it worked smoothly. There is one more thing that could be a problem, it is that the phone may need an extra reboot cycle after receiving the VLAN ID.

If you changed your pnp.xml file, check the pnp file in this post for changes. The pnp had to be updated because it was in many cases too easy to get a configuration from any web browser in the LAN or even the WAN. I know this is a pain for many people who had their own pnp.xml file. Of course our intention is that there is no need to have any changes in pnp any more.

At the moment: No. The good news is that we are able to have several prompts, so we need to work only on the assignment of events to prompts. Something we should consider for the next major release.

The call gets disconnected immediately or after a timeout? Sounds like a SIP problem on the trunk side... Can you filter the SIP packets to the IP address of the trunk and attach them here?

You need to have a public IP address to get this working. Set the country code in your domain to "1". Then create a trunk and set the following: Only inbound traffic No outbound proxy Global trunk If you have a DNS name, use that instead of the IP address and put it into the domain (otherwise just give the IP address a try) Then assign the names "511 567123456" as names for the extension/auto attendant. Give it a try. Set log level to 8 and see if the PBX receives any traffic.

What did you put into the outbound proxy, domain, username, account, password? Can you get a REGISTER message from the log?

That looks like a username/password mismatch to me. Make sure that the username is in the format user@domain and the password is really really correct.

Is that the same problem as in http://forum.pbxnsip.com/index.php?showtopic=2282?

Check if the file audio_de/ringback.wav is there. Some service providers are using software that is not able to deal with media when the SIP call is not connected yet. On the trunk there is a settings called "Ringback": try chaning it to "Message 180".

Yea... Hopefully we can release it soon. Testing testing testing!

If you use the 3.3 version of the PBX (see the annoucement forum) then PnP should also work.

Remove the pnp.xml file or merge it with the attached one. pnp.xml

Upgrade to 8.1.3.

We know a couple of SBC; for example the people at ACME packet know pretty well what they are doing. The PBX comes with it's own built in "Mini-SBC", which is not exactly what e.g. the SBC from ACME packet is doing. The SBC that are on the market usually address the needs of a typical carrier. Essentially that is NAT traversal for a large number of subscribers, topology hiding, billing (policy enforcement). Essentially the SBC gives subscribes "dial tone" on a SIP trunk. Which is a great thing! The PBX "Mini-SBC" is pure software and not as scalable as a real (mostly hardware-based SBC). It scales for the registrations that you have on that particular PBX, something around 500-1000 extensions depending on CPU and overall load with calls and so on. The Mini-SBC does not deal with billing; but it cares about keeping the media session alive. That's when a call gets disconnected because the PBX does not receive any media (the famous "one-way audio timeout"). One problem with the carrier-grade SBC is feature transparency. More and more phones do not only use SIP; they also use HTTP and HTTPS to talk to the address book, show what calls are availble for pickup (AJAX and PAC), and maybe one day do stuff like XMPP. I would expect a lot of problems with the SBC and non-standard events on SIP. Maybe REFER works, but dialog-state, check-sync and whatever extensions we are using to provide the features that customers expect from a PBX today might be a headache and we need to explain and justify everything to the SBC vendor. IMHO the PBX belongs from a logical point of view in front of the SBC. The carrier should have a core that deals with the billing on trunks; the PBX acts like a CPE-PBX; it just happens to be located in the colocation to that the customer does not have to run it on his on power circuit. If you want to run 50 PBX you need a SIP proxy, and SER is a good and obvious choice here. If you are running two or three, you can fix a lot of the routing problems with the dial plan. But when you have a farm then the dial plans get so chaotic that you need a central routing instance. Also, billing is a major issue. The CDR that the PBX generates is not what you want to bill! Customers want to see the CDR for the trunks, and the SER is in the best position to generate CDR for this. You probably need a professional billing software, and pbxnsip is more than happy if the billing takes place on the SER. Many (most?) of the clients that we have actually run the PBX on a public IP address. And fortunately most of the clients are savvy enough to close ports like NFS, FTP, and who-knows what ports on the server. The case of TCP SYN attack is tricky; In order to prevent this a regular firewall can make sure that the PBX does not get overloaded with these packets. If you clients have a fixed IP address, you can also white-list them on the PBX, so that all other packets get rejected and the PBX is invisible to the rest of the Internet. Running multiple PBX instances also give you some kind of "no single point of failure". The PBX is supposed to never crash and we take that pretty serious. But if there should be something going wrong, maybe even a hardware failure, then the damage is limited to 1/50 servers = 2 %. Those customers will not be pleased, but the other 98 % will not even notice. If you already have a SBC than that is a good start. If you already have customers that use a "soft phone" with your service, then that's even better. Then you can keep things like they are, and connect the PBX like you would connect a soft phone to your SIP trunking service. I know one case very well where the carrier already had a SIP trunking product and just put the PBX in front of it. That approach made a lot of sense. The PBX service is a true value-add to his existing portfolio. We got a good exposure with SBC - from the "customers" side. We only hear from customers when the carrier does not use a SBC (the cases when the carrier just says "get a public IP or use STUN and try a couple of DSL routers out until it works"). The interop nightmare known from SIP should not happen when a SBC is used! That what SBC are good for. Saying that this project is a piece of cake would set the wrong expectations. I believe the biggest problems are the efficient management of a large customer base (setting up a new domain, deleting a domain, moving a domain), customer support. I think it is okay to just get started and do the steps manually and then write some scripts that perform steps automatically. Customer support is all about plug and play, and the way the CPE setup is organized. We recently gave some deep thougths about failover, and that will also be an issue that needs some scripting to make the failover happen automatically and quick. And the other topic is of course QoS. If you are able to provide the neccessary bandwidth to the customer, your support life will be so much easier. Maybe VLAN on CPE to keep the traffic seperated from the general data traffic. Combined with the whilelist of allowed IP addresses that is a very robust way of providing hosted PBX which is safe against DoS and QoS-Problems.

We have made new builds in the version 3 of the PBX: http://pbxnsip.com/download/pbxctrl-3.3.0.3165.exe (Windows Upgrade) http://pbxnsip.com/download/pbx3.3.0.3165.exe (Windows Full Install) http://pbxnsip.com/download/pbxctrl-freebsd7.0-3.3.0.3165 (FreeBSD 7 32 bit) http://pbxnsip.com/download/pbxctrl-centos5-3.3.0.3165 (CentOS 5.2) http://pbxnsip.com/download/pbxctrl-suse10-3.3.0.3165 (SuSE10, 32 bit) http://pbxnsip.com/download/pbxctrl-rhes4-3.3.0.3165 (RedHat EL4) http://pbxnsip.com/download/pbxctrl-debian4.0-3.3.0.3165 (Debian 4.0) http://pbxnsip.com/download/pbx-darwin9.0-3.3.0.3165.zip (MacOS) http://pbxnsip.com/cs410/update-3.3.0.3165.tgz (CS410) This release has no major changes, just a lot of "smaller" things that we cleaned up or fixed since the 3.2 version. I believe it should be a great version, pretty stable, doing 99 % of what business expect today from an IP-PBX. I know some of you want to see a couple of new features like full video support and attended transfer into anything; we'll do this in a new version 4. Until then it is good to have a stable version 3. Release Notes are as usual at http://wiki.pbxnsip.com/index.php/Release_Notes_3.3. If you are running 3.2 or 3.1, IMHO it should be an easy upgrade. As always, when you upgrade this is a excellent opportunity to back up the working directory before upgrading and store it in a safe place. If you are upgrading from previous versions and you are in North America (country code "1"), make sure that the dial plans use the 10-digit notation. For outbound calls, you can also tell the trunk on how the number should be represented. That seems to be the biggest problem with upgrades so far.

Interesting concept to send the message in the SDP... Though in the meantime people would probably use the MESSAGE method (SIMPLE) or even better XMPP.

I would recommend to use the 3.2 version of the Polycom phones. That is much more recent. Do you have the SIP packets that are exchangd between the phones and the PBX?

The trick with # works on only direct destinations.

Well, 3-way conference should work... Did they try pressing the "conference" button?

From the PBX perspecitve VPN is just like any other network interface. In the setup above, the different netmask raise a question. If you are using snom, why do you want to use VPN? You can as well just connect the phone directly through TLS and SRTP to the PBX. Maybe you can try to set up a laptop with VPN and try to register a softphone first. That is probably a good way to verify that the setup is okay.

If you have a audio cable, you can always connect the headset output to the mic input. It is a very pragmatic solution, but it works...

http://pbxnsip.com/protect/pbxctrl-debian4.0-3.3.0.3163.