Below is a response from Nick Matthews on the key things to keep in mind when considering SIP trunking. This is the outflow of a conversation a few of us had on the cisco-voip mailing list.
The cisco-voip list is a great community to be involved in if you work with IP telephony.
SIP trunks can be a blessing or a burden. Things that become important with SIP trunking:
All of your versions and VOIP applications become points of interoperability. With PRI’s, your interop stopped at the PRI. This means contact center applications, voicemail, call control, etc. This even extends out into the provider cloud – sometimes you’ll have interop issues with only certain DIDs or companies on the other side of their network. SIP is open and flexible, which is good and bad. Sometimes the fixes to these problems are complex and require for people like the SIP provider to take action, which you can’t control. You may find your contact center software, call control software, border element software, and provider have differing levels of interoperability flexibility.
Sometimes it is a wash. If you’re worried about survivability at the branch, you can take the money you may save by centralizing the PRIs and use it to get another circuit and router at the site. Now you’ve got higher branch survivability and more bandwidth as well. And if you lose two routers and/or two circuits at the site – you’ve probably got bigger problems. The easy generalization is that you inherit the flexibility of IP networks and get to work with the equipment you’ve invested into the network rather than 20+ year old telephony technology. Since you’ve got increased flexibility, it may be worth it to just flip the calls from the failed site somewhere else until they’ve recovered.
Faxing/911/Modems. Now that your VOIP domain is extended to the SIP cloud, you have to take care to make sure you’re standards based and compliant with the provider. It’s common for people to leave a small percentage of TDM at the branch sites for 911, faxing, and survivability. Expect trouble here.
Many choose to co-reside their SIP provider with their MPLS provider. This prevents having a ‘dumb pipe’ for your SIP traffic with the capability to distort the traffic without a disincentive. Imagine calling your cable modem provider at home and telling them “you’re causing 20% jitter and a 1% loss on my high priority EF traffic”. That being said – the internet is quite significantly more reliable than many expect for carrying SIP traffic. Skype, google voice, and a number of others are prime examples.
That being said – it’s really cool. There are a couple places where it’s just awesome. If you’ve got a remote branch and the only voice offering is a dusty T1 CAS circuit? Forget about that. If you have highly seasonal or even unpredictably bursty traffic, it can be great. If you have a lot of offices where you’ve overprovisioned the phone lines, SIP is a big cost saver. It’s portable, and you are no longer tied down to a single smart jack where your T1 comes in on. When I travel, I register a SIP agent on my cell phone to a HTTP PBX, which registers to a SIP trunk. It’s the exact same concept and architecture that SIP trunking for enterprises build on, but cool-ified.
If SIP is confusing, just think about how an H.323 gateway works. Your CUCM points to an IP address in your network. Now move your gateway out onto the internet. H.323 and SIP are incredibly similar, so just switch the protocol from H.323 to SIP. The last step is to place a Session Border Controller (SBC) or in Cisco’s terms a Cisco Unified Border Element (CUBE). This is basically a voice firewall, and makes sure your signaling and voice stays secure and is manageable. What really happens is that is takes the call, terminates it, and then re-originiates it going outbound. From your CUCM’s perspective – it wouldn’t know whether a PRI or another SIP leg was on the other side.
In my opinion, once you get the hang of how SIP works, the troubleshooting can be simpler too. Call quality problems and resolution can be a pain on TDM circuits – who is to say where the distortion is coming from. With IP, you can easily prove where the distortion is coming from with a sniffer. Ever have to troubleshoot ISDN Q.921 messages? No thank you. It’s a stronger protocol than H.323 – the odd TCP handshake isn’t a problem, it isn’t inhibited by a large specification, and it’s a whole ton easier to read and troubleshoot.
Signaling interoperability problems can be solved by going through the RFCs, which can be muddy and fruitless - Vendor A allows only strictly formed messages and Vendor B refuses to implement such details. Vendor A knowingly doesn’t follow SIP RFC #17, while Vendor B expects compliance. Vendor A is written by a guy in Russia who quit 3 months ago, and Vendor B doesn’t like the way it was written, but Vendor B thinks it’s correct. This was all solved by TDM PRI’s which are essentially the lowest common denominator of voice termination.
Hopefully this gives you an idea. I suppose I’m just full of opinion on this one.
Thanks for your contribution to the community, Nick. It’s this type of mindshare that we need to be forward thinking and leverage the latest technologies to improve the functionality of VoIP in the marketplace.