Working around NAT issues with SIP and RTP has little-to-nothing to do with whether the PBX lives "in the cloud" or is a local piece of hardware. We do not (at this time) do hosted PBX ourselves, and NAT is generally not a problem.
Our strategy isn't even to use something like STUN or TURN. It is simply to employ a B2BUA architecture, where both the SIP and RTP traffic is always guaranteed to come from a single IP, the same one that the customer phone or PBX initiated communication with when it registered itself to our SIP+RTP proxy (and we require SIP registration and don't offer static IP authentication as an option). We also use a low SIP registration expiration timer. That way the necessary port mappings are already in the NAT router's connection tracking table, so when an unsolicited SIP message hits their router, it gets sent to the right place, and those entries in the table are constantly getting refreshed. It probably doesn't hurt that in many cases, we also end up selling the customer a router that actually has a decent SIP ALG implementation (MikroTik/Linux). But I've found that even with the ALG turned off, everything still works fine. Security of a local PBX is also relatively straightforward. DO put the PBX behind a NAT, and DON'T create any static port forwards to it on the NAT router. Just let NAT/conntrack and the ALG do their jobs. Then unsolicited SIP traffic coming from hosts other than your own SIP proxy will never reach their PBX. Any attacker would first have to compromise the NAT router, and if they didn't have any reason to believe that you were running an IP PBX behind it anyway (and why would they if external scans never generated a response to a SIP message?), they would have no reason to go to the trouble of attempting to break into the router in order to gain access to the PBX, unless they were targeting your organization specifically (so, a person who had a beef with you/your customer, and not some automated bot spewing SIP INVITEs to thousands of public IPs). I am personally not a fan of the whole hosted PBX craze myself, although we may eventually feel the pressure of coming out with a product like that for our customers if the demand becomes such that we can no longer ignore it. I don't really get why people want it or where the benefit is. I think most people just have it in their heads that if they pay "per port" for a hosted solution, that method of pricing service has some inherent cost-savings built into it. That, and they think that having the PBX "in the cloud" rather than local means that it's one less piece of gear for them to maintain. But there is nothing preventing somebody (like the provider) from selling or renting the end-user a piece of hardware and also maintaining it for them remotely. The end result is the same: the customer doesn't have to worry about it. The huge downside I see with hosted PBX is that if the internet connection goes down or the cloud PBX becomes unreachable for some other reason, then all the phones that happen to be in the same building and connected to the same LAN don't work at all, even for, say, local phone-to-phone intercom calling in the same building, or group paging, or what-have-you. If you tried to sell a business individual internet connections for each computer in their organization, where all of the computers would have to go through the internet in order to exchange data with each other, people would think you are nuts. So why are people so eager to sell (and buy) phone service that works on the same principle? But I digress. -- Nathan Anderson First Step Internet, LLC nath...@fsr.com -----Original Message----- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Faisal Imtiaz Sent: Wednesday, May 14, 2014 4:32 PM To: WISPA General List Subject: Re: [WISPA] Small IP PBX - Grandstream UCM We find it easier to manage nat/routing issues via a hosted pbx. (Pbx is hosted on a Virtual Server VPS at the DataCenter) Using Mikrotik's as client routers (managed router service) is very practical. Setting up Dual ISP with Failover is a bit daunting task, however.... if you follow this, recipe to get it done.. http://mum.mikrotik.com/presentations/US12/tomas.pdf Plus it is my opinion, that it is easier to manage / monitor / secure the PBX at the datacenter than one at client site. Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 Help-desk: (305)663-5518 Option 2 or Email: supp...@snappytelecom.net ________________________________ From: "Chris Fabien" <ch...@lakenetmi.com> To: "WISPA General List" <wireless@wispa.org> Sent: Wednesday, May 14, 2014 1:29:14 PM Subject: Re: [WISPA] Small IP PBX - Grandstream UCM It seems like a box on site would make routing/nat issues easier to manage especially for customers who may not have our Internet or want to keep a second internet provider for redundancy. It seems like a bunch of ip phones behind nat connecting up to our switch or a hosted solution would be problematic. If you have a suggestion on a solid solution i'm all ears, want to learn whats available and how others are doing this. On May 14, 2014 1:21 PM, "Faisal Imtiaz" <fai...@snappytelecom.net> wrote: Why do you want to put a 'box' on-site ? Why not hosted PBX, and have IP Phones ? Regards. Faisal Imtiaz Snappy Internet & Telecom 7266 SW 48 Street Miami, FL 33155 Tel: 305 663 5518 x 232 <tel:305%20663%205518%20x%20232> Help-desk: (305)663-5518 <tel:%28305%29663-5518> Option 2 or Email: supp...@snappytelecom.net ________________________________ From: "Chris Fabien" <ch...@lakenetmi.com> To: "WISPA General List" <wireless@wispa.org> Sent: Tuesday, May 13, 2014 11:40:10 PM Subject: [WISPA] Small IP PBX - Grandstream UCM Anyone tried out this Grandstream IP PBX? Looking for a low cost option we can use for small businesses with 4-8 phones. Also need to redo our office phones so I have a nice chance to try out a new product before selling one to a customer. Any suggestions other than the grandstream are welcome too. _______________________________________________ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless _______________________________________________ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless _______________________________________________ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless _______________________________________________ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
