After re-reading what I wrote, I guess I should clarify the following: We have a homegrown SIP-based telephony service that is built on top of Asterisk, but which is emphatically not "hosted PBX". We can provision an account as either a single line (one DID, one SIP registration from an ATA, 2 channels for call-waiting) or a SIP trunk (multiple DIDs, one SIP registration from a PBX, multiple channels), and whether it is a single-line or trunk account, the customer has the option of specifying an emergency call forward number that calls are sent to if either their ATA or PBX goes down for whatever reason, or if our main NOC goes down completely (worse-case scenario where all connectivity and power redundancy utterly fails).
So we are using Asterisk, but we are not using it on our side in our NOC as a PBX in the traditional sense or understanding. We are using it more like a telephony software platform or SDK. If a customer needs a PBX and doesn't have a preference, we will sell them an Asterisk-based one (an Asterisk instance that is configured more traditionally) to live on their premesis, and typically also set up VPN access to it so that we can manage and troubleshoot it remotely. That on-site PBX will get calls sent to it from our Asterisk-based server. We do have enterprise-ish customers that do want BYOPBX, and they successfully peer (via SIP) with our Asterisk server using things like (e.g.) Cisco CallManager/UCM. So I feel that by attacking the voice provisioning problem in the same way that we attack data provisioning, we give customers options and flexibility that allow us to serve customers we would otherwise have to turn away, or who wouldn't even give us a passing glance. -- Nathan Anderson First Step Internet, LLC nath...@fsr.com -----Original Message----- From: wireless-boun...@wispa.org [mailto:wireless-boun...@wispa.org] On Behalf Of Nathan Anderson Sent: Wednesday, May 14, 2014 10:17 PM To: 'WISPA General List' Subject: Re: [WISPA] Small IP PBX - Grandstream UCM Lots to address here. :) Thanks for engaging. By B2BUA, I don't mean "Asterisk to Asterisk." I mean something like Asterisk itself...Asterisk is, by its very nature, a self-contained "back-to-back user agent." That is, it doesn't just forward SIP messages from a proxy or UA upstream. It "pretends" to be both the final endpoint as well as the original calling UA, inserting itself into the middle of the conversation at all levels: it answers the incoming INVITE itself, and then generates a brand-new INVITE with a different ID/sequence number that it sends on, as if the originating INVITE is coming directly from that Asterisk instance. Asterisk also can proxy the RTP audio as well, such that the SDP content in the INVITE points back at itself rather than whatever the originating media gateway is. In a typical SIP switching/proxy architecture, this is just not done...the host that the target UA gets its marching orders from (SIP INVITE, etc.) is not necessarily where the audio stream comes from. It's also not necessarily the same proxy that future SIP messages for that particular session are expected to come from or go to. The RTP media gateway is oftentimes at a completely different IP address. All of this can serve to make the whole scheme very NAT-unfriendly and also makes crafting competent ALGs more tricky than one might assume. So NAT issues can arise even with known-good routers, and my point was not really that we are solving the problem by using "good routers", but that we are trying to eliminate the problem at a different level so that we don't have to care 99% of the time what router a customer is using. Reducing the multitude of IP addresses that are involved in a typical SIP session from the destination UA's perspective down to a single IP plays a huge part i n this. Asterisk is a "B2BUA" in the SIP context not because that's what the authors of Asterisk consciously intended when it came to adding SIP support, but is rather that way by its very nature, because it was written from the ground up to be a technology-agnostic telephone platform, not a SIP-specific platform. Asterisk needs to be able to bridge channels from disparate interfaces and technologoes (TDM to SIP, analog to TDM, etc.). Asterisk treats SIP-to-SIP calls no differently internally than it treats SIP-to-ISDN or analog-to-PRI. The Asterisk core actually has no clue what technologies are behind the two channel legs that it is being asked to bridge together...that all gets abstracted away by the channel drivers. And at its core, Asterisk already knows how to do audio transcoding because it needs to be able to do that in order to fulfill its stated mission, even if it didn't have SIP support at all. In actuality, if all you are dealing with is pure SIP, a B2BUA such as Asterisk i s technically not as efficient from a resources perspective...because it is having to keep track of state information about all of the different active dialogs flowing through it *as well as* bridge and transcode all of the audio channels itself, it can't handle the same kind of call volume that a pure SIP proxy can. But we find it is worth the tradeoff in order to reduce or eliminate NAT headaches, since it's pretty easy and cheap to scale up Asterisk by launching additional instances of it. Hosted PBX solutions are often implemented as B2BUAs on the PBX-in-the-cloud side, which is probably why many people have experientially less NAT problems when using such a service. But the reason that they don't have as many NAT problems is not because it is a "hosted PBX", as if there was something inherent to that concept on the technology side that reduces or eliminates NAT problems...it's because the PBX itself also happens to be a B2BUA in the way I've just been describing. That's what I was getting at. You use FreePBX, which is a layer on top of Asterisk, so it does not surprise me that you are also not finding yourself subject to NAT-related troubles most of the time. I never said that static security was sufficient; I was just trying to point out that the majority of security breaches happen when the PBX is exposed to the public and there is some bot out there systematically trying various extension #s and SIP secret combinations until it hits paydirt. You can mitigate that risk to some extent with rate-limiting or Fail2Ban and such tools, but if, as I suggested, the PBX doesn't have a public IP address in the first place and there are no port forwards in place, then the only way you are getting through to that PBX (or can even tell that there is a PBX there to get through to!) is if there is an exploitable security vulnerability in the NAT implementation itself. By definition, a hosted PBX is directly reachable on the public internet (unless you are using and requiring phones that have built-in VPN clients), whereas the local PBX doesn't have to be (and *shouldn't* be), so you tell me which one is more inherently secure. (Of course, just beca use it is behind a NAT does not mean you can eliminiate active vigilance and policing of the PBX itself, or that you don't need to enforce any additional security policies.) There is also absolutely nothing that prevents us from setting up call forwarding to cell phones or from having a backup voicemail box take calls in the event that our communication with the end-user's PBX is interrupted. Our home-grown platform absolutely allows us to do this, and I'm sure it is not unique in this regard. I agree that ultimately what this comes down to is a business philosophy, but business philosophies can have either a positive or negative impact on the end product and the customer experience. I hear you on trying to avoid truck-rolls to customers, but for the majority of the stuff that you might be asked to do for a customer's PBX if it was on-site, you could do all of those things remotely, just the same as if the PBX was some VM that existed on some public server out there. For example, if a remote client wanted us to turn up a new extension for them with a new local DID, I could do all of that from the comfort of my desk without dispatching anyone, just the same as you. The only thing I can think of that would be an exception to that is hardware failure, which is a real possibility. So what I am hearing is that hosted PBX has all of these supposed benefits, but all of those benefits are ones that favor the provider of the service by making things more convenient for them, an d which doesn't necessarily provide additional value-add for the end-user (and in fact might take away some value, depending on how you look at it). I also agree about looking at it from a service provider perspective, but I guess I disagree with what that actually looks like. Like you, I am not interested in making money by selling hardware. I want to sell service. To me, what that means is selling either a single line of service (e.g., residence using an ATA) or a SIP trunk that peers with a PBX of that user's choice. In either case, what I care about are the recurring monthlies. If the customer doesn't have an ATA or PBX that they are bringing to the table, then we can sell them one and even set it up for them and configure it such that we can get into it remotely to actively manage it for them. This is the *exact same philosophy* that we follow when it comes to internet connectivity: if the customer has a router that they want to use, fine. If they don't, we'll sell them one. If they want us to help with its configuration (either one-time or on an ongoing basis), we can do that, too. But all of that is just to keep t he monthly service revenues coming in. We are simply trying to be consistent in the way that we approach both data and voice services. Treating IP routing one way (local router + LAN) and PSTN routing another (everything is hosted/in the "cloud") just doesn't make sense to me. Again, thanks for the discussion! -- 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 8:54 PM To: WISPA General List Subject: Re: [WISPA] Small IP PBX - Grandstream UCM 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 _______________________________________________ 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
