MGCP problem with CallManager 4.1(2) <--> 1760

Hi

I'm experiencing troubles with Cisco CallManager 4.1(2) and 1760 router (IOS Version 12.3(11)T3) as a MGCP-gateway. I'm trying to get CM and 1760 to work with MGCP and have succeeded to establish some sort of connection between them (as shown in **debug mgcp packets**). Gateway Configuration in CM also shows "Registered with Cisco CallManager". 1760-gateway has been configured basically from the CM with some commands to router side also (**show running-config**).

My problem is that I have not managed to receive any MGCP packets other than these while trying to call through gateway (debug mgcp packets on) and the call won't go through (I'm using ISDN BRI port and line to connect 1760 to PBX and it should be OK.). I have also created a Route Pattern to CallManager and it should also be correct. Does anyone have any ideas about this? Why won't I see any other MGCP-packets? Why won't call get routed?

sh run, sh isdn status, sh int bri 0/1, debug mgcp packets and sh mgcp

-command outputs are attached.

**1760 show running-config** gwtodx200#sh running-config Building configuration...

Current configuration : 1644 bytes ! version 12.3 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption ! hostname gwtodx200 ! boot-start-marker boot-end-marker ! ! tdm clock bri-auto mmi polling-interval 60 no mmi auto-configure no mmi pvc mmi snmp-timeout 180 voice-card 0 ! no aaa new-model ip subnet-zero ip cef ! ! ! no ftp-server write-enable isdn switch-type basic-net3 ! ! ccm-manager mgcp ccm-manager music-on-hold ccm-manager config server 192.168.9.2 ccm-manager config ! ! interface FastEthernet0/0 ip address 192.168.10.10 255.255.255.0 speed auto ! interface BRI0/0 no ip address shutdown isdn switch-type basic-net3 ! interface BRI0/1 no ip address isdn switch-type basic-net3 isdn tei-negotiation first-call isdn point-to-point-setup isdn incoming-voice voice isdn bind-l3 ccm-manager service mgcp isdn skipsend-idverify ! router eigrp 1234 network 192.168.9.0 network 192.168.10.0 auto-summary ! ip classless ! no ip http server ! ! control-plane ! ! ! voice-port 0/0 ! voice-port 0/1 compand-type a-law cptone FI ! mgcp mgcp call-agent 192.168.9.2 service-type mgcp version 0.1 mgcp dtmf-relay voip codec all mode out-of-band mgcp rtp unreachable timeout 1000 action notify mgcp package-capability rtp-package no mgcp package-capability res-package mgcp package-capability sst-package no mgcp package-capability fxr-package no mgcp timer receive-rtcp mgcp sdp simple mgcp fax t38 inhibit mgcp rtp payload-type g726r16 static ! mgcp profile default ! ! dial-peer voice 1 pots application mgcpapp port 0/1 ! ! line con 0 line aux 0 line vty 0 4 login ! end

**show running-config**

**sh isdn status** Global ISDN Switchtype = basic-net3 ISDN BRI0/0 interface dsl 0, interface ISDN Switchtype = basic-net3 Layer 1 Status: SHUTDOWN Layer 2 Status: Layer 2 NOT Activated Layer 3 Status: 0 Active Layer 3 Call(s) Active dsl 0 CCBs = 0 The Free Channel Mask: 0x00000000

%Q.931 is backhauled to CCM MANAGER 0x0003 on DSL 1. Layer 3 output may not appl y

ISDN BRI0/1 interface dsl 1, interface ISDN Switchtype = basic-net3 L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003 Layer 1 Status: ACTIVE Layer 2 Status: TEI = 65, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED Layer 3 Status: 0 Active Layer 3 Call(s) CCB:callid=800B, sapi=0, ces=1, B-chan=1, calltype=DATA, hdlctype=HDLC-T RUNK Active dsl 1 CCBs = 1 The Free Channel Mask: 0x80000002 Total Allocated ISDN CCBs = 1

**sh isdn status**

**sh int bri 0/1** gwtodx200#sh int bri 0/1 BRI0/1 is up, line protocol is up (spoofing) Hardware is Voice NT or TE BRI MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation VOICE, loopback not set Last input 00:00:05, output never, output hang never Last clearing of "show interface" counters never Input queue: 0/75/2/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: weighted fair Output queue: 0/1000/64/0 (size/max total/threshold/drops) Conversations 0/1/16 (active/max active/max total) Reserved Conversations 0/0 (allocated/max allocated) Available Bandwidth 48 kilobits/sec 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 19903 packets input, 84480 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 2 input errors, 2 CRC, 0 frame, 0 overrun, 0 ignored, 2 abort 16992 packets output, 68549 bytes, 0 underruns 0 output errors, 0 collisions, 9 interface resets 0 output buffer failures, 0 output buffers swapped out 35 carrier transitions

**sh int bri 0/1**'

**debug mgcp packets**

*Mar 7 20:28:40.303: MGCP Packet sent to 192.168.9.2:2427--->

NTFY 12114 *@gwtodx200 MGCP 0.1 X: 0 O:

200 12114

NTFY 12114 *@gwtodx200 MGCP 0.1 X: 0 O:

200 12114
Reply to
cm4121760
Loading thread data ...

Well, not quite sure, but hopefully I can offer some help. At one of my locations, I have a 12 channel PRI into a 1760 - IOS version 123-4.T6. My version of Call Manager is 4.0(2a)sr1. Everything is working fine for me. I haven't used these with a BRI before, so I can't comment a lot on your config. But, generally, it seems okay.

