RSS

When simple changes aren’t…tales of MGCP to h.323 conversions

Maintenance windows have a way of reminding you that simple changes aren’t always so simple.

Take a recent after hours task of switching over some MGCP gateways to h.323.  The primary inbound gateway was already h.323 and the MGCP gateways were – well, MGCP – so it made sense to make everything uniform and do the conversion.

So I changed all my calls to route in and out the primary gateway, which was already h.323, and set about making my changes.  In case you haven’t done this before, here is a brief outline of the process – not meant to be a step-by-step, all inclusive list, just a general idea of the process.

On the gateway side:

-set isdn switch type on the router (you can get this from the MGCP configuration in CUCM)
-bind h323 to source interface
-create inbound and outbound dial peers on the router
-remove MGCP bind command and other MGCP configuration (you will need to shutdown the voice port to do this)
-reconfigure the T1 controller
-confirm MULTIPLE_FRAME_ESTABLISHED
-put in place any translation patterns required
-add commands for calling name and/or Facility IE support if required

On the Cisco Unified Call Manager side:

-create the gateway 
-add the gateway to a route group
-add the gateway to a test route list
-create a few route patterns to send calls out the gateway
-add gateway to production route list(s)

My plan was proceeding perfectly up until I needed to send a long distance call out one of the recently converted gateways.  The call received a reorder tone from the carrier even though the debug isdn q931 output showed my call going out with the proper digit format. I knew long distance calls were working going out this gateway before, so I was pretty sure it had to be something with my configuration even though it looked like a carrier issue.  

After comparing configurations with the current h.323 gateway (PRI to the same carrier), uttering a lot of fairly creative yet non repeatable curses, and wasting an hour of my life with a clueless carrier tech who swore I wasn’t sending the 1 required for long distance, the obvious finally hit me.  And it was annoyingly painful.

See, I had made the assumption that long distance calling had been tested out the primary gateway when it was installed.  I foolishly believed that outbound long distance via the primary h.323 gateway had been tested at installation, as this is pretty much standard and *should* be part of any voice gateway install process.  Once I wised up and tested that theory, however, I realized that all long distance calling to the carrier was broken from every gateway, including the old h.323 one which I hadn’t changed anything on.  Knowing this couldn’t be the result of my conversion efforts, I was now able to think through what the real source of the issue could be.

When you send the carrier the right digit format and yet they emphatically insist you most definitely aren’t, you are likely hitting an issue I blogged about in my first ever post.  In some cases, a carrier switch reads your ISDN plan type and takes digit stripping action based on it. They seem to be completely unaware they are even doing it, so don’t expect the carrier to ever discover this is your problem. The solution is simply to set a translation pattern that changes the plan type to UNKNOWN and then the carrier switch doesn’t try to do you any favors and manipulate the digits. Problem solved.

I am now adding testing inbound and outbound calling from ALL gateways before making changes to my check list.  Pass the bourbon please.

Bonus material:
At the time, I didn’t think about the 8945 phones (and newer phones with video capabilities) that often require you add a specific command to the ISDN voice port, otherwise outbound calls from the device fail. I discovered this while finishing up my testing plan and was able to fix it before anyone noticed.  A very good reason to have a thorough testing plan no matter how small the changes being made. Here’s a link to a forum post on this type of issue and the command you need to fix it:

voice-port 0/1/0:23
bearer-cap speech

Also, your lucky day, some commands for calling name when carrier is using the Facility IE:

voice service voip
h323
h225 display-ie ccm-compatible
!
interface Serial0/1/0:23
isdn supp-service name calling
isdn outgoing display-ie

Published 7/2/2014

 

Tags: , , , , , , , , , , , ,

The Sparkly Side of Cisco Live 2014

In case you were living under a rock in the networking world, Cisco Live 2014 happened last week and in a big way.  Thousands of geeks took over San Francisco and it’s safe to say a good time was had by all!

A few things made my week in particular quite excellent, one of those being the Cisco Champion(s) Program. The Champion events were excellent opportunities to get to know fellow engineers and have a good time laughing it up with friends.  A special thanks to my fellow ginger and partner in plotting world domination, Amy Lewis (@commsninja), who definitely leveled up her already extraordinary unicorn wrangling skills. Her own talk was also fantastic and you should check it out here.

IMG_0732  IMG_0721

