Many businesses globally – large and small alike – have been converting calls from routing over traditional PSTN carrier trunks – such as E1 & T1 PRI or CAS – to much lower cost, yet still high performance, SIP ITSP (Internet Telephony Service Provider) trunks for years now. INE is no different than your business with regard to this – we have been using SIP trunks in lieu some traditional PSTN calling for years now as well. In fact, in response to a US Federal Communications Commission sub-commitee’s exploration on “PSTN Evolution” in December 2009, a representative from the US carrier AT&T described the traditional circuit-switched PSTN as “relics of a by-gone era”, and said that “Due to technological advances, changes in consumer preference, and market forces, the question is when, not if, POTS service and the PSTN over which it is provided will become obsolete” – source: Reuters [emphasis mine].

The challenge however, becomes that every SIP ITSP carrier has a slightly different way of implementing these sorts of trunks, and each has different provider network equipment that you, the customer, must connect to, and interoperate (properly) with. If you are a large national or multinational business, you may for instance sometimes even connect to two or three different types of provider network equipment, between possibly having multiple contracts with multiple carriers, and even sometimes having to deal with different provider equipment within a single carrier’s network.

Now while you both speak the same agreed upon language (namely SIP), it seems more often than not that you don’t always seem to speak exactly the same dialect of that language. This presents a major challenge in that calls and supplementary services (such as Hold, Resume, Blind Transfer, Semi-Attended Transfer, Fully-Attended Transfer, Forwarding, Faxing, etc) don’t behave as expected, or worse, that some functions don’t work at all.

It is not that SIP isn’t fully mature yet (it will turn 15 years old next year and has been widely used for over 10 years now), or that it is fully standardized and therefore governed by those IETF standards and working groups, it is simply that – as every one of us in the field for any respectable amount of time now knows – not every equipment vendor chooses to implement every single extension and option defined in every IETF RFC for SIP. I mean, have you ever actually looked at how many RFCs there are that deal with not just the core functions, but describe every option and extension to the SIP protocol? There are well over 100 RFCs! Therein lies the problem.

So what are we to do? Cisco Unified Border Element to the rescue! Today we will cover just a few of CUBE’s ability to perform SIP Normalization to allow optimum interoperability with many various SIP ITSPs.

At its base, CUBE consists of allowing both inbound and outbound call legs to be of the type VoIP. Here we first explore a very basic configuration where we have 2 Inbound/Outbound Dial-Peers (depending on which direction the call originates from) To/From the CUCMs in the cluster, and 2 Inbound/Outbound Dial-Peers To/From a fictional AT&T SIP ITSP trunk. We are allowing a codec negotiation and also possibly a DTMF relay internetworking between CUBE and the CUCMs on Dial-Peer’s 101 & 102 (we needed both of these for another utility on this router using the SIP stack), while allowing for the codec of G.729 Annex B on the AT&T carrier side in Dial-Peers 1001 & 1002. We are also load balancing calls between both of the CUCM Subscriber servers and also between both of the SBCs on AT&T’s side that they have given us to peer with. We see this here:

Now what if we have a carrier who wants to see our specific domain name (ine.com) after the @ in the Contact header of a SIP INVITE request message (so 2065011001@ine.com vs. 2065011001@177.1.254.1), possibly for something like compliance with SIP Asserted-Identity? Let’s look at what the SIP INVITE might look like prior to any modification to the above configuration:

So what can CUBE do about this? CUBE can alter the contents of any header in any SIP or SDL header of any request or response (SDL or “Session Description Language” is where things like media, DTMF relay, etc are negotiated – you see a SDL sub-component of the above SIP INVITE message – which is known as a “SIP Early Offer”). So let’s tell CUBE to alter that Contact header of that particular INVITE message, but only out to AT&T. As a preface to our configuration example, it is worth noting that SIP Profiles allow for pattern matching and replacement in a similar (but not exact) method to that of Voice Translation Rules, and like them, are based (loosely) on the GNU SED stream editor. We will use this to match and replace a few possible dynamic values of the string. Like Voice Translation Rules, reference “sets” of matched information in the replacement string with \1 which calls Set 1 from the matched pattern to the replacement pattern. Also like Voice Translation Rules, any part of the string (beginning or end) that we don’t match, passes through to the replacement pattern, unaltered.

There are many other things that the Cisco’s UBE can do for us, and we have only covered one small one here in this article. For a lot more great information on this product check out INE’s Class-on-Demand CCIE Voice Deep Dive for CUBE. By the way, Cisco’s implementation of what others in the industry might label a “SBC” (Session Border Controller), goes far beyond what other industry SBCs are able to offer in terms of both features and scalability (CUBE hardware support ranges from ISRs for SMBs, up through ISR-G2s and ASRs for Enterprises, up to the 12000 series routers for SPs). I will cover many more of the offered features of the CUBE in follow-up postings, so stay tuned!

I will leave you with a great Cisco article describing some basic functionality of CUBE and SIP Normalization, and also a lot of great Cisco configuration examples from live SIP ITSP trunks that Cisco has installed and tested with in their RTP labs, as well as live PBX integrations that they have performed, and subsequently written up these “recommended practice” documents.

About Mark Snow, CCIE #14073:

Mark Snow has been actively working with data and traditional telephony as a Network Consulting Engineer since 1995, and has been working with Cisco Call Manager and voice-over technology since 1998. Mark has been actively teaching and developing content for the CCIE Voice track since 2005, and the Security track since 2007.
Mark's story with both data and voice technology started out quite young, as he began learning around the age of five from his father who was a patented inventor and a research scientist at AT&T Bell Laboratories. Mark started out on Unix System V and basic analog telephony, and went on from there to large data networking projects with technologies such as Banyan Vines, IPX and of course IP, and large phone systems such as Nortel 61c, Tadiran Coral, Avaya Definity and of course Cisco Unified Communications Manager in both enterprise and 911 PSAP environments across the US and internationally.
Mark is also an accomplished pilot and punched his ticket in 2001. When Mark isn't learning, labing, consulting or teaching, he can be found either piloting or possibly jumping out of a perfectly good airplane, hanging off a rock somewhere or else skiing out west. He also might just be enjoying a quiet day at the beach with his wife and two wonderful young kids, Ryleigh and Judah.

Leave a Reply

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page.Click here for instructions on how to enable JavaScript in your browser.