SIP Trunking v. PRI

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.

-nick

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.

Guru Guide: CVOICE (IOS Gateways)

I have a confession to make: I love gateways and gatekeepers. There’s something about diving into the command line that appeals to my personality. The black of the terminal… The blinking white cursor…

Truth be told, I didn’t always enjoy gateways. They were difficult to wrap my head around at first, but now they’re a piece of cake. I used to enjoy MGCP gateways for the ease of configuration, but now H.323 is my preferred method. Yes, there is a great deal more configuration when running H.323 or SIP, but you have much more control.

And control is something we engineers like to have (and keep)!

If you’re studying for the CVOICE lab or just generally interested in a concise reference on basic commands and theory surrounding gateways and gatekeepers, refer to this “Guru Guide” below. Read the rest of this entry »

CUCME SIP Phone Re-Registers Intermittently

Problem: After configuring SIP-based CUCME, I noticed that my SIP phones would intermittently re-register.  The phone would also be non-responsive when I tried to initiate outbound calls. Ironically, though, was that the SIP phones could receive calls.  During the troubleshooting phase, I tried everything I could think of.  I even made sure that the firmware on the SIP phone was the version explicitly stated in the CUCME Admin Guide.

Debugs: I ran the following debugs to gather logs: debug voice register events, debug voice register errors, debug ccsip message, debug ccsip info.  Based on the debugs, this is what I was seeing:

Resolution: Based on the logs, the phone was never receiving the 401 challenge to the register refresh request.  To correct this issue, I bound the SIP signaling to the interface used as the source address under voice register global.  In my case, this was Vlan400:

Conf t
Voice service voip
Sip
Bind control source-interface VLAN400
Bind media source-interface VLAN400
End

The phone has been stable and the registration refreshes successfully.

It seemed the phone was not receiving the 401 challenge to the register refresh.  Due to this the phone was resending the register without authentication information and the CUCME would again reject the request.  This process would repeat until registration timed out and the CUCME closed the TCP connection.  At this point the phone would reset and would successfully register.

IOS Dial-Peer Destination-Pattern Commands

Below are the following destination-pattern operators that can be used in IOS dial-peers for voice:

Standard Operators

• Asterisk (*) and pound sign (#)—Keys that appear on standard touchtone dial pads.
• Brackets ([ ])—Range of digits. Digits (0 to 9) are enclosed in brackets. Similar to a regular expression rule.
• Parentheses (( ))—Define specific pattern. Same as the regular expression rule—for example, 408(555). Use parentheses in conjunction with symbols ? or %.
• Period (.)—Match to any entered digit (used as a wildcard).
• Comma (,)—Pause between digits.

“Repeating” Operators

• Percent sign (%)—The previous digit or pattern zero or multiple times, similar to wildcard usage in the regular expression.
• Question mark (?)—The previous digit occurred zero or one time.

Other Operators

• Circumflex (^)—Match to the beginning of the string.
• Dollar sign ($)—Match to the null string at the end of the input string.
• Backslash (\)—Is followed by a single character matching that character or used with a single  character having no other significance (matching that character).
• T—Control character indicating that the destination-pattern value is a variable-length dial string.

Sample CUCME SIP Configuration

This post attempts to lay out the basic commands needed for a functional CUCME SIP system.  I pulled this configuration off a Cisco TechNote and added my comments inline in red.  For those of you following my blog and also studying for the lab, do you see any commands that may be missing?

Read the rest of this entry »