Tech Field Day also organized some great events, including round table discussions for us blogger/social media types.  These pictures don’t do justice to the staggering amount of brain power gathered around the table, but you can check out the videos here.

        

I’d be remiss not to give an extra special thanks to these two guys, Tom (@networkingnerd) and Stephen (@sfoskett) for all the work they do to build community in networking.

 

IMG_0726

This Cisco Live was also the week of fabulous tweeps bringing me all sorts of fun and shiny presents.  From a Batgirl t-shirt from Jeff (@fryguy_pa) to actual sparkly bats from Tom (@networkingnerd) and Denise (@denisefishburne), I love that this group laughs and jokes together.  A sparkly PVDM from Erik (@ucgod) and a tiara (also from @denisefishburne) rounded off the gifts. The opportunity to dub Pete Lumbis (@tacCCDE) as the king of TAC, complete with a tiara and a sword, certainly made my week.

IMG_0700IMG_0692IMG_0693

IMG_1036

Last but not least, the awesome events organized by @ciscolive @kathleenmudge @rbakker and the rest of the Cisco Social Media team, allowed for some quality time with awesome engineers.  These are just a few pics below. From the looks of it, by the end of the week dignity had clearly taken a vacation, not that there was much of it to start with in this crowd.

IMG_0777IMG_0735IMG_0694

IMG_0729IMG_0706IMG_0722

IMG_0731IMG_0741

IMG_0813

Good times with truly good friends. Can’t wait till next year!

Special shout out to Kale Blankenship (@vcabbage) for creating a CLUS set of Cards Against Humanity. This one is my favorite:

IMG_0717

And congratulations to @bcjordo who got his CCIE digits on Monday, way to go!

 

 
6 Comments

Posted by on 2014/05/27 in Cisco Live, Cisco Live 2014

 

Tags: , , ,

Threats of Tornados and Redistribution, Oh my: The final day of Narbik’s Training Class

Today started out a typical day in Narbik’s class – lots of labbing and mind-bending topologies, today’s subject being QoS. Until today, I have never sat through a lecture on or read a book about QoS that wasn’t just a slight step up from a root canal in terms of pain and frustration. However, today’s lab demos really helped clarify what various methods of QoS were really doing, and as a bonus, I didn’t feel an overwhelming desire to be anesthetized while listening to the explanation.  My loose grasp on previously confusing terms like single rate, two color policers versus dual rate, three color policers was significantly strengthened.

We then made an attempt to talk redistribution.  Now apparently Narbik has a history with redistribution, when he tried to talk about it in Poland, they ended up with a fresh coat of snow on the ground, and today Dallas nearly took a tornado for it. The warning sirens went off, literally, and we all got to trudge down to the first floor of the hotel and cram into a small space with a few hundred other guests. As Narbik himself said, “sh** happens when you do redistribution.” Hilarious and so true!  When we got back to class, we looked at about a half dozen scenarios where redistribution sent a perfectly good network into the crapper. Incredibly fascinating to see and start to really understand the vulnerabilities inherent in the processes.

Now a typical Narbik class would not have ended after that, stories of Thursday nights are legendary – the night usually ending about 4:30am or so I am told. Since, however, we missed our window for the last mock lab attempts while slumming around in the tornado shelter, we decided to finish the lectures for the entire week and class came to an early close at a mere 7pm. Fortunately all the students get an opportunity to make up the mock lab attempt on our own within the next couple of months, so it all works out.

I can honestly characterize this class as one of the best educational experiences I have had.  Much of this stems from the philosophy of learning espoused by Narbik himself and shows in the quality of his teaching and methods. His pronounced idea that he is creating and shaping better engineers, not just folks that can pass a test really resonates with me.  He talked about how engineers are like artists and that how we do our work is our signature. He went on to say how we should pride ourselves in the quality of our work even when no one is watching or grading it. I just couldn’t agree more.

On that note, I’d like to thank Eman Conde and CCIE Flyer one last time for giving me the opportunity to sit the class, couldn’t be more grateful for the experience!

Published 5/8/2014

Disclaimer: While Eman and CCIE Flyer were very generous to grant me a seat in this class and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

 

 
1 Comment

Posted by on 2014/05/08 in CCIE, ccie boot camp

 

Tags: , , ,

Can I get a hardware upgrade please? Narbik’s CCIE training, Day 3

