no shutdown of voice-port

Answered Question
Sep 22nd, 2009

In a situation where I started making a call, and then hung up while the call was going out the FXO port, I had that FXO port get "stuck" with the LED on, and I couldn't make calls from that line, nor could that line accept incoming calls.

In fact, Auto Attendant doesn't even play anymore when this line rings.

If I call my other line, everything works as expected.

On previous occasions when this has happened, I would reload the UC520, then it would work fine again.

Since, I found that I can do the following:

uc520#conf t

uc520(config)#voice-port 0/1/0


uc520(config-voiceport)#no shutdown

The problem is, after the voice-port comes back, UC520 will try use the line to try and make a call, but nothing ever happens, and the line simply goes dead and UC520 hangs up after 40 seconds.

Is there a better way to get an FXO port "unstuck", or reset it?



I have this problem too.
0 votes
Correct Answer by Marcos Hernandez about 7 years 3 weeks ago

Luis, this sounds like an FXO disconnect issue. More information about the problem and ways to mitigate it on:



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
David Trad Tue, 09/22/2009 - 22:02

Hi Luis,

The problem is, after the voice-port comes back, UC520 will try use the
line to try and make a call, but nothing ever happens, and the line
simply goes dead and UC520 hangs up after 40 seconds.

Yes i am having this same issue with another client, i am unable to shut down that port and bring it back up, this even had TAC staff puzzled as to why this happens, the only difference is that all 6 FXO lines at my clients site lock up over a period of time, so we have a script now in place that logs into the system and reloads the UC-500 every 3-4 days as this is usually when all the lines have locked up.

I am not sure what is going on with the latest IOS releases, but their system has been swapped out already, and the same problem has occurred again, but this time it took almost 3 weeks for it to rare its ugly head.

Your problem is similar but not exactly the same as mine, but the resolution taken is the same and the results are identical, if you dial that port it just becomes dead air, and at times crackling.

No resolution to the problem on my end yet.



Luis Giraldo Tue, 09/22/2009 - 22:59

Possible development...

I hadn't seen this before, but in CCA, under Ports > Voice Trunk Settings, one can Shutdown a port. Once shutdown, the drop-down menu shows an "Activate" option to bring it back up.

In my experiment, I made a call from UC520 to my celphone on that line, and placed it on hold.

I then went into CCA and shutdown the port, which hung up the call.

Then I activated the port again via CCA, and it worked again as expected. I was able to place and receive calls on this line.


To be sure of the behaviour, I did the same via CLI.

I made a call to my celphone, answered it and then put the call on hold.

In CLI, I entered:

uc520#conf t


uc520(config)#voice-port 0/1/0


At this point the call was hung up as expected.  Then I issued the command:

uc520(config-voiceport)#no shutdown

I was able to place and receive calls from this port as expected.

So I think something else is getting messed up over time that causes the port to fail, and it seems that it can only be resolved with a reload.

Extremely disappointing.

Here's my show version:

Cisco IOS Software, UC500 Software (UC500-ADVIPSERVICESK9-M), Version 12.4(20)T2, RELEASE SOFTWARE (fc3)

Technical Support:

Copyright (c) 1986-2009 by Cisco Systems, Inc.

Compiled Mon 26-Jan-09 20:55 by prod_rel_team

ROM: System Bootstrap, Version 12.4(11r)XW, RELEASE SOFTWARE (fc1)

mnkyuc01 uptime is 1 hour, 12 minutes

System returned to ROM by reload at 21:48:01 PDT Tue Sep 22 2009

System restarted at 21:48:57 PDT Tue Sep 22 2009

System image file is "flash:uc500-advipservicesk9-mz.124-20.T2"

Last reload reason: Reload Command



Cisco UC520-16U-4FXO-K9 (MPC8358) processor (revision 0x202) with 249856K/12288K bytes of memory.

Processor board ID **************

MPC8358 CPU Rev: Part Number 0x804A, Revision ID 0x20

22 User Licenses

10 FastEthernet interfaces

2 terminal lines

4 Voice FXO interfaces

4 Voice FXS interfaces

1 Voice MoH interface

1 cisco service engine(s)

128K bytes of non-volatile configuration memory.

125440K bytes of ATA CompactFlash (Read/Write)

Configuration register is 0x2102

Albert Wilhelm Mon, 10/05/2009 - 06:38

Hello Luis and David,

