MGCP and PRI issue

Unanswered Question
Aug 8th, 2007

I have a branch office and GW with full E1 PRI circuit and connection to IP WAN. This is centralized deployment without CCME and set-up for SRST. If the GW is not communicating with CCM (i.e. IP WAN is down), the isdn status comes up fine with multi frame establised. However, when CCM is given control to the PRI interface I lose multi frame established and see in it's place TE1_Assigned. There is no problem with layer1 isdn. As a result no external calls can be made from remote site. From CCM the GW is registered perfectly.

Anywhere in particular I should start looking?

Have already reset MGCP and GW number of times.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading. Thu, 08/09/2007 - 11:19

On the CallManager webpages under the gateway setup what ISDN protocol are you using? PRI Euro, QSig etc. Does that match up with what has been programmed on the gateway configuration on the device itself? eg isdn switch-type ....

AJAZ NAWAZ Thu, 08/09/2007 - 11:57

yes they do match. PRI Euro on CCM side and primary-net3 under the serial on the gateway.

this one has got me baffled.

Ajaz Thu, 08/09/2007 - 12:18

primary-net3? I don't have that as a option on my gateways. Have you checked to make sure that the same switch-type is showing up under "sho isdn stat" when the gateway is connected and not connected to the CM?

AJAZ NAWAZ Thu, 08/09/2007 - 13:26

yup. you possibly don't see that option since your gateways are populated with T1 cards. primary-net3 is Euro for sure.

so to the other point. output from ISDN status shows correct switch type and encaps, and as i mentioned before - getting multi frame established when CCM is not reachable. The spanner is thrown into the works as soon and CCM comes into the frame.

you see the thing is i've done a bit of reading on MGCP and understand that it controls the interfaces and sends configuration to the gateway through TCP 2427 (and tcp 2428?)

I'm going to do some more digging into PRI backhauling since the symptoms do warrant this. This document looks fantastic:






AJAZ NAWAZ Fri, 08/10/2007 - 15:08


Two things to mention really. I made a mistake stating primary-net3 - it was actually primary-net5.

Secondly, I managed to resolve the issue albeit it was SW bug related. The root cause was PRI backhaul issue with MGCP. So you know that's UDP 2427 and TCP 2428. I had to frigg both of these since they were included within a policy map / access-list. Didn't see a need to mark these with QoS so removed them and bingo!


btw - given that i solved my own problem how can i rate the post ;)

Thanks for your help dude.

Ajaz :-)


This Discussion