IP Phone keeps ringing forever after incoming call on FXO Port, MGCP

[nascoentr]

Hello,

I am practicing the MGCP config and i have a problem with calls inbound from the PSTN to the FXO Port (0/0/0) on my router (Cisco 2821), when a call is made to my FXO Port from the PSTN the call is directed to the Attendant DN that i configured under the FXO Endpoint I setup in the CUCM 7.0 and the Attendant DN is 1003 that points to an IP Phone on my network (all IP Phones are in the range 1xxx), the call eventually goes fine and my IP Phone on extension 1003 rings but I have two major problems:

a) I'm calling from my mobile (on the PSTN) to the FXO port and after it rings once for me on my mobile phone the line gets connected and i can hear a dial tone for 10 secs exactly (similar to a dial tone when you pick up a phone to dial a number) and my cell minutes are already being used and then after exactly 10 secs i can hear the ringing of the remote phone on my mobile phone and can also see the ip phone start ringing as well.

b) now as a continuation to the problem (a), once my ip phone starts ringing and if i happen to hang up my mobile phone, the ip phone keeps ringing forever....

I bound 2 ports to call manager using the following dial-peers:

- FXO

dial-peer voice 1 pots

service MGCPAPP

port 0/0/0

- FXS

dial-peer voice 2 pots

service MGCPAPP

port 0/1/0

I have a route pattern in the call mananger for 9.!# that is directed out the EndPoint 0/0/0 of the MGCP gateway registered in CUCM and also have the Discard Digits set to "Pre Dot" and the Provide Outside Dial Tone, calls go fine from inside to the PSTN....

I've pasted the config of my router below:

Any help will be much appreciated (Note: I added the tone ringback alert-no-PI under the FXO Port 0/0/0 as i read an article somewhere that it would solve the "forever ringing" problem)

hostname GATEWAY
ip source-route
ip cef
ip dhcp excluded-address 192.168.1.1 192.168.1.20
ip dhcp pool lab
   network 192.168.1.0 255.255.255.0
   option 150 ip 192.168.1.10
   default-router 192.168.1.1
   dns-server 192.168.1.5
   domain-name voice.lab.local
ip domain name voice.lab.local
ip name-server 192.168.1.5
no ipv6 cef
voice-card 0
application
global
  service alternate default
username cisco password 0 cisco
archive
log config
  hidekeys
interface GigabitEthernet0/0
no ip address
duplex auto
speed auto
!

interface GigabitEthernet0/1
ip address 192.168.1.1 255.255.255.0
duplex auto
speed auto
!
voice-port 0/0/0
echo-cancel coverage 64
timeouts call-disconnect 1
timeouts wait-release 1
timing hookflash-out 50
caller-id enable
!
voice-port 0/0/1
!
voice-port 0/1/0
ring cadence pattern12
timeouts initial 20
timeouts interdigit 20
station-id name fawaz
caller-id enable
!
voice-port 0/1/1
!
ccm-manager mgcp
no ccm-manager fax protocol cisco
ccm-manager music-on-hold
ccm-manager config server 192.168.1.10
ccm-manager config
!
mgcp
mgcp call-agent 192.168.1.10 2427 service-type mgcp version 0.1
mgcp modem passthrough voip mode nse
mgcp package-capability rtp-package
mgcp package-capability sst-package
mgcp package-capability pre-package
mgcp default-package mt-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp fax t38 inhibit
!
mgcp profile default
!
!
!
dial-peer voice 1 pots
service mgcpapp
port 0/1/0
!
dial-peer voice 2 pots
tone ringback alert-no-PI
service mgcpapp
port 0/0/0
!
dial-peer voice 999010 pots
service mgcpapp
port 0/1/0
!
dial-peer voice 999000 pots
service mgcpapp
port 0/0/0
!
!
!
alias exec s show ip interface brief
!
line con 0
password cisco
line aux 0
line vty 0 4
login local
!
scheduler allocate 20000 1000
end

[Michael Odom]

I'm not really sure about your first problem, however, resetting the FXO port and the gateway in CUCM might help.  Usually when MGCP is acting wierd, resetting everything usually fixes it.

