TROUBLESHOOTING: MUSIC ROUTES AND BROADCASTS STOP PLAYING 1

[81Cadmin]

I'm looking to guidance on diagnosing a problem with Symposium 5.0. (w'CP 4, Succession 3.0/81C).

Scripts are all working well, with the exception an intermittent problem where Broadcast voice sessions and music fail to play after the caller has been on hold.

The greeting do play initially, as well as music. However after several Broadcasts and music 'sessions' are played they will get dead air, but remain in queue waiting.

*Note: if the call gets queued to an agent, then bumped (Not ready) to go back in queue the music returns as well as the broadcast every 3-50 seconds.

It's a strange problem and I'm looking to guidance on troubleshooting.

I find it strange that it is affecting both the MUSIC RAN and Broadcasts. I had GIVE MUSIC listed after every Broadcast, however removed it with the same result.

Below is a test script I've created to duplicate the problem...

/* Secondary Script: TESTING */
/* revision: */

IF OUT OF SERVICE skillset_cv THEN
EXECUTE CHD_NOAGENTS
ELSE
QUEUE TO SKILLSET skillset_cv WITH PRIORITY priority_cv
WAIT 2
GIVE MUSIC 5
END IF


/* ----- LOOPS ------------------------------------------ */

SECTION LOOP1
IF OUT OF SERVICE skillset_cv THEN EXECUTE CHD_NOAGENTS END IF
IF AGE OF CALL > 100 THEN EXECUTE LOOP2 END IF
GIVE CONTROLLED BROADCAST ANNOUNCEMENT 6330
PLAY PROMPT WITH LANGUAGE language_cv VOICE SEGMENT chd_wait1_vs
WAIT 20
EXECUTE LOOP1

SECTION LOOP2
IF OUT OF SERVICE skillset_cv THEN EXECUTE CHD_NOAGENTS END IF
GIVE CONTROLLED BROADCAST ANNOUNCEMENT 6330
PLAY PROMPT WITH LANGUAGE language_cv VOICE SEGMENT chd_longwait_vs
WAIT 20
EXECUTE LOOP2

SECTION CHD_NOAGENTS
IF SKILLSET_CV = test_SK THEN
GIVE CONTROLLED BROADCAST ANNOUNCEMENT 6330
PLAY PROMPT WITH LANGUAGE language_cv VOICE SEGMENT chd_wait1_vs
WAIT 5
ROUTE CALL CHD_afterhours_gv
ELSE
EXECUTE CHD_OVERFLOW
END IF

SECTION CHD_OVERFLOW
EXECUTE SCRIPT CHD_5801
DISCONNECT

 

[81Cadmin]

I ran an IVR QUEUE STATISTIC on my ACCESS PORTS for the last 4 hours. It shows that of 254 Calls, only 203 were treated = approx 20% untreated rate.

Is there a way to see if a particular port is the trouble?

 

[Milesprower]

You can run the IVR Port Statistics report. It will show by port how many calls were "answered" (announcements played).

If you had 100 calls a day, then each port should answer roughly 25 calls (the actual number will vary). If you have one (or more) port(s) with zero calls answered, then that is your port.

I had one customer who had 16 ports. Four where not working. Roughly 25% of the calls did not receive an announcement.

If the announcement fails to play, then the music may not come on.

 

[81Cadmin]

Milesprower, the first Access Port won't even show up on the report even though it was included in the selection criteria. I'm assuming it didn't answer any calls, and as a result was left off. The other ports seem to have answered a similar amount of calls, so it may be likely that broadcasts are failing when served to port 1.

I will test throughout the day tomorrow and update the post then. I think you definately put me on the right track. Now if I could only resolve my Rightfax problem...

Cheers,

 

[81Cadmin]

PS - I de-acquired the port in Symposium as it's not a port that I can disable in CallPilot. Am I right in assuming if it's not acquired it won't be used? (I believe so but just wanted to confirm).

 

[Milesprower]

No!
The command takes the longest available port in the acd queue. So, all ports in the ivr acd-dn must be acquired.

The fact that the first port does not show up on the report is an indication that something is wrong. Double check it's configuration and make sure it can be acquired properly.

 

[81Cadmin]

The programming is fine on the port and Symposium acquires it with no problems. It doesn't however appear on the report you advised me to run.

What's the best method to remove this port from this Access DN hunt (De-acquire and out TN on M1, reboot CP?)?

I don't want to make any modifications to Callpilot yet, as from experience port changes have caused major problems on CallPilot. I will only make port changes during a Sunday Maintenance Window.

 

[81Cadmin]

After a reboot of all servers it looks as though the problem may be resolved. I have a test call into the system hunting through all Access channels and none have failed thus far. Will leave in test for the next while and let's see what happens.

 

[81Cadmin]

After 4 + hours of testing (leaving 3 calls in queue) the report now shows 496 calls offered and 4 un-treated.

The reboots of CP and Symposium seemed to be the fix. All 6 ports seem to be working within acceptable levels.

Thanks again Miles,
Stuart

 

[81Cadmin]

Miles quick question. I'm seeing alot of calls to the CDN as "Calls Terminated" in historical reports. What does this mean (ie. what calls get this pegging)?

Do you know what CD includes the data dictionary NTP?

 

[81Cadmin]

Found the Data Dictionary. I don't think i fully understand how the calls are being pegged as 'terminated'. The number of terminated calls concerned me so I'd like to make sure this isn't a problem and that we aren't loosing calls.

 

[Milesprower]

Terminated calls are not "lost", they are calls that encounter one of several commands in the script (Disconnect, Busy, Route, Overflow). Usually, terminated calls are routed to voice mail or given disconnect after hours. Check the Application Call Treatment report to see these calls.