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!

Tracking 'Dead Air' calls through TM and CCM6.0

Status
Not open for further replies.

rachelle

Technical User
Jul 30, 2003
220
US
We have only one of many toll-free skillsets reporting periodic 'dead air' calls. When we take those call examples and look at the raw data in the TM, we find the call. When we take those call examples and look at the CCM 6.0 Call by Call, we can't find the call anywhere. The TM data shows the call going to the dialable DN of one of our other locations. This is the only location currently working on this campaign.


Why do most of the calls work but, a select few are open air?
Why do none of the reported calls show up in the CCM Call by Call records but, they are found in the TM, CDR?
How do calls know to go to the dialable DN of the CCM but, do not post to the Master Script?

We have a meeting on 11/24 and they are expecting us to explain our findings. I have more questions than I do answers. Anyone have any experience with this?


rachelle

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
Are your Historical settings setup in such a way it should fill the Call By Call database?
Hence are the Master_Script and all related applications set to 'Local' (and 'Network' if applicable) in Configuration, Historical Settings?
 
Our database doesn't appear too full but, just to be certain, where would you look? All of the networked NCC skillsets and such are set to both local and network.

It is just so confusing that TM would se something that the CCM does not. With the agents reporting dead air, we need to find the source quickly.

Thank you so much for the feedback. Please keep the ideas coming.


Rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
what shows the display/CTI application - before - the Agent answer the call?
 
I assume from your posting that calls are arriving at one site and answered at another using Network Skillsets. In this case the call will arrive at the "local" site and will pass through the master script at this site and onto a primary script (application). In the primary application there will at some stage be a command QUEUE TO NETWORK SKILLSET xxxxxxx. When a free agent has been identified at the "distant" site, the call will essentially be transferred to the diallable DN for that site. It will not use the master script or primary application at the distant site. How are you searching the call by call stats, presumably by date and time. How are your site connected? You may simply have a faulty channel or something like that.
 
Our sites are connected with dedicated ISDN/PRI T1s. We don't know what is showing on the display other than the CLID, that the agents report. We have asked them to tell us what sk shows up but, so far, no one is reporting what we have asked for.

You are right. Calls come in to site A and are routed to site B. I have been searching my site A and site B CBC records for the CLID reported. This worked in the past but, this time I am not finding any of these calls.

TM finds the call but, CBC sees nothing.


rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
So you are getting reports of dead air on networked calls at the far end? Network reporting is complex - Captaingadget has started with the basics above. But you need a good understanding of the architecture and how calls peg to try and use reports to pin down this type of issue.

So let's ask some questions and we may get lucky.
Assumptions: two site network with dedicated trunks in between.
Question: Do all calls terminate on one site and network to the other? Or do calls terminate at both sites and network both ways?
Question: Are the dead air calls only reported for one network skillset (and the other network skillsets work)?
Question: are the dead air calls only reported at the distant site (not at the local site)?
Question: Are all the skillsets set up for Local Node Inclusion? Are they all identically configured?
Question: Do you have Network scripting set up to handle defaulted (far end agent becomes unavailable when call is being transferred) calls?

My rough guess from your description above is that the call is being set up properly, but that the voice path setup is failing. I have seen trunk configuration issues cause this. But, that would affect all call types.

Question: do you have call by call set up on both sites and at the NCC? Call by Call is a pain to sift through, but you can use search tools to try and find a problem call.
Question: Are you seeing any filtering of skillsets or sites in the network parameter table?
Question: Are you seeing any filtering or call failures in the alarm monitor or event log?


The better you can describe your current setup and define the issue, the better chance there is we may be able to help
 
1) Calls all come in to site A but, they are answered at site B. So, they terminat on one site and network to the other.

2) Yes, only this one networked skillset is having this issue. Many other skillsets use these same facilities (T1s, etc.)

3) Calls are only taken at the distant site. They have not brought up the staffing in the other locations, yet.

