Solved: MGCP Gateway problem

nunoscosta · ‎06-28-2010

Hi guys,

I have a problem with one CUCM cluster, each node is in different locations connect with l2 fiber (distributed cluster).

Each site have it's own voice gateway connected to ISDN PRI line.

The problem that i am facing is one of the sites are not making calls to the outside world, using the local gateway, the user receives a busy tone when try to make calls, but they can receive calls from outside.

Call Manager version7.0
ROUTER with (C2800NM-IPVOICEK9-M)
E1 interface

The voice gateway relevant config is:

!---------------------------------------

isdn switch-type primary-net5

voice-card 0
no dspfarm

controller E1 0/0/0
pri-group timeslots 1-31 service mgcp

ccm-manager redundant-host 10.88.11.1 10.88.31.1
ccm-manager mgcp
ccm-manager music-on-hold
ccm-manager config server 10.88.11.1 10.88.21.1 10.88.31.1
ccm-manager config
!
mgcp
mgcp call-agent 10.88.21.1 service-type mgcp version 0.1
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
mgcp package-capability sst-package
mgcp package-capability pre-package
no mgcp package-capability res-package
no mgcp package-capability fxr-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp rtp payload-type g726r16 static
!
mgcp profile default

!---------------------------------------

Some output commands

VOICE#sh controller e1
E1 0/0/0 is up.
Applique type is Channelized E1 - balanced
Cablelength is Unknown
No alarms detected.
alarm-trigger is not set
Version info Firmware: 20071011, FPGA: 13, spm_count = 0
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
Data in current interval (407 seconds elapsed):
     0 Line Code Violations, 0 Path Code Violations
     20 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
     20 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Total Data (last 7 15 minute intervals):
     0 Line Code Violations, 6 Path Code Violations,
     307 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins,
     307 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 10 Unavail Secs

VOICE#sh ccm-manager
MGCP Domain Name: CV_VGTW
Priority        Status                   Host
============================================================
Primary         Registered               10.88.21.1
First Backup    Backup Ready             10.88.11.1
Second Backup   Backup Ready             10.88.31.1

Current active Call Manager:    10.88.21.1
Backhaul/Redundant link port:   2428
Failover Interval:              30 seconds
Keepalive Interval:             15 seconds
Last keepalive sent:            12:47:53 WEST Jun 28 2010 (elapsed time: 00:00:12)
Last MGCP traffic time:         12:47:53 WEST Jun 28 2010 (elapsed time: 00:00:12)
Last failover time:             12:45:10 WEST Jun 28 2010 from (10.88.21.1)
Last switchback time:           12:45:25 WEST Jun 28 2010 from (10.88.31.1)
Switchback mode:                Graceful
MGCP Fallback mode:             Not Selected
Last MGCP Fallback start time: None
Last MGCP Fallback end time:    None
MGCP Download Tones:            Disabled
TFTP retry count to shut Ports: 2

Backhaul Link info:
    Link Protocol:      TCP
    Remote Port Number: 2428
    Remote IP Address: 10.88.21.1
    Current Link State: OPEN
    Statistics:
        Packets recvd:   4
        Recv failures:   0
        Packets xmitted: 4
        Xmit failures:   0
    PRI Ports being backhauled:
        Slot 0, VIC 0, port 0
Configuration Auto-Download Information
=======================================
Current version-id: 1267623651-ea7f8b90-1293-47f5-b45e-d0417ac1c91f
Last config-downloaded:00:00:00
Current state: Waiting for commands
Configuration Download statistics:
        Download Attempted             : 6
          Download Successful          : 6
          Download Failed              : 0
          TFTP Download Failed         : 0
        Configuration Attempted        : 2
          Configuration Successful     : 2
          Configuration Failed(Parsing): 0
          Configuration Failed(config) : 0
Last config download command: New Registration
FAX mode: cisco
Configuration Error History:

VOICE#sh isdn status
Global ISDN Switchtype = primary-net5

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

ISDN Serial0/0/0:15 interface
        dsl 0, interface ISDN Switchtype = primary-net5
        L2 Protocol = Q.921 0x0000 L3 Protocol(s) = CCM MANAGER 0x0003
    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: 0xFFFF7FFF
    Number of L2 Discards = 0, L2 Session ID = 6
    Total Allocated ISDN CCBs = 0

