Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Calls jumping between paths 1

Status
Not open for further replies.

tomcotton

Technical User
Dec 19, 2007
175
I've got 3 clustered MXe's with one working like a trunk gateway and the other hosting a load of ACD paths. I've got a problem with calls jumping from one path to another. I've double checked the path programming and can't see any reason for this. The calls come in on 4009 (P409) then jump over to 4500 (P450). Here is the SMDR:

Digits dialed: P450 200 200
DNIS: 4009
Record: 06/22 15:50:24 0000:03:08 X9999 0025 P450 200 200 403 001 *********** 4009 A0026805 C

X9999 is our IP link, 200 200 are the agent groups.

Any ideas??
 
ACD can output multiple SMDR records for the same call depending on how the call is handled.

1) Are you sure this is the only record associated with this call?
2) Based on my knowledge 001 is the agent group, please be very specific on what 200, 403 and 001 represent.

**********************************************
What's most important is that you realise ... There is no spoon.
 
1) I've had a look at the SMDR records either side of this call and they don't seem related (although I'm not too sure our CCM would pickup the call on the way through our trunk gateway).

2) 200 is the agent group, 403 is the agent, just not too sure what 001 is. It only seems to be affecting this one path, but I just don;t know what would cause the DNIS to stay as 4009 but the call to be advertised and answered as 4500???
 
001 will be the system ID set in SMDR options assignment are all your system ID's set and different.
I think you need to provide more details as to how the call routes. ie What does the DDI match on the trunk controller, where do both the paths you mention exist.
A0026805 is the call ID so when looking for other SMDR record on the same call this is what you need to search for. The C after it is the sequence, Being this is a C that tells you there are at least 2 other records for this call (A&B)They may be out of time sequence as some records can be created when the call finishes and therefore created much later hence the Sequence field so no matter what time the record comes in the CCM knows what order to read them in.
 
The system ID is set to 1, and there is only one call showing on the CCM with a call id of A0026805. How do I search for SMDR on the actual controllers?

4009 is a rem dir entry on Sys71, which passes the call onto Sys70 which has a path of 4009. Within that path there are some custom RAD greetings and two agent groups. The RADs and Agent Groups aren't shared by path 4500, but that call still ends up there ??

Both paths are on Sys70 with the RAD ports and agent groups.
 
And you don't have any interflow or overflow setup between the paths? No Call rerouting of the one path to the other?

King of weird that a call would go from one path to the other unless it is transfered by an agent, send by call rerouting if the group was in DND or interflowed/overflowed to another path.

The single biggest problem with communications is the illusion that it has taken place.
 
from the maintanace commands you can do a "logs read smdr new xx" where xx is the number of records you want to see, You can also replace the number with ALL but this will take a long time to run.
Is your CCM not collecting SMDR from the other systems?.
Maybe a CCS trace from both systems at the same time will show better what is happening.
 
Here's a summary of the path programming:

Path Directory Number - 4009
Primary Agent Skill Group ID - 2016
Recording 1: Delay to Start Time Seconds - 0
Recording 1: Directory Number - 7187
Recording 2: Delay to Start Time Seconds - 30
Recording 2: Directory Number - 7173
Recording 2: Release Digit Receiver After Recording - No
Recording 3: Delay to Start Time Seconds - 50
Recording 3: Directory Number - 7167
Recording 3: Release Digit Receiver After Recording - No
Repeat Last Recording Enabled - Yes
Last Recording Repeat Interval Seconds - 20
Overflow 1 Agent Skill Group ID - 2154
Overflow 2 Agent Skill Group ID - 2013
Interflow Enabled - No
Interflow Point Directory Number - (blank)
Allow Overflow to Interflow Before Time Out - No
Path Unavailable Answer Point Directory Number - (blank)
Path Real Time Events Enabled - No
Interflow To This Path Uses This Path Priority - No
Primary Agent Skill Group Overflow Timer Seconds - 15
Primary Agent Skill Group Remote Agent Blocking Timer - 60
Overflow 1 Agent Skill Group Overflow Timer Minutes - 1
Overflow 1 Agent Skill Group Overflow Timer Seconds - 00
 
Boycey9 - This isn't happening all the time and we're a site of 700 users so I wouldn't want to leave any traces going. No the CCM only captures SMDR from the main user system, should I add the Trunk Gateway too?
 
If you add it to the other site then you will get the record from there as well which may help. Is this the only path it happens on? Maybe you need to spen some time recreating the issue try all different scenarios of agents logged in/out etc can learn how to make it happen then turn on a ccs trace it would help.
 
Any call reroute on 4009?

The single biggest problem with communications is the illusion that it has taken place.
 
This looks like the Overflow to me.

The path is programmed to overflow to groups 2154 and 2013

Based on what you have provided it looks like overflow is set to 15 seconds.

"Primary Agent Skill Group Overflow Timer Seconds - 15 "

That being said, I cannot find an option in the path programming that is labeled as you have provided. (What SW Version are you running?)

The call was answered after 25 seconds so if Overflow was engaged at 15 seconds .....


**********************************************
What's most important is that you realise ... There is no spoon.
 
Ive not put that bit in, the first group is a dummy agent group with no members to hold the call in while a call recording RAD is being played.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top