Urgent Symposium Information 3

[V4DUR2]

Hi Guys,

Im looking for a real pro here to help out, currently we have Symp 4.2 and ICM running on a particular site. Without going into to much detail can someone please advise what would make the following services fail:-

TFE
MLSM
IS
SDP

For some reason that is becoming more and more regular these services fail.
Any input would be most gratefully accepted.

Kind Regards
V4DUR

 

[Devlekar]

Hi,

TFE - Call may routing will be default skillset
MLSM - CCMS will stop communication with 3rd Party Application
IS - Reports will not be available.
SDP - Reports will not be available.

Regards
ND

 

[V4DUR2]

Hi Mate,

Thanks for the repsonse - but do you knwo what could be causing them to fail?

Regards

 

[Devlekar]

Hi,

Skill based routing will stop & calls will route to default skill-set (DFDN)

Thanks & Regards
ND

 

[dulfo666]

Any problem with the E-Lan could cause the services to fail.

 

[sandyml]

Agree with dulfo666. Are you using a standalone hub/switch to connect the SCCS to the PBX? I've had those little hubs go bad, and the resulting congestion can cause this. If you are using a VLAN on your network, make sure it is isolated.

Have you checked the Event Log? Also look for TFE errors. If you have calls hitting a script that is causing a critical error (maybe programming, maybe trying to use a RAN or other voice announcement that is not working), that can cause SCCS to drop TFE and possibly the link to the PBX intermittently.

 

[V4DUR2]

cracking answers from the both of you guys there - the error we are seeing is:-

Error Code 48413
TFE service terminated due to an internal error: (Scheduler Thread. File/Func: .\nitfe_service.cpp/NITFE_clService::callback : line 1596)

and

TFE encountered some internal error ( fails.Cause/RC:45351.File/Func:.\nitfe_service.cpp/waitForServiceToEnd() : line 1313)

we are also seeing ALOT of these errors:-

Skillset List Error: (Call cannot be queued to same skillset again. Skillset: 10125. Call ID: 1970476566. File/Func: .\cpcall.cpp/CPCall::queueToSkillset() : line 2571.)

Any ideas?

 

[captaingadget]

Have you by chance created a circular dependency in your scripts? i.e. script A calls script B which calls script C which calls script A and so on. This endless loop will cause the TFE to crash out. Problems on the ELAN will cause trouble also.

 

[V4DUR2]

Hey Cap'

thats a big check to be completed - with the amount of scripts we have any ideas how we could go through and check these? lol

I have checked the script that is associated to skillset 10125 in the "Skillset List Error:" but i cannot see nothing out the ordinary other than:
GIVE CONTROLLED BROADCAST ANNOUNCEMENT
PLAY PROMPT VOICE SEGMENT vs_xxx_hold_message
DISCONNECT

I personally havent seen the broadcast alongside Play Prompt - it is usually:

OPEN VOICE SESSION
PLAY PROMPT VOICE SEGMENT vs_xxx_hold_message
DISCONNECT
(can someone verify this is ok)

Cheers again

 

[Milesprower]

Both commands are valid. I normally put the access IVR ACD_DN after the command:

OPEN VOICE SESSION access_acd_dn_gv

it is overkill, I know (global values should have this information already defined.)

Back to your initial issue: Either a hardware issue with the platform or (as captaingadget suggests) bad script writing.

If you can start collecting call by call statistics, it may give you information that will help you identify if certain scripts are the issue.

 

[captaingadget]

It's probably not as big a job as you think. But you still need to look at each PRIMARY script. Just scan though each and look for an EXECUTE SCRIPT command. If there are none then it's job done. If there is one then follow it through.

 

[sandyml]

It does look like you may have more than one problem. The one error:
Skillset List Error: (Call cannot be queued to same skillset again. Skillset: 10125. Call ID: 1970476566. File/Func: .\cpcall.cpp/CPCall::queueToSkillset() : line 2571.)

-- is certainly errors in script writing.

