UC520 AA call transfer oddity

Unanswered Question
Apr 17th, 2009

I am working with a UC 520 that has started to show signs of possession.

The AA menu allows numbers one to three to call three extensions that forward to voicemail on busy or noan.  Menu item 4 allows transfer to the prompt management system.  All works as advertised on local phones attached to the UC520. Until two days ago, calls from the PSTN FXO lines also transferred correctly.  Now, however, pressing number 1-3 from an outside line results in the calls bouncing back out and initiating another external call back to the AA.  Oddly enough, though, pressing 4 transfers the caller to the prompt management system as it should.  It's not a DTMF decode issue as far as I can tell, since the prompt management system recognizes the extension and PIN and works correctly. No changes were made to the UC520 config as shown by the logs and configuration date. I have checked the bug tool, but there is no mention of any sort of call routing mystery that is remotely similar. I am hoping that someone out there has read about or experienced some sort of parallel issue and might be able to save me several hours of poring over debug files onsite, since the box is not configured for remote admin. My first trick will be a reboot when I arrrive onsite tomorrow.


I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Marcos Hernandez Mon, 04/20/2009 - 12:03

Could there be some ort of issue with the POTS wiring? What happened after the reboot?


Marcos Hernandez
Technical Marketing Engineer
Cisco Systems, Inc.

Anonymous (not verified) Tue, 04/21/2009 - 05:47


Thank you for your reply.

There was no change following the reboot.

I ran a "debug ephone stat" and  find that incoming calls from

the PSTN to the autoattendant show a redirect with a cause code of 12

when they are sent back out of the autoattendant.  Please see debug snippet below.

Number 601 is the outside line connected via a PLAR OPX command from the first FXO port.

Number 611 is the line that the Auto Attendant tried to transfer the call to.

18 14:19:29.299: ephone-5[6]:Call Info DN 20 line 1 ref 54 call state 7 called 601 calling 6473289880 origcalled 611

Apr 18 14:19:29.299: ephone-5[6]:Call Info DN 20 line 1 ref 54 called 601 calling 6473289880 origcalled 611 calltype 1

Apr 18 14:19:29.303: ephone-5[6][SEP0018187C1CC9]:Call Info for chan 1

Apr 18 14:19:29.303: ephone-5[6][SEP0018187C1CC9]:SkinnyDisplayCallInfo callingName=DONALD MILLER

Apr 18 14:19:29.303: ephone-5[6][SEP0018187C1CC9]:SkinnyDisplayCallInfo calledName=Line 1

Apr 18 14:19:29.303: ephone-5[6][SEP0018187C1CC9]: RedirectReason 12

Apr 18 14:19:29.303: ephone-7[11]:SetCallState line 2 DN 20(20) chan 1 ref 54 TsRingIn

Apr 18 14:19:29.303: ephone-7[11]::callingNumber 6473289880

Internal Skinny calls process normally. 

I cannot find any information regarding Redirect cause code 12.

If you have any information on this cause code I would greatly appreciate it.


Marcos Hernandez Wed, 04/22/2009 - 12:16

The debugs you posted don't really expose any problem. Let's try one more thing before we send you to TAC :-)

can you post a "debug vpm all" while the call is connected and you press 1, 2 or 3? I think this could still be DTMF mishandling (probably due to some quality problem on the line).



Anonymous (not verified) Tue, 04/28/2009 - 06:46


Apologies for the delay in response.

I am working to convince the client to spring for a remote admin option.

Once complete, I will be able to run and capture debug sessions after hours

and without the long drive.

I will post results. In the interim, if you can find any information at all on call redirect code 12

I would appreciate it.




This Discussion