RSS

Monthly Archives: February 2012

The Sting of Rejection: Part 2

We left off the last episode with one registered conference bridge and one snarky MGCP port touting its Registration Rejected message as a badge of honor.

So what makes MGCP ports unhappy enough to reject all caring efforts of devoted voice engineers?

A few things you should check first:

Is MGCP configured and running on your gateway? Sounds simple enough, but easy to miss the actual “turning it on” step.

In this particular case, I was configuring a single port on an otherwise h323 gateway as an MGCP port, so my configuration looked something like this:

mgcp
mgcp call-agent 192.168.1.10 service-type mgcp version 0.1
ccm-manager fallback-mgcp
ccm-manager redundant-host 192.168.1.11
dial-peer voice 10 pots
     description MY MGCP PORT
     service mgcpapp
     destination-pattern 7777
     port 0/2/0
application
     global
          service alternate default

The above configuration allows not only for port 0/2/0 to be controlled via MGCP, but also allows the port to failover to h323 when in SRST mode.

So once you’ve checked the gateway configuration and everything looks kosher, you can move onto checking the CUCM piece of the puzzle.  There are (at least) two common errors when it comes to MGCP port configuration.  One, and by far the most common, is to get the device name wrong.

Easiest way to check this is to do a #show ccm-manager on the gateway and see what is listed as the device name in the output . Go ahead and copy and paste this into CUCM to be sure you have it correct. Your device name will look like mygateway@mysitename.com if the domain name is set. This needs to be precise in CUCM or the gateway won’t register – it would be like calling your new girlfriend by your old girlfriend’s name. Hostile doesn’t begin to describe it.

The other most common mistake is to pick the wrong module, card type, and/or slot for your gateway in CUCM.

The best way to ensure you are picking the right module, card type, and slot for your gateway from the CUCM drop-down menus is to do a #show diag on the router. This will show you the part number and slot you should be picking.

If your card is a VIC3-4FXS, selecting a VIC-4FXS in CUCM is not the same thing. Extending the previous analogy, saying your girlfriend has blue eyes when they are really green, will not help your cause. And in that example, the results may be fatal.  With CUCM however, you will likely be greeted with a Registration Rejected message and a raspberry blown in your general direction should you err in your selection.

Here’s an example of what you will be looking at, be sure to confirm part number and location with your router output:

MGCP module selection

On this particular brain-dead day, I had managed not to make either of these mistakes but was still getting a Registration Rejected error. Troubleshooting finally revealed I had made two very bad assumptions.  One- I assumed that the IP address CUCM was seeing for the port on the gateway was reflective of connectivity to that IP address.  Two- I assumed the networking had been done before the voice person was called in.  In hindsight, both of these assumptions were really very silly.

If you haven’t configured an MGCP port before, CUCM shows the IP address of the port after it tries to initially register.  Do not make my mistake and assume this means CUCM can actually reach that ip address.  Logs confirmed that, since I had not bound MGCP to any particular interface, MGCP was sending messages to CUCM which included the highest configured IP address on the router.  Just because CUCM knew about this address did not in fact mean that it was actually reachable.

Once I was issued my clue card, I easily confirmed with an unsuccessful set of pings – sourced from IP address CUCM had reported seeing- that indeed connectivity did not exist between the two devices.

The solution was simple enough – bind MGCP to an interface that could actually reach CUCM and voilà – instantly registered MGCP port.  I will point out that actually fixing the routing is an even better solution, but unfortunately outside my scope on this project, so second best had to do.

Here’s what the fix looked like:

mgcp bind control source-interface GigabitEthernet0/1
mgcp bind media source-interface GigabitEthernet0/1

So there you have it – many more slow days like this and my blog entries will practically write themselves!

Publish date 02/24/2012

 
2 Comments

Posted by on 2012/02/24 in MGCP

 

Tags: , , ,

The sting of rejection: Part 1


Ever have one of *those* days where you just aren’t on your game?  Usually we try to keep those days to ourselves and hope no one is noticing, but I’ll share a couple of pieces of one of my brain dead days in hopes that someone gets a good chuckle, that someone learns something, and that *I* never, ever, make this particular mistake again.

So there were two tasks remaining to complete my voice gateway setup: configure local conferencing and configure a single MGCP port on the router – in this case on a 2800 series.  Let me just preface this by saying this same setup had been done for approximately 20 other sites.  Imagine my surprise when neither the conference bridge nor the MGCP port registered. This blog entry will focus on the conferencing issue and mayhem that ensues when you just can’t see what it is you’ve done wrong.

There are a number of steps to creating a conference bridge on an IOS voice gateway.  The router configuration is going to look something like this:

dspfarm
dsp services dspfarm
sccp local GigabitEthernet0/0.1
sccp ccm 192.168.1.11 identifier 1 priority 1 version 6.0
sccp ccm 192.168.1.10 identifier 2 priority 2 version 6.0
sccp
sccp ccm group 1
bind interface GigabitEthernet0/0.1
associate ccm 1 priority 1
associate ccm 2 priority 2
associate profile 1 register my-Conf
dspfarm profile 1 conference
codec g711ulaw
codec g711alaw
codec g729ar8
codec g729abr8
codec g729r8
codec g729br8
maximum sessions 3
associate application SCCP

Once you’ve done this, you just need to add the conference bridge in Call Manager and it’ll register.  In theory. And in practice – if you do it right.  But I hadn’t.  My bridge was a bridge to nowhere – status Rejected. <cue sad violin music>

If you find yourself in a similar situation, there are several things you should check right out of the gate. Or should that be gateway?  But I digress.

Is sccp running on the router?

Enter no sccp, then sccp to confirm.

Is the dspfarm profile active?

Enter dspfarm profile 1 conference, then do a no shut.

Is the name of the conference resource correct on the router and in CUCM? In our example above it’s my-Conf, that *exact* name should be entered in CUCM. No wiggle room in this one – copy and paste it from the router to be sure.

And here’s the kicker.  At least what kicked me a few times over:

Is the conference bridge type you selected correct?

When I added the bridge to CUCM, I selected Cisco IOS Conference Bridge.  Sounds like a good choice, right? Uh, no.

What you really want is Cisco IOS Enhanced Conference Bridge. Which is what had been picked the other 20 times this had been done.  But for whatever reason, I picked the former, and let me tell you, the system does not provide a handy error message that says “hey bozo, you picked the wrong bridge type.”  Although, I am sure that will make it into the latest release.

Here’s what you will likely see as options in the drop down, go ahead and make the enhanced selection, you deserve it:

If, however, you choose poorly error either due to oversight or just not knowing any better, you will a status of Rejected for the bridge. In the RTMT Application Log for the CUCM server, you will likely see this error message over and over again:

: 37326: Feb 08 06:02:00.522 UTC : %CCM_CALLMANAGER-CALLMANAGER-3-DeviceTransientConnection: Transient connection attempt. Connecting Port:0 Device name [Optional].:my-CONF Device IP address.:192.168.1.11 Protocol.:SCCP Device type. [Optional]:52 Reason Code [Optional].:3 Cluster ID:StandAloneCluster Node ID:MYCMPUB

And if you are industrious enough you can track that reason code down, but it doesn’t necessarily shine much light on the situation:

So just add “Confirm the correct conference bridge type, you ninny” to your checklist when configuring a conference bridge on an IOS router.

And try very hard not to overlook this mistake the 90 times you check your configuration afterward.  It’ll save you a few hours of head scratching and an embarrassing call to TAC.

*In order for your devices to use the fabulous conference bridge you’ve just setup, be sure to assign it to the appropriate Media Resource Group and Media Resource List. Also, be certain you have assigned the MRGL to the devices or device pools that will need it.

Publish date: 02/09/2012

 

Tags: , , , , , ,

A Brief Interlude for OpenFlow

In this post I am going to veer away from voice-related topics ever so briefly to chime in on OpenFlow networking, hitting specifically on HP’s Open Flow’s story – why HP’s story? Well, frankly, because @hp_networking invited me to a briefing on the subject this morning and OpenFlow is freaking cool.

So what could I possibly say about OpenFlow and software defined networking that @etherealmind, @ecbacks, @ioshints, and other networking gurus haven’t already written about?  Not much. In my defense, however, those guys are blogging machines!

So my point in this post:  HP *has* an OpenFlow story.  Honestly, hadn’t caught that before – but to hear them tell it they have been working with OpenFlow founders since it started as a science experiment in someone’s basement (no, not really a basement- well, maybe a basement). Recently HP announced they were making all (well almost all) of their switches OpenFlow capable.  http://www.networkworld.com/news/2012/020212-hp-openflow-255641.html

Why does this matter? Um, because in my opinion, if these guys are doing it, the reality is OpenFlow is here and looking for a place to settle in.

Where exactly is it settling in at? Is it like the 800 pound gorilla, wherever it wants to?  I’m not so certain about that one, but the flexibility OpenFlow offers means you can toss a slew of issues at it and adapt a solution to meet the needs of the moment.  At least that’s the hype – and from what I can tell – a very plausible reality being implemented now.

If you want to get educated on OpenFlow I highly suggest checking out the resources I’ve listed below. Or take Greg out for a drink, pretty sure after one or two rounds, he’d be more than willing to talk your ear off about it.

http://etherealmind.com

http://packetpushers.net

http://ipspace.net

http://techfieldday.com/2011/openflow-symposium/

https://www.opennetworking.org/

Publish Date: 2/2/2012

 
1 Comment

Posted by on 2012/02/03 in OpenFlow

 

Tags:

 
Follow

Get every new post delivered to your Inbox.

Join 183 other followers