Pretty sure I need a vAmy upgrade on memory and disk space to make it through the end of this fabulously exhausting week.  It’s the third 12-14 hour day of class and I have resigned myself to seriously constrained sleeping and eating.  I have been smart enough to bring snacks for the afternoons and that definitely helps keep energy levels up, especially since dinner is a luxury this CCIE training class opts out of entirely.

We covered BGP and MPLS in-depth today and I really wish I had these lectures years ago when studying for the CCIP track. Narbik certainly has a gift for explaining the overall big picture without glossing over the intricacies of how things work.

I was encouraged when he presented one scenario and I immediately saw the impact and suggested a possible solution – the solution he was just about to present.  Always nice to be on the right track!

Today was also focused on developing a troubleshooting process – a methodology that could be worked over and over again and help keep me from stumbling around and getting lost on troubleshooting tickets.  Definitely want to work on some flow charts/lists/processes for this and commit them to memory.

Also learned some pretty cool tricks for troubleshooting BGP today, pretty sure I will be seeing AS numbers in my sleep. Which actually isn’t that unusual for me…

Narbik says tomorrow is our long day, this worries me and I think I’d better get some sleep…

Published 5/7/2014

Disclaimer: While Eman and CCIE Flyer were very generous to grant me a seat in this class and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

 

 

 

 

 
Leave a comment

Posted by on 2014/05/07 in CCIE, ccie boot camp

 

Tags: , ,

Runt Post: Narbik & the Bad Ass Network Topologies, Day Two of CCIE Training

Today we started off class with Narbik excitingly diving into what he humorously referred to as “bad ass networking topologies” and it certainly didn’t disappoint. We looked at OSPF from conceivable angle and then tackled the inconceivable ones.  While I may have felt at one point or another in my life that I understood OSPF, I am now convinced that someone should have handed me some crayons and safety scissors to match my elementary knowledge level.  Good news, however, there is some serious leveling up going on.

I could feel the brain cells clicking when we looked at topologies that weren’t just examples of “stupid router tricks” but instead were excellent demonstrations of how the protocol responded under given conditions and caveats.  Being able to see the problems while configuring the CLI definitely drove concepts home for me.

One of the best quotes today was Narbik saying “if Cisco says something is not supported, it becomes a puzzle for me.”  This kind of attitude makes good engineers and great teachers. I’m certainly feeling the challenge this week of the vast amount of knowledge I have yet to master, but am encouraged to see that I seem to have a knack for the troubleshooting questions.  Which is definitely good because Narbik also said “I looked at this switch and I asked myself what is everything that could possibly go wrong in this switch, and then I created your troubleshooting homework from that.” Yep, we are *way* passed kindergarten.

Time for sleep now, grateful there is at least a little rest for the weary.

Published 5/5/2014

And a bonus command for readers today – and I cannot believe I have never seen this before today – you can speed up your traceroutes by using the numeric keyword.  This keeps it from having to waiting on DNS resolution. It’s the best thing since sliced bread, and who doesn’t like sliced bread?

R1#traceroute 1.1.1.1 ?
numeric display numeric address
port specify port number
probe specify number of probes per hop
source specify source address or name
timeout specify time out
ttl specify minimum and maximum ttl

Disclaimer: While Eman and CCIE Flyer were very generous to grant me a seat in this class and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

 
6 Comments

Posted by on 2014/05/06 in ccie boot camp

 

Tags: , , ,

Runt Post: Narbik’s CCIE Boot Camp, Day 1

A few months ago, Eman Conde (of CCIE Flyer) granted me a seat to attend an upcoming CCIE training class taught by none other than Narbik Kocharians. Well, today that officially kicked off.  And wow, what a week it is going to be.  Narbik’s classes are legendary and after today I can see why.  He began the day insisting the staff bring him the largest whiteboard they could find.  I *always* take this as a good sign. He then delved into his philosophy of teaching and I was thrilled to find that it very much aligns with how I like classes to be presented and how I learn best. He really drove home ideas based around explaining for understanding and hands on doing while learning.  I laughed when he said “if I say something but I don’t give you a lab on it, than it’s probably a lie.”

Today was mostly spent getting my keister kicked by a practice evaluation lab that was supposed to be easy. Yes, did I mention drinking from the fire hose this week? But tomorrow should be more teaching and doing as alluded to earlier in the day.  I am really interested to see what Narbik calls “teaching the theory from the command line perspective” looks like.