VOICE#sh mgcp profile
MGCP Profile default
Description: None
Call-agent: 10.88.21.1 Initial protocol service is MGCP 0.1
Tsmax timeout is 20 sec, Tdinit timeout is 15 sec
Tdmin timeout is 15 sec, Tdmax timeout is 600 sec
Tcrit timeout is 4 sec, Tpar timeout is 16 sec
Thist timeout is 30 sec, MWI timeout is 16 sec
Ringback tone timeout is 180 sec, Ringback tone on connection timeout is 180 sec
Network congestion tone timeout is 180 sec, Busy tone timeout is 30 sec
Network busy tone timeout is 0 sec
Dial tone timeout is 16 sec, Stutter dial tone timeout is 16 sec
Ringing tone timeout is 180 sec, Distinctive ringing tone timeout is 180 sec
Continuity1 tone timeout is 3 sec, Continuity2 tone timeout is 3 sec
Reorder tone timeout is 30 sec, Persistent package is ms-package
Max1 DNS lookup: ENABLED, Max1 retries is 5
Max2 DNS lookup: ENABLED, Max2 retries is 7
Source Interface: NONE
T3 endpoint naming convention is T1
prefer active call-agent is DISABLED
CAS Notification Digit order is Default

In CUCM i see the gateway registered with the correct endpoint, the configuration is the same for all sites (CUCM nodes and gateways).

What is the problem? Who can i find the mistake here?

Thank you in advance,

NC

Md. Mijanur Rahman · ‎06-28-2010

That's simple! That's because your gateway can't recognize the network anymore! I can see the disconnect cause=82

You can find the detail of 'Disconnect Cause = 82' from this document:

http://www.cisco.com/en/US/partner/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml

However i'm quoting it from the doc:

82

No route to specified network

The ISDN exchange receives a request to route the call through an unrecognized intermediate network.

This cause indicates that the equipment receives a request to route the call through a particular transit network. However, the equipment does not recognize the network.

The equipment that sends this cause does not recognize the transit network due to one of these reasons:

The transit network does not exist.
The transit network exists, but does not serve the equipment that sends this cause.

This cause is supported on a network-dependent basis.

There might be some changes/modifications on your service provider side and your gateway is not recognizing the network anymore. Please call the Service Provider and raise the issue to them, everything is fine from your end! And yalso ou should have redundant/backup route to PSTN through another site gateway so that users can have uninterrupted service.

HTH.

Please rate helpful posts!

View solution in original post

Abu Hadee · ‎06-28-2010

Hi

Since MGCP is a slave device, most of the issue is related to CUCM configuration.

Will you be able to collect following from the gw while making outbound call?

debug mgcp packet

debug isdn q931

thanks

- abu

nunoscosta · ‎06-28-2010

Hi Abu Hadee,

The debug from mgcp packet is:

000643: *Jun 28 13:31:49.402: MGCP Packet sent to 10.88.21.1:2427--->
NTFY 458624249 *@VGTW MGCP 0.1
X: 0
O:
<---

000644: *Jun 28 13:31:49.402: MGCP Packet received from 10.88.21.1:2427--->
200 458624249
<---

000645: *Jun 28 13:32:04.402: MGCP Packet sent to 10.88.21.1:2427--->
NTFY 458624250 *@VGTW MGCP 0.1
X: 0
O:
<---

000646: *Jun 28 13:32:04.402: MGCP Packet received from 10.88.21.1:2427--->
200 458624250
<---

000647: *Jun 28 13:32:19.402: MGCP Packet sent to 10.88.21.1:2427--->
NTFY 458624251 *@VGTW MGCP 0.1
X: 0
O:
<---

000648: *Jun 28 13:32:19.402: MGCP Packet received from 10.88.21.1:2427--->
200 458624251
<---

The debug from isdn q931 INBOUND is:

000733: *Jun 28 13:40:36.994: ISDN Se0/0/0:15 Q931: RX <- SETUP pd = 8 callref = 0x00C8
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA18395
                Preferred, Channel 21
        Calling Party Number i = 0x00A3, N/A
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0xA1, '919020'
                Plan:ISDN, Type:National
000734: *Jun 28 13:40:37.026: ISDN Se0/0/0:15 Q931: TX -> CALL_PROC pd = 8 callref = 0x80C8
        Channel ID i = 0xA98395
                Exclusive, Channel 21
000735: *Jun 28 13:40:37.030: ISDN Se0/0/0:15 Q931: TX -> ALERTING pd = 8 callref = 0x80C8
        Progress Ind i = 0x8088 - In-band info or appropriate now available
000736: *Jun 28 13:40:39.562: ISDN Se0/0/0:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x00C8
        Cause i = 0x8090 - Normal call clearing
000737: *Jun 28 13:40:39.598: ISDN Se0/0/0:15 Q931: TX -> RELEASE pd = 8 callref = 0x80C8
000738: *Jun 28 13:40:39.622: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x00C8

