UC320 AA invalid input = hangup?

[wireguided]

I have a client who has the AA setup so the caller needs to dial '1' and then dial an extension (3 digit). Some callers are just dialing the 3 digit extension directly from the main menu. What is happening is that if the extension they were trying to dial has a 2nd digit which is the start of an internal reserved group then instead of following the invalid input settings it says "Your call has been forwarded" and then disconnects.

Example:

At main AA menu caller should enter '1' (it will then say to dial extension at any time) followed by the extension (let's say extension '139'). This works fine.

If at the main menu the caller dials '139' directly it waits for a bit, give the forwarded message, and then disconnects.

I did run some syslogs on the call and it looks like it is trying to transfer the call to extension 39 (which does not exist and could not they have 3 digit extensions). Why would the AA not follow the invalid input settings? The UC320 is at 2.1.5 firmware.

Syslog except below:

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>SAA_Checkdialplan:

Feb 20 13:13:33 UC320W user.debug voice: SAA_DBG:Accepted. dn = 39

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>SAA_CheckMenu

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>checkDialPattern input=39, dp=4

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>checkDialPattern input=39, dp=5

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>checkDialPattern input=39, dp=6

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>checkDialPattern input=39, dp=8

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>checkDialPattern input=39, dp=9

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>checkDialPattern input=39, dp=#

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>checkDialPattern input=39, dp=*

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>checkDialPattern input=39, dp=x.

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>Execute AUACT

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>loadCurPA

Feb 20 13:13:33 UC320W user.debug voice: Clear

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:>>>>SAA_LoadAudio, index = 0

Feb 20 13:13:33 UC320W user.debug voice: SAA_DBG:<<<<SAA_LoadAudio 1

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:<<<<loadCurPA

Feb 20 13:13:33 UC320W user.debug voice: SAA_DBG:play propmt 2

Feb 20 13:13:33 UC320W user.debug voice:

SAA_DBG:<<<<SAA_DPSTimerCallBack

Feb 20 13:13:33 UC320W user.debug voice: initPlayPromptFromFile 0 1 0

Feb 20 13:13:33 UC320W user.debug voice: en aa=en;vm=en;pm=English-US; 1

Feb 20 13:13:33 UC320W user.debug voice: Seperated String aa=en

Feb 20 13:13:35 UC320W user.debug voice: Clear

Feb 20 13:13:35 UC320W user.debug voice: SAA_DBG: End of prompt 0 1

Feb 20 13:13:35 UC320W user.debug voice:

SAA_DBG:>>>>SAA_ExecuteAction(5a5228, 56f734)

Feb 20 13:13:35 UC320W user.debug voice: [AA]: xfer to target=39

Feb 20 13:13:35 UC320W user.debug voice: SAA_DBG:<<<<SAA_ExecuteAction() rc= 1

Feb 20 13:13:35 UC320W user.debug voice:

SAA_DBG:SAA_ExitAA

Feb 20 13:13:35 UC320W user.debug voice: SAA_DBG: psao->rtval = 559db8

Feb 20 13:13:35 UC320W user.debug voice: CC:BlndXferTgt:39

Feb 20 13:13:35 UC320W user.debug voice: Calling:39@10.1.1.1:6060, rc=0

Feb 20 13:13:35 UC320W user.debug voice: [11:0]AAA Rel Call

Feb 20 13:13:35 UC320W user.debug voice: SAA_DBG: lid=11

Feb 20 13:13:35 UC320W user.debug voice:

SAA_DBG:>>>>SAA_Destroy

Feb 20 13:13:35 UC320W user.debug voice: Clear

Feb 20 13:13:35 UC320W user.debug voice: SAA_DBG:<<<<SAA_Destroy

[Christopher Edgeworth]

Hi,

Thanks for reporting this.  I've opened bug CSCty11352 to see if we can tighten up the AA dialplan and treat partial extensions as invalid input instead of trying to route them.

Thanks,

Chris

[ensemblecustom]

Hi -

I am having the same problem.

At the main prompt we say "Dial 3 for a directory". 

If the caller presses 3 we read the directory, e.g. "for Jim dial 13".  Assume Jim is at extension 13.  If the caller dials 13, the system tries to transfer the call to extension "3" which doesn't exist, and then it hangs up.

If the caller dials "13" at the main AA menu then it works fine.  I don't really want to say "113" on the directory because then that is incorrect if they call and try and dial it at the main AA menu.

For now I have prevented barge-in on the directory prompt, which forces the caller to listen to the whole directory, but then when they can dial it works properly.

Would love to have this work more straightforwardly - it really just needs to be able to dial the extension number while it's playing a secondary prompt.

[Christopher Edgeworth]

Hi,

I think you are running into the barge-in while playing prompt issue.  Please see this thread for a solution:

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

Thanks,

Chris

[Shweihat55]

Hi Chris, I am having a similar issue, I have the option to dial Ext at anytime on in the AA and when we try and dial an ext while the main prompt is playing we get the message that your call is being forwarded and then dead air.

[Christopher Edgeworth]

Hi,

Do you get the message after entering the first digit of the extension or after you have entered all of the digits for the extension?  Where are you trying to transfer the call to?  an internal extension, huntgroup, shared, extension, external number?

Chris