Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
2834
Views
10
Helpful
5
Replies

VG310 MGCP FXS Port Unregisters

Go to solution
RL5901
Level 1
Level 1

‎04-28-2022 03:24 PM

I have a new VG310 configured using MGCP as the protocol. Half of the FXS ports (ports 0/0/12 through 0/0/23) are configured (loop-start) and registered just fine. However, the first 12 ports (0/0/0 through 0/0/11) are having trouble staying registered. 

 

What happens...

  1. A port (e.g., 0/0/0) is configured in CUCM
    1. Both Loop-Start and POTS were both tried with the same results
  2. The device (i.e., a fax machine) is connected to the port (e.g., 0/0/0)
  3. The port registers and is assigned the correct IP address
  4. The port unregisters

Using a butt-set, the port was configured and dial-tone could be heard but then suddenly stops (port unregisters) and does not produce dial-tone again unless the config in CUCM for the port is deleted and recreated (which just repeats the adverse symptoms).

 

I have a TAC case open but the TAC engineer is not responsive and provides no updates when asked. I've come here to see if anyone can tell me definitively what my debugs show. My cable tech swears he has checked the wiring and cabling twice (on the Amphenol and cabling to the fax). I'm not sure what else would result in the debugs showing a config file being pushed to port 0/0/5 when I was configuring 0/0/0. Port 0/0/5 is not configured at all in CUCM. 

 

Debugs...

MGCP:
Media Gateway Control Protocol events debugging is on, trace level Verbose
Media Gateway Control Protocol errors debugging is on
Media Gateway Control Protocol packets debugging is on
Call Manager:
Call Manager events debugging is on
Call Manager errors debugging is on
Call Manager config events debugging is on
Call Manager config errors debugging is on

 

A snippet from the debugs is attached with IP addresses and domains changed.

Labels:
Preview file
5 KB
0 Helpful
2 Accepted Solutions

Accepted Solutions

Go to solution
Scott Leport
Level 7
Level 7
In response to RL5901

‎05-03-2022 04:15 AM 

ip host CM1 10.X.X.2 <--note that this is CM3's IP address but CM1's name

I would suggest removing this config as it creates a static DNS entry, and an incorrect one at that.

 

ccm-manager config server 10.X.X.10 <--shouldn't this be the 1st CUCM in the CM Group, which would be 10.X.X.1

As per the Command Reference guide, the ccm-manager config server command specifies the IP address of the TFTP server from which the XML config files are downloaded. If 10.X.X.10 is a TFTP server, that should be fine.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-c4.html#wp1337836707

 

Could the CM Group not matching the VG310 configuration be the problem with maintaining registration for these ports? I've never seen where a port is configured on CUCM and the VG is requesting a file for the wrong port before. Let me know if you need to review the full config and I'll mask off the identifying info and align it with the example and debugs (masked).

No, I don't think the CM Group would be an issue, but I would tend to ensure registration on the VG matches up with the CM Group as it will keep it straight in your head. No I haven't seen this issue either and that's why I was asking if you make a call from port 0/0/0, does the output reflect that port 0/0/0 has the call?

 

The config would help, but I think there are a few things to go after here first, such as removing the host entry and ensuring the config server is pointing to a node with the TFTP service enabled.

View solution in original post

0 Helpful

Go to solution
RL5901
Level 1
Level 1
In response to Scott Leport

‎05-03-2022 10:11 AM

Here's what I did to fix the MGCP VG310. 

  1. Fixed the ip host line with the correct IP address
    1. VG310(config)# no ip host CM1 10.X.X.2
    2. VG310(config)# ip host CM1 10.X.X.10
  2. Disabled MGCP
    1. VG310(config)# no mgcp
  3. Removed the dial-peers
    1. VG310(config)# no dial-peer voice 999xxx pots (for each line)
  4. Removed the ccm-manager commands 
    1. VG310(config)# no ccm-manager config server X.X.X.X (where X.X.X.X is the config server's IP address)
    2. VG310(config)# no ccm-manager config
  5. Added the ccm-manager commands
    1. VG310(config)# ccm-manager config server X.X.X.X (where X.X.X.X is the config server's IP address)
    2. VG310(config)# ccm-manager config
  6. Enabled MGCP
    1. VG310(config)# mgcp
  7. Reloaded the VG310