Has anything changed on the router that would break the association? I'd be interested to see what 'show mgcp stat' shows for you. I guess, first, check the obvious. Are you sure you have a route properly set up to send a call to that gateway? Are you successfully getting inbound calls on that device? My hunch is that this is a Call Manager config thing. Perhaps deleting and re-adding the host in Call Manager would bring some things into light.

Jim

line-package

Reply to
Scooby

Also, you could check the ccm traces on the CallManager to see what, if any mgcp messages it's getting back from the router. They are located in C:\program files\cisco\traces\ccm. Use a program like Translator X that can filter based on Q.931, skinny, or mgcp to cut out the extra stuff...the traces can be quite verbose. You might have to configure the trace collection parameters in Serviceability.

Reply to
Majortom

Thanks for your advices. I deleted that gateway and added it back to CM again but that didn't change the situation. I'm quite novice with these things so my problem could also be very simple one... Anyway, here is my mgcp statistics from that gateway. It seems to me like there's some sort of misconfiguration in actual calls between CM and gateway. Gateway is only sending Notify packets to CM in which CM responds with respond code 200, but nothing else shows up when trying to call through it. Do I need to configure some dial-peers to that gateway? Shouldn't it be configured while adding Route Pattern to CallManager?

PBX side hasn't been configured to route calls to my VoIP branch (Directory Numbers 601...699) but a normal ISDN call can be established between two numbers straight from Network Termination point. This call is tested between telephone numbers 5116 and 5140. My gateway, CallManager and IP-phones are now behind number 5140. I have tried this with CM Route Pattern 5XXX and also with single numbers.

gwtodx200#sh mgcp stat UDP pkts rx 16504, tx 16601 Unrecognized rx pkts 0, MGCP message parsing errors 0 Duplicate MGCP ack tx 0, Invalid versions count 0 CreateConn rx 0, successful 0, failed 0 DeleteConn rx 0, successful 0, failed 0 ModifyConn rx 0, successful 0, failed 0 DeleteConn tx 0, successful 0, failed 0 NotifyRequest rx 0, successful 0, failed 0 AuditConnection rx 0, successful 0, failed 0 AuditEndpoint rx 22, successful 16, failed 6 RestartInProgress tx 51, successful 51, failed 0 Notify tx 16437, successful 16437, failed 0 ACK tx 16, NACK tx 6 ACK rx 16462, NACK rx 20

IP address based Call Agents statistics: IP address 192.168.9.2, Total msg rx 16431, successful 16411, failed 20 System resource check is DISABLED. No available statistic gwtodx200#

Reply to
cm4121760

That sort of translation program could be useful. Where can I get that Translator X software? Quick google survey didn't help me...sorry. There is an option "Q931 Translator" in Serviceability, could that do the same? It shows some files but when clicking them it just says "No ISDN Messages in the File". But how to debug mgcp messages? I checked those ccm traces with notepad and here is what it tells when trying to establish a call (192.168.9.6 and 192.168.9.7 are IP-phones):

03/21/2005 11:27:40.984 CCM|ConnectionManager - wait_AuDisconnectRequest(16777547,0): NO ENTRY FOUND IN TABLE| 03/21/2005 11:27:51.843 CCM|ConnectionManager - wait_AuDisconnectRequest(16777551,0): NO ENTRY FOUND IN TABLE|

Seems like something is missing..?

Reply to
cm4121760

ISDN debugs also shows that something is definately coming to gateway while having inbound call but there seems to be no reaction to it. What kind of configuration would allow calls to pass gateway also? Cisco is saying here

formatting link
you can not use destination-pattern or session target commands with mgcp configuration. What is the way to do this differently? I've fought with this quite a while now and fresh ideas would be more than welcome ;)

gwtodx200#deb isdn q921 debug isdn q921 is ON. gwtodx200#deb isdn q931 debug isdn q931 is ON. gwtodx200#deb isdn events debug isdn event is ON. gwtodx200#

*Mar 11 23:10:20.113: ISDN BR0/1 Q921: User RX
Reply to
cm4121760

This tells me that the call manager is not using this as the gateway (ie call manager config problem). Otherwise, you would see stats in the CreateConn, DeleteConn and ModifyConn fields. The fact that you are getting successful AuditEndpoint packets indicates that the gateway is set up properly - just the routing rules most likely are not.

Jim

MULTIPLE_FRAME_ESTABLISHED

Reply to
Scooby

I'm not an expert on mgcp commands, by any stretch. But, I think all you really need at a minimum is something like this:

ccm-manager config server 192.168.9.2 ccm-manager config ccm-manager mgcp

mgcp mgcp call-agent 192.168.9.2 service-type mgcp version 0.1

mgcp profile default

dial-peer voice 1 pots application mgcpapp port 0/1

Also the bind-l3 in the serial interface is needed, but you already have that.

That should be enough to at least get the router talking with the call manager for inbound calls. You do seem to have that in place. Perhaps you should do the debug mgcp on the inbound calls too, to see what is happening. You will need a rule on the call manager to tell it what to do with the call.

Hope that helps,

Jim

formatting link
that you can not use destination-pattern or session target commands

Reply to
Scooby

Actually, there is an even better translator....but you need a CCO account to get it from Cisco.

formatting link

Reply to
Majortom

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.