Problem with calls Transferred to Symposium 1

[ccarmock]

I wonder if anyone can help with this weird problem.

I have an Option 81C - P4 processors and 4.5 software with Symposium 5.

I have a number of CDNs acquired by symposiums which work just fine when callers ring the DDI (DID!) numbers that map to them. Also if someone calls the CND from an extension on this switch or across the network it works fine too.

However we get some callers that run our switchboard and ask to be transferred to customer services. The switchboards at 2250's The Attendant transferrs the call to the CDN.

we then find it is processed as a non symposium call in effect and gets delivered to the ACD queue as if the CDN was not acquired.

This only happens for calls transferred from the Attendant. Calls transferred from a standard 3903 or 3904 for instance are dealt with my symposium as you would expect.

For these Attendant transferred calls we see the real time agent display in Symposium show the call as an ACDN call and offered to the agent with the longest idle time. However it bypasses all the call scripting.

I have another option 81C with Symposium 5, this one on CP4 processors and rel 4.0 software. Repeatign the test on this site does not show the problem.

Is there a prompt on the ACD queue or the Attendant setup that could cause this?

Any help appreciated.

Regards
Clive

 

[janeenaj]

I would ask and watch what the actual number that the attendant operator is xferring to.

 

[ccarmock]

Yup I wodnered that - I have watched them transfer to the correct CDN.

 

[janeenaj]

Are you routing based on DNIS, CLID, NPA...etc or anything like that?

Create a test scenario:
Build a test CDN and acquire.
At the top of the Master put in the following commands:
IF CDN = <insert test cdn here> THEN
ROUTE CALL <insert some xtension close by here>
END IF
Activate the script and have the attentant xfer to this CDN, if the xtension rings, its user error. If you get RNA - start looking at patches or call your vendor.

 

[ccarmock]

Ok will try that - thanks.

We route calls based on CDN - so our Master script looks very much like your example - exept we route the calls to skillsets.

Regards
Clive

 

[DRNurse]

What happens when the attendant calls the CDN (without transferring a call)?

 

[ccarmock]

The same thign happens when the attendant calls directly.

I have tried building both a phamtom that has a DCFW to my CDN and also with one ACDQ with MAXP=1 and NCFW to the CDN

Again when the attendant transfers calls to these the same thign happens - Symposium can't control the call.

 

[DRNurse]

Is it only 1 script/cdn where the Attendant isn't controlled or is it all of Symposium.
Have tested with 81C Rls 3 and ATT gets Symposium treatment, but not on-site to check CPU Version.
Would say that if only 1 CDN giving problem the it would be patch problem on PABX/SCCS, but if not then something on that script?
Any luck finding out the problem?

 

[lretrievers]

I would check to see if your PBX is up on all the current patches. I have seen this happen before, but remember the exact release of software, and there was a PBX patch for it.

 

[johnpoole]

another thought, because the operator is unlike a normal tdm phone, the call keeps the original dialed dn... that may be the block, add that dialed dn to your master (if possible) and it should send the call to the symposium.. another thing i have had to do was transfer the call external, and back in to the group.. but that later turned out to be a patch issue (non-related to this).. another thing i would do is captue the cdb from each switch and do a file compare... this could be caused by an cdb option that does not seem related cff/cfo for instance has caused me call flow problems that were not a forward but a transfer 'glitch'

john poole
bellsouth business
columbia,sc

 

[ccarmock]

Thanks for all this - some useful stuff for me to test tomorrow.

Regards
clive

 

[yyrkroon]

Add the following commands at the top of your Master Script...if you haven't already...

IF TRANFERRED OR CONFERENCED THEN
WAIT 6
ELSE
GIVE RINGBACK
END IF

This gives the PBX time to complete the xfer or conference before SCCS takes off with the call. But you mentioned that a direct call to the CDN does the same thing...I would say a corrupt CDN or patch issue.

Out the CDN and rebuild it, make sure to set CNTL and RPRT to no when creating the CDN.

 

[ccarmock]

Thanks to all who posted.

In the end the solution turned out to be putting:

IF TRANSFERRED OR CONFERENCED THEN
GIVE RINGBAKC
WAIT 6
END IF

at the start of the Master script. This isn't needed at the other main site we have however I suspect it could be purely the operators are quicker and completign the call transfer at one site. Adding these lines seems to have cured the problem.

 

[fixerguy]

Similar to your problem discription above I too have a problem with transfered calls from reception going to default ACD.

I do have the

IF TRANSFERRED OR CONFERENCED THEN
GIVE RINGBACK
WAIT 6
END IF

at the start of the master script yet the problem still presents itself. We recently upgraded from 4.2 to 5.0 and the PBX is running 4.0 I am still working through the other suggestions above. I wonder if this needs to be the first item in the Master or just near the top. I have a emergency global variable first which will play a emergency announcement should the unforseen happen and after that piece of script I have the If Transferred ...

 

[yyrkroon]

The IF TRANSFERRED OR CONFERENCED THEN must be the very first line in the master script.

 

[ccarmock]

It might be worth varying the WAIT time - if the operators are slow at releasing the call then you need to increase that timer.

Since a 2250 holds on to control of the call (until they RLS it) I think Symposium cant take control. It seems that console is a higher priority.

Regards
clive