Symposium 5.0 Broadcast Announcements not playing 1

[81Cadmin]

First off, thanks in advance for your input.

Environment:
- Symposium 5.0
- CallPilot 4.0
- M1 81C (rel 25.40b) soon to be upgraded to 4.5

We recently completed building our Symposium 5.0 server. This project has been put on hold several times due to various reasons. It's up and running and I've tested most of the functions and all seems okay.

I have however uncovered a problem with when placing multiple calls to the same skill-set. Below is part of the call treatment script which loops while the call is on hold.

/* CHD_CCT SCRIPT */

GIVE CONTROLLED BROADCAST ANNOUNCEMENT
PLAY PROMPT WITH LANGUAGE language_cv VOICE SEGMENT chd_1stwait_vs
GIVE MUSIC 5

I've noticed that the voice segment does not play to all callers (tested it with 3 simultaneous calls). In some cases "DEAD AIR" is played (caller notices a pause of music for duration of voice segment). What's more concerning is that in some rare instances Symposium is bridging a "LIVE PRIVATE EXTENSION" call for the duration of the voice segment. You can actually hear a private call during the voice segment window (5 seconds).

I definitely can't roll this into production without resolving this issue. I've checked the access and IVR ports of CallPilot and can't find any issues. And I have no idea of how/why the system is doing this.

Any assistance or suggestions is appreciated.

 

[Milesprower]

Check your global settings. Open IVR ACD_DNs and then check global settings (File, Global Settings). A Dialog box should open up that defines the maximum number of access ports for which broadcast can be used. This sould always be less than the total number of access ports. There is also a Broadcast Voice Port Wait Timer. It specifies how long a call waits for an access port to play a broadcast message.

The lower the number of broadcast ports and the shorter the duration of the timer, the higher the probability that you will run out of ports (and hear nothing).

One other possiblity: you may have a bad port (or ports). For example, if you have 4 ports and every fourth call does not hear the message, one of the ports could be bad. Check the IVR queue statistics and IVR port statistics reports. You should see a few calls not treated, but if it is an appreciable percentage (>10%), then check the voice ports.
Make sure they are defined and acquired correctly. Then check their status on Call Pilot.

 

[81Cadmin]

Thanks Milesprower. I found that in the Global Settings the access ports were configured for 5 when we have 4.

Unfortunately after changing this parameter it now seems the access ports will not acquire (attempted several times to complete the acquire for all 4 access ports).

I've attempted a reboot of both CallPilot and Succession (delaying the boot of CP); Ports will not acquire.

I've also re-ran the config wizard of CP and performed another reboot of each; Ports will not acquire.

I tried reverting back to the original Global setting of 5 ports; Ports still will not acquire.

I'm not sure why this change resulted in this problem. All environments are latest Peps / patches.

 

[81Cadmin]

Update:

In troubleshooting I removed the Channel (1-4) setting from the IVR ACD-DN's table. The channels acquired immediately after. After re-adding the channel designation (1-4) the acquire again fails. I checked the CP port configuration and the channel sequences are correct.

 

[81Cadmin]

Small correct to the above. The channel setting was changed in "Phonesets and voice ports" not IVR ACD-DN's table.

 

[Milesprower]

If the ports do not "acquire login", most likely the cause is incorrect programming on the switch or a missed setting in the Call Pilot Configuration wizard. Double-check the voice port settings.

The TNs are defined in "phonesets", and then the channels are assigned in "voice ports". The voice ports are acquired in "voice ports".

Have you run the SCCS setup configurator and specified (under voice services tab), TCP/IP, put in the call pilot ELAN IP and hard coded the port 10008?

By the way, 4 voice ports is the bare minimum I would go with. The number of Broadcast ports should be less (so 3 or less) than the total number of voice ports.

 

[81Cadmin]

Thanks for the suggestions Milesprower. I've tried all of the above steps with no success. it's odd that the problem started when attempting to correct the inital problem of this thread.

The 81C and CP show the ports as logged in / active. I've run the CP Config wizard several times along with reboots of all environments per Nortel guidelines(excluding the 81C).

The only way I can get the ports to acquire is by removing the listed channel (1-4) from the "Phonesets and Voice Ports configuration" (in SWC) and directly with the SMI workbench tool. Same result in both cases.

Thanks for your support on this. I think it may be time to contact our technical support vendor as I'm at a loss as to why they will not acquire. Unfortunately I'm sure it will take some time (and lots of $$$) to get this corrected.

Thanks again.

 

[Milesprower]

It shouldn't cost $$$, but it can. I just did a Call Pilot upgrade last week. Me, a Technician and a Project Manager. Took 6 hours because we had to track down some errors in the Call Pilot Wizard. The ports and IVR ACD-DN queue all have to be built just right in the switch, call pilot, and SCCS.

The documentation is spread between the Call Pilot and SCCS so it is really difficult to follow. We still use the technical knowledge transfer Nortel did. You can check the SCCS documetation in the Symposium, M1/Succession 1000 and Voice processing Guide (297-2183-909). It should be on the SCCS documentation CD-ROM.

One other thing, on Global settings make sure the default access treatment dn and the default ivr dn are both set to your IVR ACD-DN. If this is a Call Pilot, put 1111 in both the mailbox and password boxes.

 

[81Cadmin]

Update:

After completing various configuration changes yesterday the ports would still not acquire. However overnight for some reason the ports automatically acquired on their own (possibly when the 81C completes it's nightly switch of processors).

I find this odd; regardless I'll need to continue and work on finding the cause and resolution of the problem.

Thanks all... I will update the thread once the cause and solution has been identified.

 

[Milesprower]

OK, sometimes the ports don't "acquire login" until both systems are have been rebooted and are up for awhile (5 min). Last tip, if everything looks right and the ports are still not acquiring properly, you can try stopping and restarting the VSM service on the SCCS. Sometimes that does it. The last site I was on, the only way we got the ports to acquire was restarting the VSM service.

 

[yukon1981]

You might also ensure your MAS Link Handler #2 service is running (Look under "computer management>services"). Sometimes it stalls after a reboot. It is safe to just restart the service. You can set the service to recover from a stall by changing the "first failure" action to "restart the service" on the recovery tab of the service property sheet. If this service is stopped, it can prevent ACCESS ports from logging on or acquiring. Good Luck!

 

[81Cadmin]

Thanks all for you suggestions; unfortunately i can't duplicate the acquire problem so I test to see if all the suggested fixes work at this time.

Looks as though i'm back to square one though as the broadcast still are playing dead air to some callers when multiple calls are in queue. i'm going to engage our support vendor for assistance.

Thanks again,

 

[djwht]

if you're doing broadcase or voice session with language options...make sure you add all the segment file and languages you're using to the variable.

for instance:

variable is please_hold_vs
segments are english file2:1
spanish files2:2
german files2:3

make sure each of those segments are in please_hold_vs

ran into this 2 weeks ago, and nortel had to correct the issue. it is not very well documented and affects all 5.0 and 6.0 systems