I too have the same problem with the FXO ports hanging up. My client has four ATT PSTN lines from his original Panasonic Key system. At least once a month, the FXO ports hang up and have the same issue you have, even when I shut down the voice port and bring it back up. The scenario described by David is also what I am seeing.

I took a look at the document referenced by Marcos and have entered the following commands for each voice port:

UC_520#configure terminal 
UC_520(config)#voice-port 0/1/0
UC_520(config-voiceport)#supervisory disconnect dualtone mid-call
UC_520(config-voiceport)#cptone us
UC_520(config-voiceport)#timeouts wait-release 5
UC_520(config-voiceport)#timeouts call-disconnect 5

UC_520 (config)#

I will let you know this week if it has made a difference with the FXO getting stuck. Hopefully it does. I have to say it is a little embarrassing when the Key system has worked without problems on it's FXO ports and the customer wants to know why the Cisco UC520 is having the problems.

I will post later this week if the above solution worked. Stay tuned.

Bert Wilhelm

APW Solutions, Austin TX

Marcos Hernandez Mon, 10/05/2009 - 06:49

Hi Bert,

I know this is difficult (if not impossible) to sell to an end customer, but this is really NOT a Cisco problem. It is an inherent problem with the nature of the FXO ports and CO trunks.

If you still see issues with the configuration below, please try some of the other mechanisms or open a TAC case.



Luis Giraldo Thu, 10/15/2009 - 15:38

I just had another disconnect of my main voice port, so I did voice-port shutdown, then a no-shut, but the voice port never comes back. I placed a call from the outside to the number, and it rings 3 times, then it seems like AA picks up, but there is no sound or anything. While monitoring CLI during my call, these messages came up:

000159: Oct 15 22:34:43.837: mbrd_e1t1_vic_connect: setup failed


000160: Oct 15 22:34:43.837: %FLEXDSPRM-3-TDM_CONNECT: failed to connect voice-port (0/1/0) to dsp_channel(0/0/2)


000161: Oct 15 22:34:51.818: mbrd_e1t1_vic_connect: setup failed


000162: Oct 15 22:34:51.818: %FLEXDSPRM-3-TDM_CONNECT: failed to connect voice-port (0/1/0) to dsp_channel(0/0/2)


I'm not sure what to make of them, or if this points in the right direction for Cisco to determine the source of the problem.



David Trad Thu, 10/15/2009 - 19:02

Hi Marcos,

I know
this is difficult (if not impossible) to sell to an end customer, but
this is really NOT a Cisco problem. It is an inherent problem with the
nature of the FXO ports and CO trunks.

Whilst i appreciate what your saying and there are some elements of truth in it, please keep in mind that traditional phone systems such as Key Systems do not have these problems, i have never seen this happen on a Nortel, NEC, Samsung, Hybrix, Panasonic's....etc..etc.. The only systems i know of that have this problem really bad is the Alcatel.

There are some things to try and manage this problem with a Cisco, the fact is the Cisco does not handle PSTN lines all too well, right now the only methods we can do to over come these problems to try and convince the client to move to ISDN lines (BRI), the reluctance to do so is a big issue as it costs more here in Australia (For line Rental) not sure what it is like in other countries.

I wish there was a quick fix for this, or a better answer to give customers/clients, alas i know there isn't and no matter what you try and do or say it will always be a tuff sell, even to the point now were i am dealing with customers that are trying to force our hands in providing full refunds because the system does not function or operate as advertised or promoted (No indication to the problem in the Cisco provided literture), on top of that the carriers do not help as they say it is the equipment and babble on with other nonsense that causes even more grief.

I have learnt now that it is infinityly better if you are going to sell a digital system such as Cisco, you should look to digital telephony services such as ISDN/PRI and SIP trunking, these services are not proned to the above problems, but still have their own issues, but are much better and easier to support.

Jut my thoughts, i have avoided posting and just observing, but i beleive that some clarifications needed to be put forward, even though i know you know what we are experiencing out here in the field.



Albert Wilhelm Mon, 10/19/2009 - 08:56

Hello all,

Wanted to update my previous post on the configuration changes for each of the FXO ports. We have been running fine for the last week and a half with no FXO hang ups using the commands I posted earlier.

It seems to be working fine right now, but I am still monitoring as the occurance of the hung-up port is spotty. Sometimes the ports will work fine for a week and then the following week we have issues.

So, just wanted to update this post on my observations. I will continuing to monitor till the end of the month and will update again.

Stay tuned.