The ports that were registered before (ports 0/0/12 through 0/0/23) were in a Rejected state.

 

I then added the other 2 CUCM subscribers that were in the CUCM config to the ip host section...

  1. VG310(config)# ip host CM2 10.X.X.1
  2. VG310(config)# ip host CM3 10.X.X.2

The ports registered (to CM2), including the first 12 ports that would not retain their registration (ports 0/0/0 through 0/0/11). Dial-tone has been confirmed. Thank you for your assistance and guidance! 

View solution in original post

5 Replies 5

Go to solution
Scott Leport
Level 7
Level 7

‎04-29-2022 04:44 AM - edited ‎04-29-2022 04:45 AM

Hi,

 

Do you have the voice ports attached to the correct dial-peers?

Do you have all of the PVDMs installed in the VG too?

If you make a call from port 0/0/0 and issue "show voice call status", is port 0/0/0 shown as having the call, or is it port 0/0/5?

 

Difficult to say without seeing your config. Would you mind sharing it, removing any sensitive info of course?

0 Helpful

Go to solution
RL5901
Level 1
Level 1

‎05-02-2022 09:40 AM

A colleague of mine originally configured this VG310 before moving to another team. He then went on a 3 week vacation. I was asked to look into why the first 12 ports won't register and I'm making a lot of assumptions about this VG's configs. However, there may be some issues with that config that I'm working through as time permits. 

 

I looked through both the debugs, the CUCM MGCP gateway config, and the config on the VG310. 

 

The CUCM configuration

The VG310 is configured as an MGCP gateway in CUCM. CM Group assigned is CM231. The CM Group membership for CM231 is CM2, CM3, CM1 (in that order). IP addresses  for this example (these are not the real IP addresses) are given as...

CM2 = 10.X.X.1 (Subscriber 1)

CM3 = 10.X.X.2 (Subscriber 2)

CM1 = 10.X.X.10 (Publisher)

 

The VG310 running configuration (these are only snippets of the config)

ip host CM1 10.X.X.2 <--note that this is CM3's IP address but CM1's name

 

mgcp

mgcp call-agent CM2.ourdomain.org 2427 service-type mgcp version 0.1 <--this is in line with the CM Group CM231
ccm-manager redundant-host CM3.ourdomain.org CM1.ourdomain.org <--this looks fine, also
ccm-manager config server 10.X.X.10 <--shouldn't this be the 1st CUCM in the CM Group, which would be 10.X.X.1

 

!!!! voice ports (0/0/0 through 0/0/23) are all cptone C2
voice-port 0/0/0
cptone C2
!
!!!!...etc.

 

!!!!dial-peers (999000 through 9990023) are all service mgcpapp with the correct ports (0/0/0 through 0/0/23)
dial-peer voice 999000 pots
service mgcpapp
port 0/0/0
!

!!!!...etc.

 

In the Debugs
The VG310 is requesting the config files from 10.X.X.1 (CM2, Subscriber 1) and not 10.X.X.10 (CM1, Publisher). When configuring MGCP port 0/0/0 in CUCM I see the endpoint name as 0/0/5 (Endpoint is [AALN/S0/SU0/5@VG310.ourdomain.org]). 

 

Show commands

VG310#sh mgcp
MGCP Admin State ACTIVE, Oper State ACTIVE - Cause Code NONE
MGCP call-agent: CM2.ourdomain.org 2427 Initial protocol service is MGCP 0.1

 