The debug from isdn q931 OUTBOUND does not show on the router, because the CUCM is not placing the outbound calls on the router

Thanks in advance,

NC

Md. Mijanur Rahman · ‎06-28-2010

Hi, the problem is not on your gateway side so far I understood. Please check the followings on CUCM:

- Are you using 'Standard Local Gateway' on the route list? if YES, please check if you have configured proper local route group on that Device Pool (I hope you have seperate device pool for that site)

- Check proper CSS for the phones if they are allowed to call outside

- Can you please confirm if you are getting busy tone after the call information is passed through the PRI, please post the 'debug isdn q931' debugs if any.

- If everything goes OK, have a 'no mgcp' and right after 'mgcp' command to bounce the MGCP process.

HTH.

nunoscosta · ‎06-28-2010

Hi Mijanur Rahman,

I do not have a local group defined on any device pool, this is the only site taht is not working.

The MGCP gateway was configured from the list in the CUCM.

I have one device pool for each site and one routing group for each site as well.

All users have full permissions, there is no css is blocking outbound calls.

I have changed the call agent and no mgcp and mgcp commands many times without success.

Md. Mijanur Rahman · ‎06-28-2010

'I have one device pool for each site and one routing group for each site as well.'

I hope you have put the correct gateway inside the Route Group you mentioned, please reset the Route List once where the Route Group is associated.

Do you have any 'debug isdn q931' log during call attempts? The PSTN might reject your call through the PRI for incorrect number pattern, type and plan. If you have any log for 'debug isdn q931' please post them also.

HTH.

Abu Hadee · ‎06-28-2010

OK, it is established that CUCM is not sending the call to GW. So it must be CUCM configuration. So follow the steps

1. What is the CSS of the Phone (device and line) ?
2. What partitions are assigned to these CSSs

3. Which partition did you put the Route-pattern?

4. Do you use router-list or the MGCP End point directly

5. If you have route list, what is name of the route-list, route-group and MGCP end point?

6. What location is defined on the MGCP GW and Phone?

7. When you dial from the phone, does it allow you to complete the number or you get busy tone before you complete?

To minimize the configuration issue, do the following

1. Remove any location from Phone and MGCP GW

2. Remove the partition from the route-pattern

3. Remove the MGCP GW from the route-group, and assign the MGCP GW directly to the route-pattern

If you can collect cucm trace for the outgoing call, will be good.

Thank you

- abu

nunoscosta · ‎06-28-2010

Hi,

Debug from ISDN Q931, it seens that CUCM is placing outbound calls

000794: *Jun 28 14:07:06.256: ISDN Se0/0/0:15 Q931: TX -> SETUP pd = 8 callref = 0x0002
        Sending Complete
        Bearer Capability i = 0x8090A3
                Standard = CCITT
                Transfer Capability = Speech
                Transfer Mode = Circuit
                Transfer Rate = 64 kbit/s
        Channel ID i = 0xA98381
                Exclusive, Channel 1
        Calling Party Number i = 0x0081, '432'
                Plan:Unknown, Type:Unknown
        Called Party Number i = 0x80, '253917267'
                Plan:Unknown, Type:Unknown
000795: *Jun 28 14:07:06.296: ISDN Se0/0/0:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x8002
        Cause i = 0x82AC - Requested circuit/channel not available
        Display i = 'REQUESTED CHANNEL NOT AVAILABLE'

thanks!

best regards,

NC

Md. Mijanur Rahman · ‎06-28-2010

That's simple! That's because your gateway can't recognize the network anymore! I can see the disconnect cause=82

You can find the detail of 'Disconnect Cause = 82' from this document:

http://www.cisco.com/en/US/partner/tech/tk801/tk379/technologies_tech_note09186a008012e95f.shtml

However i'm quoting it from the doc:

82

No route to specified network

The ISDN exchange receives a request to route the call through an unrecognized intermediate network.

This cause indicates that the equipment receives a request to route the call through a particular transit network. However, the equipment does not recognize the network.

The equipment that sends this cause does not recognize the transit network due to one of these reasons:

The transit network does not exist.
The transit network exists, but does not serve the equipment that sends this cause.

This cause is supported on a network-dependent basis.

There might be some changes/modifications on your service provider side and your gateway is not recognizing the network anymore. Please call the Service Provider and raise the issue to them, everything is fine from your end! And yalso ou should have redundant/backup route to PSTN through another site gateway so that users can have uninterrupted service.

HTH.

Please rate helpful posts!

nunoscosta · ‎06-28-2010

Thank you all for HELP!!!

Best Regards,

NC