Albert Wilhelm Tue, 11/10/2009 - 14:22

Well, I was hoping to have good news. We have been running fine for approx 4 weeks since my last post and then just last week the FXO ports hung up two days in a row. Sigh.

I will inform TAC of the bug number from Steven.

cchubb Wed, 01/06/2010 - 16:45


I just checked on my customer and their 3 FXO lines are still active.

If you haven't already, log a TAC case as previously recommended.

TAC assistance might be the only way this ultimately gets resolved for everyone.


Steven Smith Thu, 01/07/2010 - 08:02

It is still broken.  Would you mind opening a TAC case for this?  It seems that is has been difficult to get the correct logs.  If you can help with that, it would speed this up.

cchubb Thu, 10/22/2009 - 20:02

Same issue with FXO ports hanging on a customer UC520 running 12.4(20)T2

#show voice call summary


0/1/0         g711ulaw   n  S_CONNECT             FXOLS_REMOTE_RELEASE    
0/1/1         g711ulaw   n  S_CONNECT             FXOLS_REMOTE_RELEASE    
0/1/2         -          -  -                     FXOLS_ONHOOK            
0/1/3         -          -  -                     FXOLS_ONHOOK

The FXO trunk group is set for longest idle and ports 0/1/0 and 0/1/1 are not working at all.

I issued a "shut", "no shut" on the voice-ports.

#show voice call summary


0/1/0         g711ulaw   n  S_CONNECT             FXOLS_ONHOOK            
0/1/1         g711ulaw   n  S_CONNECT             FXOLS_ONHOOK            
0/1/2         -          -  -                     FXOLS_ONHOOK            
0/1/3         -          -  -                     FXOLS_ONHOOK

The 2 ports went to the proper onhook status, but the VTSP state would not change from S_CONNECT

The ports would activate for outbound calls, but the calls would not go through. They would just hang for 30 seconds or so.

and give the following message:

022041: Oct 21 22:42:45.219: %FLEXDSPRM-3-TDM_CONNECT: failed to connect voice-port (0/1/0) to dsp_channel(0/0/4)

There seems to be no other method of clearing the voice ports. If anyone know of a better way please let me know.

I inserted the supervisory and timeout commands as per Bert, saved, and requested an after hours system reload.

I expect to be back onsite soon and will reply with any positive results.

Chris Chubb

UNIS LUMIN, Vancouver

Steven Smith Mon, 11/09/2009 - 08:13

CSCsw87778: FXS Port fails to use allocated DSP

Looks like this is a bug, but it isn't resolved yet.  If you have this issue, please open up a case and reference the fact that you might be hitting this bug.  This will allow TAC to help the developer get the debugs he is looking for.

David Trad Thu, 01/07/2010 - 00:20

Hi All,

I know this is not a solution for many of you, but what i have begun to do is set clients up with a SIP services or GSM gateways for any of the call bridging, i now know that here in Australia bridging two PSTN lines together (Bonding two call legs) will always result in hung ports, or bad tare downs (Call Clearing).

As a result what i have found is that more and more clients are now requesting that they have the SIP service turned on as a permanent outbound service, what i had implemented as a solution to a problem, has ended up solving other issues like larger monthly/quart bills from their line provider.

But as i said this is not for everyone and some of you might have issues setting up SIP services on their UC's, but hey if you can do it i am promising you that it is a viable solution, and you can program the system up so that only Call forwards and After hours use it if you are worries about call quality or anything else.

If you are in Australia, i would encourage you stop looking into the problem, it is a known fact that does not just effect Cisco, so far i have tested this on an Alcatel, Nortel, Mitel and Avaya system and they all have the same issue, although i must say the Mitel system handled this problem a lot better when the outbound lef was to a mobile, but the issue never went away.

I hope you all find a solution for this problem, trust me i know how much of a headache it can be to you with your clients, and also how much of a sour taste it can leave in your mouth when it raises its ugly head, but you should know that Cisco, whilst in my opinion the the best of breed phone systems out there, they are not immune to carrier issues, the PSTN network is a dodgy setup at best, your only options to get past this problem is either ISDN or SIP or GSM gateways, no system can escape this problem unless it is a really...really...really old Key system that have line level work around's.



Luis Giraldo Thu, 01/07/2010 - 09:16

I haven't had the issue happen to me again - BUT, I had noticed the port would hang when I had started a call and immediately hung up. I've been very cautious to not do that, and the problem has not happened again for me.




This Discussion