The others lead me to think you are calling a resource that is either not responding, announcement not recorded, or again is a scripting issue. Go through all your announcements and (1) make sure thay are recorded and playable, and (2) that the script variables that call them are correct (upper/lower case exact, name exact). Put these in a test script that just plays the announcement(s) and see if they will play.

Then, if you are using CallPilot, make sure all your ACCESS ports are acquired and working. Check your IVR PORTS report and see if you are getting a lot of calls not handled. You may have a problem on your CallPilot/MMail or PBX that is causing TFE failure.

 

[V4DUR2]

Thanks folks for all the updates, just to throw things into the mixer, this following error has appeared:-

VSM Request Failed. (Result: 2. Event: 11. Call ID: 1970481354. File/Funct: .\nitfe_cltaskvsm.cpp/Execute : line 515)

Does this tie back to CallPilot issue? im going to sit today and completely strip everything out as much as possible to see if i can find route cause. happy days!?

 

[picklemogg]

VSM errors are completely normal to see such as the one in the previous post. Not sure what you will be able to do on 4.2, but it's very possible that a patch may exist to correct your issues.

We recently upgraded to 6.0 and we had a couple of sites where we would have similar errors on TFE and ASM which would ultimately cause ELAN to jump around. Just installed a Nortel designer patch and all good now.

CCMS6.0 DP_060350 rules!

 

[V4DUR2]

Cheers picklemogg,

understandably one or two - however we were seeing this error every 2mins at one point, i managed to nail down - through the call ID provided in error - the script that was causing these and subsequently had removed all instances of in queue messaging (callpilot messaging) and these have now dropped considerably!

A new theory im thinking now is that the site is being flooded by calls that has recently been implemented in ICM scripting, and whilst in queue the callpilot cant deal with all these requests?!

Thoughts anyone?

 

[V4DUR2]

All,

Thanks for your inputs into this thread, we have now reduced the errors coming into the event browser 10 fold. there still are a SMALL numbers of VSM errors but no longer do i\we have the Skillset error as (you guys pointed out) there was an error in the scripting.

The call was in queue as normal then after music when it went through to the "loop" section and where the symposium was supposed to check if the call is not queued - place it in a queue. The command to check the queue was not there so it was trying to place the call back to the same queue.

If that doesnt make sense he is the sample script

SECTION loop
WAIT gv_delay_2
/* Check call still queued at original Skillset */
IF NOT OUT OF SERVICE skillnamexxx THEN
QUEUE TO SKILLSET skillnamexxx
WAIT 2

when it should show

SECTION loop
WAIT gv_delay_2
/* Check call still queued at original Skillset */
IF NOT QUEUED THEN
IF NOT OUT OF SERVICE skillnamexxx THEN
QUEUE TO SKILLSET skillnamexxx
WAIT 2

===========================================================

Now - anybody any ideas on what

Login Warning. (13203, 46, .\LoginRespTransaction.cpp/performTransaction)

this means - i know thats a login ID but i cannot see anything wrong with the user?

hopefully by getting rid of these errors our event browser can take it easy for a while.

AGAIN - THANKS TO ALL WHO INPUT IN THIS THREAD - MUCH APPRECIATED

 

[Supernn]

I would add to the last scripting the following:

SECTION loop
WAIT gv_delay_2
IF OUT OF SERVICE skillnamexxx OR AGE OF CALL > old_call_gv THEN
GIVE CONTROLLED BROADCAST ANNOUNCEMENT PLAY PROMPT VOICE SEGMENT notinservice_ann
END IF
IF NOT QUEUED THEN
QUEUE TO SKILLSET skillnamexxx
WAIT 2
END IF
GIVE CONTROLLED BROADCAST ANNOUNCEMENT PLAY PROMPT VOICE SEGMENT waitmsg_ann

Of course the GIVE CONTROLLED... can be replaced with OPEN VOICE SESSION and closed with END VOICE SESSION.
This way you also have an escape when the above mentioned skillset is out of service or takes a long amount of time.
Our script have the redicoulous time of 14400 seconds there.
If a customer still hangs for that amount of time they'll get a message and a disconnect, otherwise it might be a phantom call.