I have the Ports already open, and the PRI seems to work. One thing i did notice was doing a source ping from the h323 gateway to the CUCM did not reply, i sorted that issue out, but phones are still in Fallback, and the gateway is not registered.

Global ISDN Switchtype = primary-ni

ISDN Serial0/0/0:23 interface

dsl 0, interface ISDN Switchtype = primary-ni

Layer 1 Status:

ACTIVE

Layer 2 Status:

TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED

Layer 3 Status:

0 Active Layer 3 Call(s)

Active dsl 0 CCBs = 0

The Free Channel Mask: 0x807FFFFF

Number of L2 Discards = 0, L2 Session ID = 2

Total Allocated ISDN CCBs = 0

I still think your issue is to do with PRI backhaul. It is stated in your reply that PRI is good and I don't disagree with that.

But remember that with MGCP, that CUCM is taking control of that interface at q931.

So the correct output from 'show isdn status', with MGCP working should look like this:

ISDN Serial0/3/0:15 interface

dsl 0, interface ISDN Switchtype = primary-net5

L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003

---------------------------------------

We are looking for CCM MANAGER in your case which is missing. Provided with the information thus far, I would still be inclined to suspect the VPN. Ontop of the ports I have already mentioned there are additional ports which are used too. Take a look at this for example of ports required and their funtion:

http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/4_1/41plrev2.pdf

Let us know what happens

Ajaz

I am not using MGCP as i understand it, This system was implemented by someone who is no longer available.

For testing purposes i have opened all ports for my voice VLAN over the VPN, and still in fallback mode.

Attached is the Remote Router Config.

Hi, from your config I can safely say that you're using a H.323 gateway. If the phones and the voice gateway are not registering to callmanager then you either have a Routing or Firewall issue. You mention that you've opened up all the ports on your F/W so we can rule that one out. For your own purposes this document highlights which ports need to be opened for CUCM 6.X http://www.cisco.com/en/US/docs/voice_ip_comm/cucm/port/6_0/60plrev1.pdf

You say you can Ping the CUCM server, have you run an extended Ping using int fasteth 0/0.2?

HTH

Hi,

I see this issue before, What you need to do is ping from the Voice Vlan on the remote site to the Voice Vlan on the HQ site to bring up the vpn tunnel, SCCP traffic does not seem to bring up the tunnel.

Yup extended ping from fastethernet0/0.2 is successful to the CUCM, however a traceroute does not work from that interface.

The VPN tunnel is being established via the firewall, and not this router.

Any other idea's?

It is highly likely that the fw is blocking traceroute. you sound like your happy that network reachability is not the issue.

who manages the fw, and is it Cisco ASA or something else...?

Make sure the fw allows:

UDP 1718

UDP 1719

I would be inclined to have the fw logging switched 'on' to see what's going on.

Ajaz

It is a SonicWall FW, i have access to make and update changes to it, and logging is on. Logs show some phase 2 mismatch errors before i got the fasteth0/0.2 to talk to CUCM.

The remote site has 18 phones, and now 3 are are out of fallback mode connected and registered in CUCM, but the other 15 are in fallback mode, and the router is not connecting the incoming line of the PRI to the AutoAttendant on the Unity Server, but goes to the alias configured in the fallback mode.

Where do you think i should check.