4) LNI is on almost all of the other NCCs. Only those skillsets that are not worked by site A are not using the LNI prompt.

5) I am not really sure. I believe that there is a default skillset configured but, I don't really know. I will have to look at the code. [for speed purposes, what am I looking for?]

6) Yes, CBC is set on the NCC as well as the CCMSs. I have looked at the CCMSs but, not the NCC. The NCC has a bigger database to go through. I will start there, today.

7) No filtering in the parameter table

8) No filtering in the alarm monitor


Thank you for such great questions. I will begin in the NCC Network CBC and post back, if I have any additional findings. If I still do not find these call examples, I will post that as well.


rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
From within the NCC, I can only choose one site at a time. I have the same results searching hear as I did going to the CCMS, Historical Data Reporting and looking at the CBC from there. These call examples just don't appear in the CBC.

These calls range in duration from 15 seconds to almost 2 minutes. That seems a bit long to hold the line for 'dead air' but, that is what we are finding.


Thoughts are next steps?




rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
Why would the TM be able to find these calls and show it handed to the other facility, via the dialable DN but, this same call example can't be found in the CCM CBC? Also, if these are all dead air, why are they holding the line for upwards of 3 minutes? Why would these people not call back and try again later?

None of this makes any sense.




rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
Here is the CallFlow ap, for this campaign. This app is used by other skillsets. We use variables to fill in the blanks. I don't believe that it is my code but, an extra set of eys would be great. Thanks!!!



/* Secondary network application for various groups at Census Bureau.
Calls reach this application from different Primary applications, initially based on source CDN.

**** SCRIPT LOGIC: QUEUE TO NETWORK SK, PLAY 1ST RAN, Queue to Network Supervisor's Skillset, ROUTE TO DN *********************************

This application is responsible for all call queuing, call routing, and call treatments. Application queues calls
to the appropriate skillset (based on source CDN) and then provides all treatment functions.

This script last modified per the date stamp by Nortel PSO *********************************************************/

EVENT HANDLER
EVENT IVR RESPONSE FAIL:
LOG "*** Secondary_NCC: IVR Response Failure ***"
GIVE RINGBACK
EVENT RAN RESPONSE FAIL:
LOG "*** Secondary_NCC: RAN Response Failure ***"
GIVE RINGBACK
END HANDLER

/* Check emergency agent status; if logged in play message and disconnect */

READVAR Flag_EmergCondition_NCC_cv
SAVEVAR

IF (Flag_EmergCondition_NCC_cv = 1) OR
(LOGGED OUT AGENT zz_EmergAgent_ID_NCC = FALSE) THEN
GIVE RAN 10
WAIT 10
DISCONNECT
END IF

/* Network skillset is available to receive calls. Queued call check made after initial queuing.
LNI option enables both local and network skillset queuing.
Code is expected to fall through to the next section - 'WaitLoop'. *************************************************/

QUEUE TO NETWORK SKILLSET SkillsetName_cv WITH PRIORITY 3

WAIT 4 /* provide sufficient time to queue across network */

/* Check for successful queuing at local and network skillsets */
IF PRIORITY IN QUEUE SkillsetName_cv <> 0 AND
PRIORITY IN NETWORK QUEUE SkillsetName_cv <> 0 THEN

EXECUTE CallQueued /* call is successfully queued */
END IF

/* Check for successful queuing at network skillset; requeue if needed */
IF PRIORITY IN NETWORK QUEUE SkillsetName_cv = 0 THEN
QUEUE TO NETWORK SKILLSET SkillsetName_cv WITH PRIORITY 3

WAIT 4
END IF

IF PRIORITY IN QUEUE SkillsetName_cv = 0 THEN
QUEUE TO SKILLSET SkillsetName_cv WITH PRIORITY 3

WAIT 4
END IF

SECTION CallQueued /*****************************************************************************************/

/* issue initial greeting */
GIVE RAN RANRt_cv