VG310#sh voice port summ
IN OUT
PORT CH SIG-TYPE ADMIN OPER STATUS STATUS EC
=============== == ============ ===== ==== ======== ======== ==
0/0/0 -- fxs-ls up dorm on-hook idle y
0/0/1 -- fxs-ls up dorm on-hook idle y
0/0/2 -- fxs-ls up dorm on-hook idle y
0/0/3 -- fxs-ls up dorm on-hook idle y
0/0/4 -- fxs-ls up dorm on-hook idle y
0/0/5 -- fxs-ls up dorm on-hook idle y
0/0/6 -- fxs-ls up dorm on-hook idle y
0/0/7 -- fxs-ls up dorm on-hook idle y
0/0/8 -- fxs-ls up dorm on-hook idle y
0/0/9 -- fxs-ls up dorm on-hook idle y
0/0/10 -- fxs-ls up dorm on-hook idle y
0/0/11 -- fxs-ls up dorm on-hook idle y
0/0/12 -- fxs-ls up dorm on-hook idle y
0/0/13 -- fxs-ls up dorm on-hook idle y
0/0/14 -- fxs-ls up dorm on-hook idle y
0/0/15 -- fxs-ls up dorm on-hook idle y
0/0/16 -- fxs-ls up dorm on-hook idle y
0/0/17 -- fxs-ls up dorm on-hook idle y
0/0/18 -- fxs-ls up dorm on-hook idle y
0/0/19 -- fxs-ls up dorm on-hook idle y
0/0/20 -- fxs-ls up dorm on-hook idle y
0/0/21 -- fxs-ls up dorm on-hook idle y
0/0/22 -- fxs-ls up dorm on-hook idle y
0/0/23 -- fxs-ls up dorm on-hook idle y

 

VG310#sh mgcp endpoint
aaln/S0/SU0/0@VG310
aaln/S0/SU0/1@VG310
aaln/S0/SU0/2@VG310
aaln/S0/SU0/3@VG310
aaln/S0/SU0/4@VG310
aaln/S0/SU0/5@VG310
aaln/S0/SU0/6@VG310
aaln/S0/SU0/7@VG310
aaln/S0/SU0/8@VG310
aaln/S0/SU0/9@VG310
aaln/S0/SU0/10@VG310
aaln/S0/SU0/11@VG310
aaln/S0/SU0/12@VG310
aaln/S0/SU0/13@VG310
aaln/S0/SU0/14@VG310
aaln/S0/SU0/15@VG310
aaln/S0/SU0/16@VG310
aaln/S0/SU0/17@VG310
aaln/S0/SU0/18@VG310
aaln/S0/SU0/19@VG310
aaln/S0/SU0/20@VG310
aaln/S0/SU0/21@VG310
aaln/S0/SU0/22@VG310
aaln/S0/SU0/23@VG310

 

VG310#sh ccm-manager
MGCP Domain Name: VG310.ourdomain.org
Priority Status Host
============================================================
Primary Registered CM2.ourdomain.org (10.X.X.1)
First Backup Backup Ready CM3.ourdomain.org (10.X.X.2)
Second Backup Backup Ready CM1.ourdomain.org (10.X.X.10)

Current active Call Manager: 10.X.X.1
Backhaul/Redundant link port: 2428
Failover Interval: 30 seconds
Keepalive Interval: 15 seconds
Last keepalive sent: 11:32:36 CST May 2 2022 (elapsed time: 00:00:11)
Last MGCP traffic time: 11:32:36 CST May 2 2022 (elapsed time: 00:00:11)
Last failover time: 11:48:32 central Feb 25 2022 from (10.X.X.1)
Last switchback time: 11:48:47 central Feb 25 2022 from (10.X.X.2)
Switchback mode: Graceful
MGCP Fallback mode: Not Selected
Last MGCP Fallback start time: None
Last MGCP Fallback end time: None
MGCP Download Tones: Enabled
Custom Tone 1 : Default (United States)
Custom Tone 2 : United States
TFTP retry count to shut Ports: 2

