Backup Routing

[Toni]

Hi all!

We're having some problems in announcements routing and calls are going to backup switch routing.

I'll explain a bit the problem:

When a call is getting routed through the announcements VDN, some times it waits more than 5 secs to be routed and the switch sends us an ASAI C_REC_TIMER code and gets the control of it.

It happens us only when we have a high call volume, and we loose abot 150 calls that go to backup.

We have Genesys 7.1 with an Avaya Media Server S8700 and an Avaya Media Gateway G700.

We've talked with switch people and they told us that we have two VAL boards for announcements with 31 ports each one, so in fact, we don't have a huge number of waiting calls to get that board overflow.

Does anybody had the same problem?

Thanks in advance!!

Toni

[René]

Hi Toni,

I would say that the issue, you've described, is caused by missing resources on the PBX side (voice processors used to play announcements/music). How many inbound channels (connection to PSTN) do you have? If number of inbound channels is higher then number of voice processors and the boards are used for both announcements for new calls and for music in queue then I can image a situation when all 62 channels are occupied.

Try to ask the switch people to monitor load on VAL boards during your peak time.

Cheers,
René

[Toni]

Hi René,

I've just told to the switch people to monitor the load on our VAL boards. We have to boards, each one with 31 channels as you said.

Switch people don't want to assume that it's a problem of their VAL board, but everything points it.

Boards are used for music announcements as well as wait announcements, so I think, that in peak times they have a lot of work.

In our peak time we could have about 60-70 calls in queue.

Switch people are tellin us, that those val boards have a queue for 4000 calls, as well as they could give the announcement for 1000 calls at the same time. That sounds me a bit strange...

What do you think about all that?

Thanks a lot!

[René]

Hi Toni,

I know that discussion with switch people could be quite hard job... But I'm pretty sure that the issue is switch related because the switch tells TServer that there was a timeout.

I've checked the Avaya documentation and it's written there that "announcement" command is skipped in case of any troubles (busy, not available etc.) with the announcement.

Could you post here the vector for the VDN we're talking about?

René

[Toni]

Good morning René,


Let's see what tells me today switch people...

The announcement vector is the following:

01 adjunct      routing link 1
02 announcement V1
03 wait-time    5  secs hearing silence
04 goto step    7  if oldest-call-wait in skill 1798  pri m<240
05 disconnect  after announcement 71814
06 stop
07 queue-to    skill 1798 pri m
08 announcement 71804
09 wait-time    20  secs hearing music
10 goto step    2    if staffed-agents  in skill 1730>=1
11 announcement  71813
12 goto step    9  if unconditionally
13 stop
14 disconnect  after announcement 71815
15 stop


I told switch people to make a change in the vector. Instead of "03 wait-time    5  secs hearing silence" I told them to put ""03 wait-time    5  secs hearing ringback". With that change, I'll call the vector in a peak hour and if I listen ringback before the announcement it means that the announcement instruction has failed, and I could have more proves to tell to switch people, that their announcement has failed for any reason.

Thanks a lot!

[René]

Good morning,

We're thinking in the same way. I just wanted to suggest you a slight modification of VDN to get a "proof" for the switch people - adding "route-to" command after the announcement and route the call to different VDN. You can monitor that VDN using CCPulse and if a call appears there then we have it (the proof)

Let us know what was the cause when you fix it. Thx

Cheers,
René

[Toni]

Hi René,

I'm still waiting an answer from the switch people, talking with that people it's being like hell...

But due to the proves we have, I'm quite sure that is a PBX issue, don't you think so?
In that way I'll make them some pressure, because for that people, never is their problem.

Thanks a lot!

[René]

Hi Toni,

I'm sure it's a PBX issue but don't know how to prove it to the switch people. I do understand you that it's a problematic communication with them usually...

You're welcome!

R.