Weird VAL behaviour under heavy call volumes 1

[nickd87]

Has anyone ever seen this behaviour before?

The boards are in one audio group, but the specific announcement at the particular steps below has "Q" stroked 'n'. My understanding of this setting means that if a port is not available, the switch just skips the announcement step?

It appears as if the switch is trying repeatedly to find a VAL board for the announcement despite "Q" being set to no.

time vec st data
18:31:54 700 4 wait-time
18:31:55 700 5 announcement
18:31:55 700 4 announcement: board 02A14 ann ext: 28400
18:32:00 700 5 announcement
18:32:00 700 4 announcement: board 01C07 ann ext: 28400
18:32:05 700 5 announcement
18:32:05 700 4 announcement: board 02A14 ann ext: 28400
18:32:10 700 5 announcement
18:32:10 700 5 announcement: board 03A16 ann ext: 28400
18:32:19 700 6 queue-to
18:32:19 700 6 queueing to skill 14 pri m



Any ideas? Or has anyone seen this before?

 

[Toni269]

I haven't seen this but I have seen a recent PCN come out for the VAL boards. If you've moved a VAL board that was in an audio group, it causes problems:
Document Title: PSN #1256U - Removing VAL board (TN2501) corrupts audio-group translations
Product: Communication Manager
Description Text: Removing VAL board (TN2501) corrupts audio-group translations
Release Version: 3.0/3.0.1
Document Category: Product Support Notice

This document is located at the following URL:

http://support.avaya.com/japple/css...eID=228560&temp.bucketID=162024&PAGE=Document

 

[nickd87]

Thanks Toni

I haven't moved the VAL board(s) or changed any administration, so I'm thinking this isn't our problem.

Any other ideas anyone?

 

[petran]

Hello,

The boards may be in an audio group, but the announcement is administered as in a group also, right? I mean, you did not administer it as being in only one board, but in a group of boards, so the system tries to find it in all boards. "Queue" has nothing to do with this, just administer the announcement in only one board, not in a group...

Regards,

Petran.

 

[WimW]

When you try to play an announcement that is defined in an audio group in a specific PN. It will try to load- balance the playing of this announcement to the boards in the same PN. But it is strange that it acts like above. Maybe you have some corrupted announcement files.

Did you already try to execute the command
"list measurements announcements all yesterday-peak" to see if you have an overload of requests going to the VAL-boards.

 

[nickd87]

Petran,

Are you saying "Q" is not applicable in an audio group setup? If so, could you explain why not? I thought that all ports can still be busy (on all boards) even in an audio-group.

WimW,

Yes i have executed that command, and the boards are very busy during the peak time, but my understanding is that 3 boards should be more than enough. And in any case, I am told by Avaya that "Q" will skip over the announcement if all ports are busy.


The boards are currently at FW09, so we are going to go to FW17 to see if that resolves the issue.

Thanks for your help guys.

 

[nickd87]

For anyone else who is having this issue.

For an announcement on a board in an audio-group that has "Q" set 'n':

the switch will go searching for the announcement on other local boards, and then will traverse the WAN if the announcement is on a remote board in the audio-group. If there is no bandwidth and IGAR is set up, it will use IGAR to deliver the announcement.

For an announcement on a board in an audio-group that has "Q" set 'y':

the announcement will NEVER be sourced from a remote VAL board even if there is bandwidth/IGAR, the switch will go looking for the announcement on local boards only.

This might be useful to someone, someday.

 

[avayafreakje]

thanks, can you give us the source of this information?