I'm beginning the process in looking at SIP trunking providers to replace my current E1/T1 circuits. My Avaya environment is global with core hubs in the major regions with LSP sites off of those and was hoping to deploy a centralized strategy if possible. May not be possible in some of the countries, I understand. Our current trunking is provided by the big carriers.. ex. BT, Colt, AT&T. Anyone have any recommendations on finding/selecting a provider? I've heard various things about the large carriers vs the boutique level providers, so I'm looking for anything to get started.
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations John Tel on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
SIP Trunking
- Thread starter trilogy8
- Start date
- Thread starter
- #3
- Thread starter
- #4
I've started the deep dive process with the carriers on their SIP offerings. I'm struggling on a few things and am wondering if I should consider a consulting service for this discover process. 2 of the large carriers (att/Verizon) indicate delivering over MPLS instead of Internet, which makes sense. However, the one item I am really struggling with is the SIP service having to run over the same carrier transport. If those carriers are not my current MPLS providers I'm basically either having to install a totally new and separate voice MPLS network or replace the current carriers with the one I choose for SIP. That's not how I understood this platform should work. I was under the thought that you can subscribe with a SIP provider who can deliver the service via many different underlying transport carriers and be able to peer between them.
Not really. At the end of the day, you're subscribing to an interface on their SBC that they set up just for you with your phone numbers.
Its up to you on how to get there. If that means some carrier has internet facing trunks, then use whatever WAN you want. Other carriers refuse to take on responsibility for the "end to end" service without guaranteeing delivery to the customer premise - that's more like you being told "to use my SIP trunks, you have to buy a MPLS from my SBC to your house. Instead of delivering you DS1 on a wire, I deliver you SIP on a wire". They'd probably be a bit more expensive and it'd be a good cost exercise to know what the extra price tag is to have that guarantee.
Its up to you on how to get there. If that means some carrier has internet facing trunks, then use whatever WAN you want. Other carriers refuse to take on responsibility for the "end to end" service without guaranteeing delivery to the customer premise - that's more like you being told "to use my SIP trunks, you have to buy a MPLS from my SBC to your house. Instead of delivering you DS1 on a wire, I deliver you SIP on a wire". They'd probably be a bit more expensive and it'd be a good cost exercise to know what the extra price tag is to have that guarantee.
DAVIDPAYNE
IS-IT--Management
Not sure I understand you issue.
We currently use Verizon SIP using MPLS. We only have 2 site that them MPLS hits, Our Primary and ESS locations. all inbound voice traffic rides over our SIP trunks into ether of those locations and will be routed to other locations across our WAN (which is not part of that MPLS).
We currently use Verizon SIP using MPLS. We only have 2 site that them MPLS hits, Our Primary and ESS locations. all inbound voice traffic rides over our SIP trunks into ether of those locations and will be routed to other locations across our WAN (which is not part of that MPLS).
- Thread starter
- #7
My problem is we already have dual MPLS in our primary and secondary datacenters which we'd ideally like to use for the voice as well. They are from 2 different carriers and the hope would be to select a SIP provider than can deliver to each of those MPLS providers. From the meeting with att that's not something they support and not sure if that's going to be the case with all providers.
I recommend Level 3 now CenturyLink the platform is call CCS RACC. We have DMARKS at colo locations and provide transport layer ourselves. The RACC platform web portal gives me control over porting, percent allocation, CDR, announcements, IVR, call recording, etc... I can change destination of TFN/TN traffic to any SIP trunk nationwide with a click of a button and a 5 min cache refresh rate. I even tied cloud 3rd party application via SIP trunks to RACC with web api transferring between sites.
jimbojimbo
Vendor
EMEA you may want to look at Verizon or Orange.
APAC you may want to look at Masergy or OneStream
South America you may want to look at Verizon or OneStream. Be very specific when you ask questions with Verizon and get the answers in writing.
NOTE: don't forget number portability may be non-existent in many countries. Be prepared to provide a local gateway and DS1 connection for local trunks if you must maintain the current DID ranges. DO NOT BELIEVE WHAT YOUR CARRIER TELLS YOU. VERIFY NUMBER PORTABILITY.
Verify carrier presence in ALL the countries you need.
Getting existing number ranges from carriers overseas can be like pulling teeth. Even your selected carrier is going to tell you they need you to provide the information.
Look at Special Applications
SA8608
SA8911
SA9065
SA9115
SA9122 (Specifically for India)
APAC you may want to look at Masergy or OneStream
South America you may want to look at Verizon or OneStream. Be very specific when you ask questions with Verizon and get the answers in writing.
NOTE: don't forget number portability may be non-existent in many countries. Be prepared to provide a local gateway and DS1 connection for local trunks if you must maintain the current DID ranges. DO NOT BELIEVE WHAT YOUR CARRIER TELLS YOU. VERIFY NUMBER PORTABILITY.
Verify carrier presence in ALL the countries you need.
Getting existing number ranges from carriers overseas can be like pulling teeth. Even your selected carrier is going to tell you they need you to provide the information.
Look at Special Applications
SA8608
SA8911
SA9065
SA9115
SA9122 (Specifically for India)
- Thread starter
- #10
I did meet with Verizon and my current MPLS network is already with them and I came out of that meeting feeling positive about their offering. We also have MPLS with CenturyLink so they will also be looked at. Thanks for the tips. I know there will be challenges with a centralized model in certain areas, so that's on my radar. With those carriers said, what is the difference between them and a provider such as IntelePeer? The one thing I have also come away a bit concerned about is the DID resiliency. Typically DID's are married to a specific central office. If that central office were to have a disaster it sounded like those DID's would still be impacted, which I was a bit uneasy about. Both carriers tiptoed around the answer.
If your concern is carrier owning RespOrg you might want to look into a 3rd party RespOrg.
- Thread starter
- #12
Getting further along in this process and have another question. What is the ideal end state of a remote branch office? If a centralized model is chosen and you eliminate the local PSTN circuits, what becomes that backup call method? We'd love to rid the branches of hardware altogether, but if that were the case what is the survivability of the site.. SIP clients on the mobile? Our branch sites all have an MPLS circuit and a backup Internet VPN. We block voice from traversing the VPN path and force survivability due to call quality issues.
Depends on the physical facilities.
Is there a case where your MPLS vs backup Internet vs local trunks are delivered in different ways so that the failure of one could be something 'carrier failure on a MPLS router in their core' and not 'some doofus didn't call before he dug and knocked out network to the place'?
How much work can your people get done with only phone and backup internet?
My 'ideal' would be an audiocodes that sip stations can register to and that audiocodes could have analog/pri or register to the SIP carrier over the internet in failover.
I'd be curious to know if a carrier could have 100 locations on central trunking, but have the DID blocks broken out 100 ways with 100 accounts that 100 IPOffices or audiocodes or SIP branch appliances could register to.
Is there a case where your MPLS vs backup Internet vs local trunks are delivered in different ways so that the failure of one could be something 'carrier failure on a MPLS router in their core' and not 'some doofus didn't call before he dug and knocked out network to the place'?
How much work can your people get done with only phone and backup internet?
My 'ideal' would be an audiocodes that sip stations can register to and that audiocodes could have analog/pri or register to the SIP carrier over the internet in failover.
I'd be curious to know if a carrier could have 100 locations on central trunking, but have the DID blocks broken out 100 ways with 100 accounts that 100 IPOffices or audiocodes or SIP branch appliances could register to.
- Thread starter
- #14
In the majority of cases these sites have diverse carriers for all 3, but separate facilities into these sites is another story.
When they do lose the MPLS network at a site, they have pretty much full functionality over the backup Internet VPN. Voice is fine because of the s8300, local voice circuit and DPT etc.. There's just a push find ways of eliminating footprint in the branches. Right now there is only network, voice and security infrastructure. For voice eliminating the GW is fine in a normal condition, but for a MPLS failure there would be nothing as backup. The other school of thought is we have home users with SIP phones that register over the Internet, so why that couldn't be an option. Trying to satisfy the $ people and preserve the redundancy.
When they do lose the MPLS network at a site, they have pretty much full functionality over the backup Internet VPN. Voice is fine because of the s8300, local voice circuit and DPT etc.. There's just a push find ways of eliminating footprint in the branches. Right now there is only network, voice and security infrastructure. For voice eliminating the GW is fine in a normal condition, but for a MPLS failure there would be nothing as backup. The other school of thought is we have home users with SIP phones that register over the Internet, so why that couldn't be an option. Trying to satisfy the $ people and preserve the redundancy.
Maybe use SIP phones and the 3rd point of registration isn't a Branch Session Manager/LSP but the public IP of a SBC as a remote worker over the internet back to your core?
If you have max simultaneous registrations at 2 (for primary and backup data center) and not 3 to include registering through a SBC over the internet, then you would only ever need as many remote worker licenses as you'd need remote workers to support at any given time - to say 100 remote worker licenses would be able to support 20 branches of 50 users each so long as no more than 2 branches are 'down' without MPLS.
Or, maybe have IPOs or Audiocodes register to a backup SIP account over the internet from the branch and have the phones register to that.
It all depends on whether you absolutely require inbound, outbound, CM level features, 911, etc when you're in that failover mode.
If you have max simultaneous registrations at 2 (for primary and backup data center) and not 3 to include registering through a SBC over the internet, then you would only ever need as many remote worker licenses as you'd need remote workers to support at any given time - to say 100 remote worker licenses would be able to support 20 branches of 50 users each so long as no more than 2 branches are 'down' without MPLS.
Or, maybe have IPOs or Audiocodes register to a backup SIP account over the internet from the branch and have the phones register to that.
It all depends on whether you absolutely require inbound, outbound, CM level features, 911, etc when you're in that failover mode.
- Thread starter
- #16
The option of the phone going to the public IP of the SBC was where I was leaning. I'd imagine I'll get questioned about why prevent the voice traffic over the backup Internet VPN, but allow it over the public Internet. These offices are all business folks and would require full telephony access.
I mean, if its the same internet circuit doing VPN, then wouldn't your phones just stay registered to the core at that point?
You could have multiple network paths to the same core - MPLS and VPN, and then maybe a backup to the VPN using an SBC, but if its the same internet circuit, I can't see why you'd want to go to the trouble - just do voice over the VPN. I suppose bandwidth management gets a little trickier when branch 5 at 192.168.5.x has 5Mbps MPLS WAN sunny day and ??? rainy day over a VPN - the SBC could be tweaked to allow different bandwidth when in failover.
Still, you gotta cave somewhere. If you want enterprise features and really need your brdg-appr and hunt groups in WAN failure, then you need a CM there, and if you need trunks and can't go over the internet, then you need gateways and local trunks.
You could have multiple network paths to the same core - MPLS and VPN, and then maybe a backup to the VPN using an SBC, but if its the same internet circuit, I can't see why you'd want to go to the trouble - just do voice over the VPN. I suppose bandwidth management gets a little trickier when branch 5 at 192.168.5.x has 5Mbps MPLS WAN sunny day and ??? rainy day over a VPN - the SBC could be tweaked to allow different bandwidth when in failover.
Still, you gotta cave somewhere. If you want enterprise features and really need your brdg-appr and hunt groups in WAN failure, then you need a CM there, and if you need trunks and can't go over the internet, then you need gateways and local trunks.
- Thread starter
- #18
In the times we've had the voice traffic traversing the VPN there were issues with phones going into discover, for obvious reasons. Then the audio quality would be choppy on internal WAN calls. Wasn't sure if bypassing the VPN was better because of the overhead of the tunnel. There's also an additional hop or 2 in path that wouldn't be present directly over the Internet. Weird because I mention these issues over the VPN, but our remote home users never have issues with the phones.
- Status