Configuration Auto-Download Information
=======================================
No configurations downloaded
Current state: Downloading XML file
Configuration Download statistics:
Download Attempted : 37
Download Successful : 34
Download Failed : 0
TFTP Download Failed : 17737
Configuration Attempted : 33
Configuration Successful : 32
Configuration Failed(Parsing): 0
Configuration Failed(config) : 0
Last config download command:
FAX mode: disable
Configuration Error History:

 

Could the CM Group not matching the VG310 configuration be the problem with maintaining registration for these ports? I've never seen where a port is configured on CUCM and the VG is requesting a file for the wrong port before. Let me know if you need to review the full config and I'll mask off the identifying info and align it with the example and debugs (masked). 

0 Helpful

Go to solution
Scott Leport
Level 7
Level 7
In response to RL5901

‎05-03-2022 04:15 AM 

ip host CM1 10.X.X.2 <--note that this is CM3's IP address but CM1's name

I would suggest removing this config as it creates a static DNS entry, and an incorrect one at that.

 

ccm-manager config server 10.X.X.10 <--shouldn't this be the 1st CUCM in the CM Group, which would be 10.X.X.1

As per the Command Reference guide, the ccm-manager config server command specifies the IP address of the TFTP server from which the XML config files are downloaded. If 10.X.X.10 is a TFTP server, that should be fine.

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/voice/vcr1/vcr1-cr-book/vcr-c4.html#wp1337836707

 

Could the CM Group not matching the VG310 configuration be the problem with maintaining registration for these ports? I've never seen where a port is configured on CUCM and the VG is requesting a file for the wrong port before. Let me know if you need to review the full config and I'll mask off the identifying info and align it with the example and debugs (masked).

No, I don't think the CM Group would be an issue, but I would tend to ensure registration on the VG matches up with the CM Group as it will keep it straight in your head. No I haven't seen this issue either and that's why I was asking if you make a call from port 0/0/0, does the output reflect that port 0/0/0 has the call?

 

The config would help, but I think there are a few things to go after here first, such as removing the host entry and ensuring the config server is pointing to a node with the TFTP service enabled.

0 Helpful

Go to solution
RL5901
Level 1
Level 1
In response to Scott Leport

‎05-03-2022 10:11 AM

Here's what I did to fix the MGCP VG310. 

  1. Fixed the ip host line with the correct IP address
    1. VG310(config)# no ip host CM1 10.X.X.2
    2. VG310(config)# ip host CM1 10.X.X.10
  2. Disabled MGCP
    1. VG310(config)# no mgcp
  3. Removed the dial-peers
    1. VG310(config)# no dial-peer voice 999xxx pots (for each line)
  4. Removed the ccm-manager commands 
    1. VG310(config)# no ccm-manager config server X.X.X.X (where X.X.X.X is the config server's IP address)
    2. VG310(config)# no ccm-manager config
  5. Added the ccm-manager commands
    1. VG310(config)# ccm-manager config server X.X.X.X (where X.X.X.X is the config server's IP address)
    2. VG310(config)# ccm-manager config
  6. Enabled MGCP
    1. VG310(config)# mgcp
  7. Reloaded the VG310

The ports that were registered before (ports 0/0/12 through 0/0/23) were in a Rejected state.

 

I then added the other 2 CUCM subscribers that were in the CUCM config to the ip host section...

  1. VG310(config)# ip host CM2 10.X.X.1
  2. VG310(config)# ip host CM3 10.X.X.2

The ports registered (to CM2), including the first 12 ports that would not retain their registration (ports 0/0/0 through 0/0/11). Dial-tone has been confirmed. Thank you for your assistance and guidance! 

Go to solution
Scott Leport
Level 7
Level 7
In response to RL5901

‎05-03-2022 11:40 AM

Great to hear it’s working now. What you did is sometimes the right approach to fix this kind of problem, evidently that being the case here. At least you know it’s configured correctly now. 

All the best. 

Customers Also Viewed These Support Documents