cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2162
Views
0
Helpful
5
Replies

ISDN bind l3 ccm-manager

Phil Bradley
Level 4
Level 4

I am trying to get SRST mode working at two sites that use the same CUCM server and have been somewhat successful at site A but not at site B. When I try to dial out of the PRI at site B I receive a fast busy. I have two device pools setup that split the phones at Site A to use the SRST at site A and another device pool that takes the phones at site B and lets them us the SRST router at site b. Site A phones are able to dial out of their PRI succesfully. The only difference that I notice is that the Serial0/0/0:23 interface at site b has the ISDN bind l3 ccm-manager and site A does not. The T1 controller has the command PRI timeslots 1-24 service MGCP applied at both sites so do I need to bind the data channel to ccm? Could this be causing my issue? As you can tell from above I am running MGCP mode between CCM and the gateways and have h323 fallback in SRST mode.

Thanks,

Phil

1 Accepted Solution

Accepted Solutions

Aaron Harrison
VIP Alumni
VIP Alumni

Hi Phil

If you are using MGCP in normal operation you should have the bind-l3 command on both routers.

You should have 'ccm-manager fallback-mgcp' configured on both, this tells the router to reconfigure itself into non-bindl3 mode (effectively unbinding the E1 from MGCP so it can be used by H.323) when CCM is unreachable.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

View solution in original post

5 Replies 5

Aaron Harrison
VIP Alumni
VIP Alumni

Hi Phil

If you are using MGCP in normal operation you should have the bind-l3 command on both routers.

You should have 'ccm-manager fallback-mgcp' configured on both, this tells the router to reconfigure itself into non-bindl3 mode (effectively unbinding the E1 from MGCP so it can be used by H.323) when CCM is unreachable.

Regards

Aaron

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

Hello Aaron,

We are using MGCP in normal operation and then falling back to SRST. One thing that we had to do was disable automatic MGCP between the gateways and CUCM. We have FXS ports that would lose their config under normal MGCP operation and Cisco has identified this as a bug and suggests manual MGCP mode between the gateway and CUCM. I basically took the ccm-manager config server x.x.x.x address out which I think puts it in manual MGCP?? The strange thing is that Site A is not binding the L3 data channel under the serial interface and the T1 is operating normally. One issue that I have had on site B is that the T1 will send a fast busy when trying to dial out if I ever shut the controller or voice interface down and the bring it back up. When this happens if I look at the controller and related ports it appears that the interface and D channel is up though. The strange thing is when the system goes to SRST mode and then back to normal mode the t1 starts functioning correctly again. I don't know what this is doing but apparently is is syncing CUCM and the pri back up. This PRI is on the router that has the isdn bind l3 ccm-manager under the serial interface also. The interesting thing is that site b always gives me a fast busy when trying to dial out in SRST mode.

Phil

Hey Aaron,

Just an update on this. I noticed that in my config that a dial peer I believe was missing for:

999000

service mgcpapp

port 0/0/0:23

After some research it appears in automatic MGCP mode this gets created for a dial-peer on the PRI. I have added this dial-peer to my config and now I can dial out during normal MGCP and SRST which was failing before. Does this make sense? This is the only thing that I have changed since the test last night on the router config.

Phil,

If i understood correctly after you created a proper dial peer calls in Srst mode worked.

That is a must that we need to remember in Mgcp mode the e1/t1 are controlled by the cucm but in h323 we must have dial peers in order to make the gateway know how to route the call.

Good to know that you realized that, i was going to tell you to check the dial peers but since you already solved....

Sent from Cisco Technical Support iPad App

Hello Rafael,

I actually already had the proper dial peers setup for H323 in the SRST router but the T1 line or the gateway was getting out of "sync" with call manager. Anytime I would shut the controller or voice port down and bring it back up the PRI would not work with callmanager in normal MGCP mode. I just happened to be testing SRST and noticed that when I would go to SRST mode and then back to call manager (MGCP mode) the PRI would again start working. I assumed this was because MGCP was registering with call manager and this caused the PRI to start working again. If I am correct, MGCP will automatically create dial peers in the gateway for each port that is controlled by MGCP. I understand that in normal cases the gateway will download the config from call manager with the ccm-manager config command but I had to take this out because of a bug with MGCP and fxs ports. So I am basically creating MGCP config in my gateway now manually. At some point the gateway lost the mgcpapp dial peer for the PRI port. It was interesting though since my PRI would work after the gateway would register back with call manager without the mgcpapp control dial peer defined. This is also true for the isdn bind l3 ccm manager command since it is not present in my site "A site" router but the PRI is still working. However after I added the dial peer above it appears that this fixed the issue with the PRI giving a fast busy when going to SRST mode and also it working consistently with call manager now.

Aaron,

Even though my PRI seems to work with call manager without the isdn bind l3 ccm manager command and I am going to make sure it is in my config. This may have got removed when I went to manual config and I was confused to why it was working without this command. Anyway I will add it back to the gateway in case this causes strange issues in the future.

Thanks,

Phil