Intermittent Call Park Problems

Unanswered Question
Apr 13th, 2010
User Badges:

I have approximately 10 UC520 systems all experiencing an intermittent call park problem. I am curious if anyone else in the community has experienced a similar problem.

Call park is configured and works without issue 99% of the time, however, there are times that the Park soft key simply does not do anything when pressed. End users can press the Park softkey until they are blue in the face and the phone still does nothing. The audio path is not interrupted and the call is not dropped; it simply will not park. This is happening across a variety of end points including 7911, 7941 and 7965. I know there are sufficient free park slot resources available when this issue is occurring. This issue will generally clear itself up after an undetermined amount of time, but sometimes requires a reset of the phone in order to correct.

One of the UC devices that just recently experienced this problem was running IOS Version 12.4(22)YB4 with these phone loads: SCCP41.8-4-2S and SCCP45.8-4-2S.

I've reviewed the TAC Case Collection and can't find a documented problem.

Anyone else experience a similar problem?

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Marcos Hernandez Tue, 04/13/2010 - 15:19
User Badges:
  • Blue, 1500 points or more

I did a quick search in our bug database and could not find anything obvious that is a match. You could try to upgrade to a more recent software pack, a new revised one will be available shortly. If you can't do that, you should set up a syslog server and try to capture these debugs for when the problem takes place:

debug ephone detail
debug voip ccapi inout



mega-byte Tue, 04/20/2010 - 15:35
User Badges:

I did some further research on this problem and determined that it is reproducible. The park button (and the TransVM) options appear to not work after an aborted consultative transfer.

I captured the requested debugs and attached them to the post.

Here is the scenario that is captured in the log:

1. Phone call from the PSTN presents itself on an FXO port.

2. FXO port is configured to PLAR to a ephone-hunt group.

3. Ephone-dn 1 on ephone 1 (extension 301) is rang.

4. Ephone-dn 3 on ephone 3 (extension 303) executes a Pickup command to seize the ringing call from extension 301.

5. Extension 303 initiates a consultative transfer to ephone-dn 2 on ephone 2 (extension 302).

6. Extension 302 answers and the user decides they are not going to accept the transfer and hangs up.

7. Extension 303 hits the resume soft key to pick up the initial leg of the aborted transfer call.

Extension 303 is now not able to hit the park button, or use the TransVM option. Both softkeys are available, but simply do nothing when pressed. The media stream is never interrupted, the buttons simply do not work.

The TransVM and Park buttons work fine as long an a consultative transfer is not attempted, then aborted.

The most relevant message in the logs appears to be: Block FAC when Sk pressed.

I am not doing an FAC blocking on that ephone-dn, or on any extension on the system for that matter.

I do have a custom ephone-template defined on that ephone, but I removed it, reset the phone and was still able to replicate the problem.

Any ideas?

Marcos Hernandez Wed, 04/21/2010 - 07:23
User Badges:
  • Blue, 1500 points or more

This is a very good description. Let me take a look at the debugs and get back to you.


Marcos Hernandez Wed, 04/21/2010 - 07:40
User Badges:
  • Blue, 1500 points or more

No need to provide the "show run", but please send a "show ver". I am positive you are running into this bug:

CSCsu07993    TransVM  softkey doesn't work after full consult transfer is declined


mega-byte Wed, 04/21/2010 - 07:54
User Badges:

That seems reasonable.

I'll upgrade the IOS to the one provided in the latest software pack and see what happens.

Thanks for your help.

Douglas Yoder Mon, 06/21/2010 - 11:22
User Badges:

So if you were to do the suggestion in CSCsu07993 Bug Fix what would the dial peer look like. The article is quite vague.


This Discussion