Agreed, that SIP/RTP NAT issues are non-issue when you are using a consistent Router such as Mikrotik.
B2BUA (Back to Back user agent, e.g. asterisk to asterisk) has its advantage and also it's own set of issues (typically in Codec Conversion ... STUN or TURN are not necessary either, all depends on the deployment. We don't depoly sip proxy either, we spin small instances (openvz) for each customer, have a scripted install for Freepbx, security etc.. let the phones register to the pbx directly. I strongly disagree about security for the pbx, it is irrelevant if the pbx is hosted or on client premises, security has to be proactive and reactive, static security is not sufficient, I believe it is less work maintaining a number of VPS vs a number of distributed hardware devices located at multiple client premises. As to the question of Hosted vs On-Premise, the right answer has to do with what I call external factors... e.g. in our neck of the woods, travel time is a significant factor, and cost of professional labor is high... being able to manage VPS, provisioning, backup, etc etc (we do all of this remotely from our office on machines located at the Data Center), we are able to do things much more efficiently than dealing with travel time and running around town. (Heck, only today, I turned up two new extension, one in Oklahoma, and another in Tennessee, for a Client based out of Carmel,IN, with local DID's, and these two extension are ready to be in service for tomorrow's business day !) I will agree with you that, having an on-premise pbx is advantageous when there is an internet outage (local ext. to ext calls work), this is the reason why most of our implementations have dual internet connections (which is easier for us to do in our neck of the woods), thus the hosted solution offering being more advantageous, (most folks are also carrying Cell Phones, and heavily utilize failover to cell in case of an outage). The flip side is, that if the hosted pbx is in the Data Center with redundant internet, it does not go down in case of internet outage the calls get directed to VM, or forwarded to Cell. Which is not true in-case of onsite pbx. I believe that Service Providers, need to learn how to deal with Voice on their network, and offer voice services to their customers, when done properly, it is most likely to be the MOST PROFITABLE service. If not done properly, it can be the biggest headache. SIP, Voice are mature and accepted Technologies, customers are receptive to it, and philosophically speaking I like to keep consistent with the Service Provider mentality... vs Hardware Sales mentality.... When we can offer anything as a service for recurring revenue, Why would we want to settle for a one time revenue from Hardware Sale and Integration ? I agree with you, that this is 75% NSP Business Owner philosophy, and about 25% actual Tech reasoning. I am glad to have this discussion on the list, hopefully this will get folk to consider / re-consider their position on offering Voice Services.. :) 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 ----- Original Message ----- > From: "Nathan Anderson" <nath...@fsr.com> > To: "WISPA General List" <wireless@wispa.org> > Sent: Wednesday, May 14, 2014 9:39:39 PM > Subject: Re: [WISPA] Small IP PBX - Grandstream UCM > > 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 > _______________________________________________ Wireless mailing list Wireless@wispa.org http://lists.wispa.org/mailman/listinfo/wireless
