no shutdown of voice-port

[Luis Giraldo]

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)#shutdown

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?

Thanks,

Luis

[David Trad]

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.

Cheers,

David.

[Luis Giraldo]

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

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

uc520(config-voiceport)#shutdown

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: http://www.cisco.com/techsupport

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

[Marcos Hernandez · Accepted solution]

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

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

Thanks,

Marcos

[Albert Wilhelm]

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-voiceport)#exit

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]

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.

Thanks,

Marcos

[Luis Giraldo]

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

mnkyuc01#

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)

mnkyuc01#

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

mnkyuc01#

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)

mnkyuc01#

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.

Regards,

Luis

[David Trad]

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.

Cheers,

David.

[Albert Wilhelm]

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.

Bert

[Albert Wilhelm]

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.

[cmonks]

Any more updates on this? I have a customer that seems to run into this issue every few weeks. shut/no shut does not free the lines. requires a reload.

Any info on if the new IOS resolves this? looks like it is still listed on the 15.0 IOS caveat list.

[cchubb]

Hi,

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.

Chris

[Steven Smith]

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]

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

[scherrer]

I've got the same issue on a costumers UC520 with 12.4(24)T on it. (only a restart works out)

...hope for a solution of the issue in the next firmware...

Daniel