MGCP backhaul after SRST

Unanswered Question
Jul 16th, 2010
User Badges:

We've been testing new VTI routing on our remote sites. Some of our sites use DSL some use 3G as their backup. We're preventing access to the UCM's because of obvious reasons. During our testing we saw that MGCP packets were still making it to and being sent by the remote routers.  We had to tighten up the ACL's a bit.  But now when the router recovers to the primary path the PRI's won't backhaul to the UCM's.  We see MGCP packets flowing ephones unregistering and registering back to the UCM.  The router registers back to the UCM everything looks fine except the backhaul on the PRI.  Show isdn status shows that it's up and running with all layers looking good except it's not backhauled and no calls are working.  We can see the call come into the router but they're dropping with 'unallocated number'.  I turned on debug ccm-manager backhaul and see these messages over and over again:


Jul 15 21:02:24.068 EDT: cmbh_xport_rcv: Could not process message for channel A000

Jul 15 21:02:24.068 EDT: cmbh_xport_rcv: No channel record for this


I finally gave up and did a no ccm-manager config and a ccm-manager config and that triggered the UCM to reconnect everything.  Everything was back to normal backhauled and all.


I searched the whole internet including this forum cisco.com for those debugs and found nothing.


We're running CUCM 7.1.2.20000-2 and IOS 15.0(1)M.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
mmendonca Fri, 07/16/2010 - 09:15
User Badges:

Closest bugs I've found so far:



CSCtc87384 Bug Details Bug #17 of 29 | < Previous | Next >


ccm-manger switchback scheduled-time does not work
Symptom: ccm-manger switchback scheduled-time does not work


Conditions: using scheduled time switchback method an mgcp router will not switch back from secondary ccm to primary ccm at the scheduled time

Workaround: use one of the othter switchback methods , graceful, immediate etc


we already use graceful but immediate may be worth a try...


CSCtg74861 Bug Details


BRI doesn't send RSIP and register to CUCM after fallback from SRST
None
Symptom:

BRI interfaces on 2801 are registering to CUCM 6.1. If failover to SRST and fallback to normal
mode, intermittently 1~2 BRI interface don't register to CUCM.


Conditions:

MGCP with SRST is configured.

Workaround:

None.


In our case it's a PRI on a 3800 with CUCM 7.1(2).


No one else has any history or issue with this?

mmendonca Sat, 07/17/2010 - 07:42
User Badges:

TAC Case Collection is a cool thing.  Never knew it was there is it new?  Learning lots of new things recently it's fun!

mmendonca Sat, 07/17/2010 - 08:20
User Badges:

Cool tool but didn't exactly match up to what is happening.  Opened TAC case will post actions here.

Rob Huffman Sat, 07/17/2010 - 10:17
User Badges:
  • Super Red, 40000 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 IP Telephony, Unified Communications

Hey Mark,


I could not find any related Bugs either, so hopefully TAC can isolate

this issue


On the TAC case Collection note, this great tool has been around for

quite some time but is seriously under-advertised and therefore under utilized.

So good find here!!


Another great source of info is found here, check it out;


http://www.ciscosystems.cg/web/services/news/ts_newsletter/techdocs/index.html



Cheers!

Rob

mmendonca Sun, 07/18/2010 - 17:29
User Badges:

So much out there.  Rob thank you.  Bookmarked .


We've got an unused PRI in the Data Center I'm going to try and patch up to the lab tomorrow and test/debug some more.  I've also got a TAC case open.


Mark

mmendonca Thu, 07/22/2010 - 06:11
User Badges:

Some of the remote locations use 3G for their VTI tunnels.  It just isn't fast enough to support voice.  We can't police it either so we wanted to stop the router from registering back to UCM.


Problem solved.  We had to tighten up the ACL's a bit to stop MGCP packets from going back and forth when the router was up on the VTI.  Tested in the lab everything works perfect now.

Actions

This Discussion