I don't think you are the only one- I too sometimes have issues with getting the PRI up and running. Here is the my approach to getting the PRI (using MGCP) MULTIPLE FRAME ESTABLISHED. The assumption here is that the config is correct. 8 times out of 10 (my guess-timate) it is confifguration error. Also make sure that if the SUB is the primary call processing agent, that phones have registered to the SUB without issue. (1) no mgcp/mgcp on the IOS (2) Ensure that if I just used hostname not FQDN in the Device Name field on CCM. Ensure that no domain name is configured on the router (3) ** remove any mgcp bind statements configured on the BR1 router. ** I have seen over and over again issues (sporadic) when mgcp packets are bound to a Vlan or loopback interface. (4) shutdown/no shut the voice-port on the BR1 (5) deb isdn q921. Am I sending L2 messages? Am I receiving something back? (6) if i am sending L2 Q921 but getting nothing back then time to tell the proctor (or in PL, reboot the PSTN-WAN). I stress that I would perform these steps after making 100% sure the configure is correct. I think step (3) might resolve most of your problems- maybe step (5) would too. A reboot would clear both. If I was really struggling, I would see if I could get the PRI up and running without MGCP- that would involve removing the bind-l3 on the serial, removing the service mgcp at the end of the pri-group. So in other words, just configure with switch-type and pri-g on the controller. If that don't work then it is more than likely a backbone issue. Every now and again, when we keep switching from PRI <-> R2 on the E1, we do seem to encounter the occasional problem with the BR1 T1 PRI (rare) but that could also be something you are running into. The PSTN-WAN is a dedicated router per pod so we do indeed reload the router- but I'm sure shut/no shut on the voice-port on the other end of your T1 PRI would do the trick to.
---------------------------------------------------------------------------- ---------------------------------- Vik Malhi - CCIE #13890, CCSI #31584 Sr Technical Instructor - IPexpert, Inc. A Cisco Learning Partner - We Accept Learning Credits! Telephone: +1.810.326.1444 Fax: +1.810.454.0130 Mailto: [EMAIL PROTECTED] IPexpert - The Global Leader in Self-Study, Classroom-Based, Video-On-Demand and Audio Certification Training Tools for the Cisco CCIE R&S Lab, CCIE Security Lab, CCIE Service Provider Lab , CCIE Voice Lab and CCIE Storage Lab Certifications. _____ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jane Ryer (jryer) Sent: Friday, February 22, 2008 9:43 AM To: ccie_voice@onlinestudylist.com Subject: [OSL | CCIE_Voice] bringing up ISDN at BR1 I have had repeated issues (on different pods) getting the PRI in the BR1 routers to reach an ISDN layer 2 status of "multiple_frame_ established". My usual tactic to get the link up is to reload the BR1 router, but yesterday even that didn't work on Pod32. I was finally successful by hitting the power button (on the Proctor labs web page) for my PSTN router. (My guess is that probably just does a shut/no shut on the controller on the PSTN router; I doubt that they would actually power down a router which is shared between pods.) When I "powered back on" my PSTN router, the link came right up. My usual process is to issue all the necessary IOS commands on the BR1 router (per task 4.2 in the Ipexpert workbook), then sometime later (in some cases it might be an hour or two later) to get to the Call Manager configuration. When I finish the Call Manager configuration, I do a "reset" on the gateway on Call Manager, then go to the router and issue "no mgcp" followed by "mgcp". The PRI almost never comes up at that point, so then I try combinations of shutting down mgcp on the router, completely restarting Call Manager on both Pub and Sub, doing a "no shut" on mgcp. Sometimes I am successful with some of those attempts, but more typically I then reload the BR1 router and after the router reloads, the link comes right up. I am concerned whether I am going to run into this in the actual lab, without any access to the "PSTN router" side of things. I guess if that happened, I could run some isdn debugs and ask the proctor to reset the other side, but I really need to understand better what's happening before I do that. It's been a VERY long time since I studied ISDN q921/q931 protocols. I did do a few isdn debugs yesterday, but didn't know what I was looking at, and managed to lock up the router by issuing "debug isdn all" or something like that. Is there a better process/procedure for setting this up? Should I not do the "isdn bind-l3 ccm-manager" command on the serial 0/0/0:23 interface until Call Manager is set up? But won't the "service mgcp" at the end of the pri-group command on the controller keep it from coming up anyway until Call Manager is responding? By the way, a "sho ccm-manager" command was showing that MGCP was registered to my subscriber, with a backup of my publisher. Has anyone else had similar issues? What am I missing here? Do I need to dig more deeply into q921/q931? (There are so many other areas that I need to be studying . . .sigh!!) Thanks, Jane
