cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2618
Views
0
Helpful
6
Replies

MGCP D Channel out of service - RTMT sending a false positive?

jeffrey.girard
Level 1
Level 1

My client uses predominantly MGCP gateways (over 40).  One in particular has 3 PRIs to an Avaya PBX.  In RTMT, I keep receiving emails about a specific D channel being out of service.  I look at the alert properties to identify the specific circuit/T1 and use that information to look in the CUCM 6 cluster to determine the specific controller/port.

I log into the router and the controllers/ports show no errors at all and all 3 PRIs are up.  I have a coworker log into the Avaya and he sees the same from that side (ie no issues that the trunks are clean).

Any ideas about what could be tripping the D channel out of service alert on RTMT?

Jeff

6 Replies 6

Gordon Ross
Level 9
Level 9

Gut feel is to check and double check the clocking. Check that both CUCM & Avaya agree on who's providing the clock. It should (must ?) be consistent across the three PRIs to the Avaya.

If no joy there, then I'd suggest checking the physical side of things (patch cables). You could also enable debugging on that particular trunk (and log it to a syslog server) to try and capture what's going on.

GTG

Please rate all helpful posts.

Gordon -

     Clocking is confirmed to be network clock on the gateway.  All 3 PRIs using the same clocking source (network T1 0/0/0) but only the first T1 is having the issue.

Karthik Sivaram
Level 4
Level 4

hello Jeffrey,

Could you also tell me if the PRI is configured as fractional. I mean are you using all  channels in the T1/E1 or is there a limited number of channels that you are using in the PRI?


Thanks,

Karthik

Karthik - All 3 are full T1s

Hi Jeff,

You might have to check the status of D-ch on the CUCM web page itself, since the RTMT got the alert from CUCM.  I've seen the same problem with another customer that D-ch shown 'Unregistered' in the CUCM, but on the IOS gateway it was fine, so there was a back-hault MGCP communication issue between the MGCP gateway and the CUCM itself.  Not sure if that was a bug or not, but when I registered the MGCP gateway to another subscriber in the same CUCM group, the problem went away.

Just my 2-cent.

Regards,

Binh.

Can it also happen if Network clock source transitioned its priority ?