For your second problem, I've seen that a few times.  Cisco FXO ports pickup the phone on the first ring detect and then generate their own ringback while the IP phone is being signaled.  If the remote end hangs up the FXO port is expecting to get a battery-reversal indicating the disconnect.  If it doesn't get the battery-reversal the port does not know the line has been disconnected and continues to signal the phone.  Contact your telephone provider and ask them to add disconnect supervision to the line.

An easy way to test your line for disconnect supervision is to hook up a test set (or an analog telephone) directly to the phone line.  Place a call to or from that line to another phone (like your cell phone), it doesn't matter which direction you place the call.  Hang up the remote end, but keep listening on the phone line.  If you hear a click followed by a dialtone then you have the battery-reversal disconnect supervision enabled.  If not you'll just hear dead air.  Don't listen for too long to the dead air because the telco will play a off-hook tone which can be loud.

[nascoentr]

Thanks Michael,

I'll try the test with the analog phone and get back, the connection plar opx .... immediate works fine with the H.323 on calls inbound fromt the PSTN but i'll read more on the battery reversal concept before i call up my telephone provider cause i dont expect much help from them.

isn't there a way for us to configure the battery reversal locally on the router to indicate that if the line does not receive any voltage anymore from the telco then shut it or something... hope i'm not off beat here....

[Michael Odom · Accepted solution]

If the connection plar .... command is effective, then MGCP is not working.  When MGCP is involved, CUCM manages everything about the call setup, so all of the H.323 commands are ineffective.  Because you have the "service alternate default" command defined, then H.323 processing takes over in the event that MGCP is down.

The disconnect supervision is something that you have to get from the phone company.  I have looked into trying to do something fancy in the gateways to detect the absence of the ring, but never figured it out.  Plus, you still have the problem if someone leaves an IP phone off-hook and the remote end disconnects.  Additionally, if you are using voicemail or some other automated system, it won't get notified to hang up, and you can have some interesting things happen.

[nascoentr]

yup, but i dont have the connection plar in place while testing the MGCP commands,

i happened to have come across a very well explained article on the FXO Port Disconnect issues that would point out what you stated earlier to have the Telco send a supervisory disconnect signal on the line to indicate that the calling part has gone On Hook.

http://www.cisco.com/en/US/tech/tk652/tk653/technologies_tech_note09186a00800ae2d1.shtml

basically tried everything, timeouts, battery reversal, i changed the FXO EndPoint of the Gateway registered in CUCM to use Ground Start and then tried the groundstart signalling auto-tip but nothing works out......

Hope someone out there has a better idea that has worked for them in this scenario, i'll be calling up the Telco to see if they can help me with it...

Thanks Michael for the tips...

[nascoentr]

did'nt know this thread existed a few threads below mine, might help to adjust the cadence and frequency, i'll check it out...

https://supportforums.cisco.com/thread/2031870?tstart=0

[nascoentr]

finally..... works...

tried the below and it works like a sharpner....

http://ciscoflair.blogspot.com/2009/05/cisco-fxo-disconnect-issue.html

thanks michael, your initial help led me to this article eventually so i'm marking you for the answer.

[nascoentr]

another helpfull link for all those with the same issue....

https://supportforums.cisco.com/thread/2015739

[garrett_low]

nascoentr,

I am experiencing the first problem you identified above, where callers from outside hearing dial tone before it rings the far end.  I was just wondering, did you ever get a solution for this problem?

garrett_low

[Ivan Prikhodko]

Hello Guys,

now I have the same issue with my 2911(FXO) - CUCM 8.5 - VG-224(FXS) scheme, each time somebody call to FXO line, there are 15 sec delay before the attendant DN begin ringing. In case I change the DN to another - the problem is gone.

So the configuration on different DN's is absolutely the same.

PLEASE HELP! any thought will be highly appreciated!

Best regards,

Ivan.

[sharafqudimi]

I have the same problem.

Please help me

[Roger Kallberg]

As answered on your reply on the other thread it is recommended for you to create your own post to ask your questions as this post as well is marked as Solved and apart from that is really old.