Welcome to Ask the Experts, brought to you by CloudServicesUniversity.com. In this video, Intelisys’ SVP Cloud Transformation Andrew Pryfogle discusses four potential pitfalls to avoid when moving SIP trunking over public IP transport with IntelePeer’s Peter Neal. Learn more about business communications from the IntelePeer team here: https://cloudservicesuniversity.com/supplier-directory/intelepeer/
| Andrew: | All right guys. We’re into our next Ask the Experts session. We’ve been talking about SIP trunking, and now we want to bring in a real expert on the subject. And that’s Peter Neal, who’s Senior Sales Engineer for IntelePeer, one of our go-to suppliers for SIP trunking. Peter, welcome. |
| Peter: | Thank you very much. It’s a pleasure. |
| Andrew: | All right. You’ve been at this game a long time, and you understand SIP trunking really, really well. I wanted to ask you in this segment one simple question. There’s this huge trend towards moving SIP trunking over public IP transport. And for a long, long time I used to teach hundreds of people, “Don’t put your voice traffic over the public internet. It was never designed for public internet. It’s going to have lots of problems.” And in fact, for a long time that was true. It feels like that is starting to change, though. I wanted to get your opinion. Putting SIP traffic over the top of a public internet connection. Good idea, bad idea? How can you leverage it without taking on huge risks? What are your thoughts? |
| Peter: | Well, I would agree with you. Four or five years ago I would have shied away from recommending that to anybody. The whole idea of convergence though has really taken over in the industry. As you said, it used to be you’d put your voice on your data access loop, manage it that way. But to my mind the evolution of the public IP infrastructure over the last four or five years has really taken us to a place where public IP services are better suited than they’ve ever been for carrying latency-sensitive traffic like voice or video. Just like we’re doing in this interaction here, on enterprise customer behalf. |
| Andrew: | Great points. So we’re actually doing that right now as we speak, so it’s a good example. And video quality’s good, voice quality’s good. So it sounds like it’s starting to work … Peering relationships are better. The way this kind of traffic is routed is smarter. Does that mean it’s kind of foolproof? Are we there? Should there be no concerns about routing this over public IP? Are there still some pitfalls to avoid? |
| Peter: | I would say most definitely it is not bulletproof. It becomes a risk versus reward thing. From an IntelePeer standpoint, right now about 98% of our enterprise retail and contact center base is actually using public IP resources to interact with us. Our churn rate is at 1% or less inside of that base. So it would seem to me that it’s proving the old adage incorrect and that it’s actually in a better position now to support it than it ever was. |
| Andrew: | 98% of your customers are opting to do this over public IP even though they have the option to do this over private IP if they wanted to. Is that true? |
| Peter: | Absolutely correct. We support ethernet private line connectivity. There are some enterprises that from a security standpoint as well as to assuage, you know, potential quality concerns take that methodology. But again, I think the proof’s in the pudding as far as our customer interaction goes. |
| Andrew: | Yeah, no doubt. And that kind of churn rate is remarkable. I think it is great evidence. So what would you say, based in your experience–again, you’ve been at this a long time–what are the three or four things that a customer ought to do if they’re going to put this over the public IP? What are some things they can do to make sure they have a great experience? |
| Peter: | I would really call it into four buckets. The first thing is to look at the type of access that you’re using in the first place. What you want to do is shy away from services that were meant to be over-subscribed that aggregate TCP traffic–regular data, non-voice traffic. Where if a packet drops because of over conscription, it gets re-sent; no harm, no foul. The voice world, they utilize UDP for the packet delivery. It’s asynchronous; it’s one way; it does not resend. So you want to avoid the DSL’s, the business cables. Any kind of connectivity where you don’t have synchronous up and down speeds is immediately suspect. It may be good as a backup or a failover, but a solid synchronous link from a good Tier 1 or Tier 2 carrier is going to be the way to go from an enterprise standpoint. |
| Andrew: | Got it, okay. So number one would be making sure that you’re using a Tier 1, Tier 2 provider with synchronous bandwidth, up and download speeds are the same. That’s a great one. What’s the number two? |
| Peter: | Number two would be the idea that you can’t put ten pounds of sand in a five-pound bag. Have your existing ISP run peak utilization stats for you on your non-voice traffic. So if I have a 100 meg circuit, and I’m at 95 meg at peak, that’s going to tell me how much voice I can overlay on top of that without all of a sudden making that network be congested, where packets will drop. So you really want to know how many simultaneous calls do you have, what’s the sampling rate you’re going to use for that call, and do you have the bandwidth on that circuit to support it. That’s huge. |
| Andrew: | Got it. That makes a lot of sense. So really look at those busy hour studies and determine what your traffic is at its peak. Not at just a normal hour but at its peak, and then engineer around that. Got it, got it. What’s the next one? |
| Peter: | We’ve seen this as a big trend within the last seven or eight months. Don’t rely on a single ISP from a circuit standpoint. Avoiding any kind of single-threaded access allows you to control your own destiny as a customer to a greater degree than before. And again the cost for bandwidth have come down so incredibly decently over the last four or five years; you can pursue this without breaking the bank. What we’re seeing people do is getting links from either one or more Tier 1 or Tier 2 providers, running a protocol like border gateway to link them together, that way you can suffer a primary link failure and still be talking to somebody on the call without it dropping. |
| Andrew: | Makes sense, makes sense. So have disparate links from different providers. The fourth one I’m going to guess. Is that looking more into the core of the network … What if those two disparate providers have the same backhaul provider. Is that also perhaps a faulty design they should avoid? |
| Peter: | Yes. What you find, depending on the enterprise, a lot of people will buy ISP services from regional players who have a regional footprint. If I have a regional footprint, that means I have to utilize a third party to get your packet to areas that are outside of my footprint. We have seen, particularly in the northeast, that people have gotten circuits from two “separate regional providers” but that third party that actually takes those packets across United States, outside of that regional footprint, is the same one. So what you do is you have two separate funnels to the same link, and now you’re single threaded again. |
| Andrew: | Yeah, got it. That’s a really important nuance there that people should be thinking about. Hey, this has been fantastic stuff. Great knowledge, Peter. And those four tips, I think, will help our partners design winning solutions using SIP trunking. And IntelePeer is a great solution for that. Guy, that’s Peter Neal. He’s senior sales engineer for IntelePeer, one of our go-to SIP trunking providers and a member of the Cloud Services University faculty. Peter, thanks for jumping in. This was great stuff. |
| Peter: | My pleasure. I really enjoyed it. |
| Andrew: | All right guys, check out IntelePeer’s learning center and go deep on their stuff. They can help you win big deals in the SIP trunking space. And be on the lookout for more insights from Peter. Great stuff. Everyone, good selling. |