Still more troubleshooting homework to finish up, so that’s all the updates for now.

Published 5/5/2014

While Eman and CCIE Flyer were very generous to grant me a seat in this class and I am very grateful for it, my opinions are totally my own, as all redheads are far too stubborn to have it any other way.

 
 

Tags: , ,

Not All PRIs Connect to Telcos…

Occasionally in voice world you end up configuring PRI connections to devices other than telco gateways. Sometimes these are PRIs between PBXs, fax servers, or other third-party vendor voice gateways for applications. These are typically connections internal to the organization versus a PRI to the outside world. Many times these require you to think just a little bit differently than your standard PRI turn-ups to get to that fabulous MULTIPLE_FRAME_ESTABLISHED goodness.

I’ll offer you a few things to look out for should you find yourself in this type of situation.  Keep in mind that no voice installation is ever *standard* so your mileage may vary.

1. T1 crossover cable. It’s a thing.  Often times the vendor bringing in their voice gateway will tell you things like “it’s just an RJ45 hand-off” or “just provide us a straight-through cable” but don’t believe the lies. More often than not in cases where you are going from your voice gateway to a vendor’s voice gateway, you will need a T1 crossover cable to achieve blinky green light success. You can order these via your favorite cable vendor or Google it to see the pin out and make one yourself, should you be that kind of handy.

2. ISDN switch-type. When you setup a PRI with a telco, they tell you what switch type and line encoding you will use, not much room for creativity.  With these back to back non-telco PRIs, I have found that vendors often have no idea what switch type you should be using and just start naming some that sound believable.  As with any PRI, you need to find an ISDN switch type that both sides can support and this could take some guessing if the vendor doesn’t know. For what it’s worth, I have had a lot of success with primary-5ess, but terrible luck with primary-ni. Of course the switch types and line coding must match between the devices.

3. “Reverse” dial-peers. Typically dial-peers follow a general standard of sending 4 or 5 digits to the CUCM and sending local, long distance, and international patterns out the serial interface of the PRI.  When passing calls between gateways in an internal situation, you need to think about what is going to be coming across to your voice gateway from this new PRI connection.  Many times it’s devices that will be trying to make outbound calls. That means they will be sending calls to your gateway and then your gateway will need to pass them to CUCM to send them out.*  You will also need to communicate to your third-party application configuration team (which may be you) the correct pre-pending for the vendor to use in order to match your dial-peers. For example, will the devices be dialing with a 9 or without?  Here’s an example of a dial-peer that would handle a local call by sending it to CUCM for further processing. Note, in the example I am requiring the vendor to pre-pend**:

dial-peer voice 10 voip
destination-pattern 9[2-9]………
modem passthrough nse codec g711ulaw
session target ipv4:10.10.10.10
dtmf-relay h245-alphanumeric
no vad
voice-class codec 100
voice-class h323 1

4. ISDN, someone needs to be in charge. This where the fairly obscure isdn protocol-emulate network command comes in.  The default in IOS, which you don’t see (because it’s the default), is isdn protocol-emulate user.  You may need to change this to get the PRI to a MULTIPLE_FRAME_ESTABLISHED state. To do so you add the emulate network command under the serial interface like so***:

interface Serial1/0/0:23
no ip address
no ip directed-broadcast
isdn switch-type primary-5ess
isdn protocol-emulate network
isdn incoming-voice modem
no cdp enable

Fortunately troubleshooting these types of connections are about as straight forward as other ISDN PRIs and debug isdn q931 is your best friend. Also, debug voip dialpeer all comes in super handy.

Published 4/30/2014

*this assumes the new vendor PRI and your current telco PRI are not terminating on the same box.  If they are you may need to enable h323 to h323 connections as well as deal with any clocking issues from having basically two providers housed in the same box.  There are specific caveats on making this type of scenario work, refer to Cisco’s documentation for your gateway.

**keep in mind that POTS dial peers consume, that is strip, explicitly matched digits and voip dial peers do not. So if, for example, you are sending a four digit extension across to the vendor’s gateway via a POTS dial peer with a destination pattern of 5000, you should add a forward-digits all to the dial peer to compensate for this behavior.

***bonus information on the isdn protocol-emulate network command

 
 

Tags: , , , , , , ,

 
Follow

Get every new post delivered to your Inbox.

Join 218 other followers