GIVE MUSIC 0

WAIT Time1stDelay_cv

QUEUE TO NETWORK SKILLSET SkillsetOverflowName_cv WITH PRIORITY 3
WAIT 4


/* Check for successful queueing at local and network skillsets*/

IF PRIORITY IN QUEUE SkillsetOverflowName_cv <> 0 AND
PRIORITY IN NETWORK QUEUE SkillsetOverflowName_cv <> 0 THEN

EXECUTE CallQueued2 /*call is successfully queued*/
END IF

/* Check for successful queuing at network skillset; requeue if needed */
IF PRIORITY IN NETWORK QUEUE SkillsetOverflowName_cv = 0 THEN
QUEUE TO NETWORK SKILLSET SkillsetOverflowName_cv WITH PRIORITY 3

WAIT 4
END IF

/* Check for successful queuing at local skillset; requeue if needed */
IF PRIORITY IN QUEUE SkillsetOverflowName_cv = 0 THEN
QUEUE TO SKILLSET SkillsetOverflowName_cv WITH PRIORITY 3

WAIT 4
END IF


SECTION CallQueued2
/* if queued successfully */

GIVE MUSIC 0

WAIT Time1stDelay_cv

ROUTE CALL DNSkillsetClosed_cv

SECTION UnscheduledClosure
/* This section handles unscheduled closure conditions - occurring when calls
reach the application during scheduled business hours, but the
skillset is not staffed and the call cannot be queued.
An exception condition message will be written
to the system event log, and the call will be provided the generic
unscheduled closure message, followed by a forced disconnect. */

LOG "*** NCC Network Skillset Call Flow9 Unscheduled closure ***"

ROUTE CALL DNSkillsetClosed_cv


no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
in the TM raw data - can you see any details - for example:the call is transferred?
 
I found several of these, in the event viewer under the Application log, at site A (site b doesn't show this): What would be cause and could this be the root of my issue?

Source: NGen
Category: Major
Event ID: 48514
Event from ICCM Task Flow Executor (TFE)[] : ASM request failed(Cause: 1.SS/Agt: 9.Call ID: 17958712.Resp:NIasm_cNWK_SKILLSET_QUEUE_CALL_RESP.File/Func:.\uc.cpp/CPUnackedCmds::doASMResponse() : line 6127)

Thoughts???? This may be a red herring.



rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
Here's another question:
Do the successful calls appear in the CBC stats? If it is just the dead air ones that do not, then this would suggest that the calls are not hitting the CC6 at all. I can't in all honesty say what would happen if you simply called the dialable DN without going through CC6. Perhaps you could try it??
 
TM shows the time the call comes in to site A, the trunk it enters on, the CLID is included here. It shows the duration of the call and the connection to the trunk group, via digits dialed, connecting site B. So, for example:

Site A
CLID Time Duration origtrk termtrk digits dialed
xxxx 00:00 :30 10004 35006 9115xxxx

Site B
CLID Time Duration origtrk termtrk digits dialed
xxxx 00:00 :30 22005 3400 nothing

So, site A sends the call to site B, via the dialable digits or the network CDN for that site. The call hits site B and it shows that it terminates on an extension number. The durations are usually 2 seconds longer in site B than in site A. Again, these calls range in duration from 22 seconds to now, over 3 minutes. None of these call examples show in CBC.

Thanks.

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
You are using

give ringback
wait 2

or

if transferred
wait 6
end if

in the masterscript?
 
Yes, the Master has both lines.

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
When does a CBC record begin and post? Does it only create a CBC if the caller reaches a voice mail or an answered phone? OR Does it create a record regardless of the calls termination?

rlc

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
grazy thing :)

is the agent reserve timer at least 2 seconds more than the Nodal Request Wait Timer.
 
Where would I find both, to be able to verify?

no matter where you go, there you are.
"This participation is persona and does not represent the United States Census Bureau." They make me say this.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top