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

[rachelle]

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.

 

[sandyml]

Question - can you confirm that networking between these two sites is working normally?

 

[mcpeppi]

i believe:
ccma -> configuration -> network communication parameters

 

[rachelle]

There are a tone of different call campaigns that are routed this same pathway that are all working. Only this one seems to be having an issue. Thus the weirdness!!!



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.

 

[Milesprower]

The error you referenced above: ASM request failed, is it for the call type for which you get dead air? Sometimes a call will "hang" in the script if your access voice segment is not properly set up. This would explain the varying times for the call length (callers abandoning at different times).

Can you look up the call id in CBC to verify if it is one of the "bad" calls?

 

[dj4020]

What does the display on the agent phone show. could be these calls are getting Basic ACD treatment rather than CCMS routing. Have you tried to trak a call when you get the dead air? ? ?

 

[rachelle]

Sandy, yes the T1s are working 100%.
Mcpeppi, the agent reserve timer is 10 seconds and the nodal timer is set at 3 seconds.
Milesprower, I can't find the call examples at all.
DJ4020, we have not traced a live occurrence of dead air, yet. We have asked for them to contact us, so that we can see a live session. [I like it... a live, dead call... that just isn't right]

YIKES!!!!

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.

 

[Milesprower]

Did you say you had not updated the network script in the far end (target) system? Can you give us a copy of the Network script for the far end system?

Also, run an application call treatment report for the network script for the target site. Does it show a lot of abandons?

 

[rachelle]

Milesprower, I'm not sure what you mean by the Network script. We have not made any changes to the NCC_ap for this campaign, since it began. The 'dead air' calls seems to only happen during high call volumn, so I am being told. The script that I posted earlier today should be what you need to see. This campaign queues to a NCC_ap skillset, plays a Ran message, queues to a 2nd NCC_ap, and then delivers it to voice mail, if still no one is available to answer the call.


I can't run an application call treatment report from the site B server. The NCC skillset is not an option. It is only an option from the Site A server. In running the report from Site A, it shows 2 routed, 902 offered, 839 answered, 60 abandoned. What is routed?

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.

 

[dj4020]

Rachelle have you been able to reproduce this say from calling with a cell phone or hammering it with some associates to try to reproduce the issue. I know sometimes agents are hard to get to cooperate when these types of issues occur no paycheck on troubleshooting for most of them. If you can get it to reproduce might be easier to troubleshoot. I do not know how big your callcenter is but perhaps if you also turn on Dchannel messaging on this incoming route could shed some light on actual call flow. You previously asked where do CBC stats start, they start when call presented to the master script and start receiving treatment from the master script. In light of this statement it appears your calls have found a way around CCMS and using Basic ACD instead. Do you have an ACD, or CDN programmed with this dialed DN as either NCFW, or DFDN respectively ? ? As far as the TFE errors with associated ASM errors we have hundreds of those types of errors and no problems here. As you stated a Red Herring I think.

 

[rachelle]

I have 13 inbound/outbound T1s, at site A. There are two T1s that connect site A to site B. Dch messages are really overwhelming, considering that all three sites perform more that 1 million calls, per day.

The dialable DN for site B routes calls over the 2 connecting T1s. The dialable DN is the Network CDN and is built:
TYPE CDN
CUST 0
CDN 4100
FRRT
SRRT
FROA NO
UUI NO
MURT
CDSQ NO
DFDN 4179
NAME NO
CMB YES
CEIL 2047
OVFL NO
TDNS NO
RPRT YES
AACQ YES
ASID 16
SFNB
USFB 1 3 4 5 6 7 9 10 11 12 13 14 15
CALB 0 1 2 3 4 5 6 8 9 10 11 12
CNTL YES
VSID
HSID
CWTH 1
BYTH 0
OVTH 2047
STIO
TSFT 20

4179 is the ACD queue that NCFW to voice mail box.

If the calls were coming in on the ACD, they would have to present to the telephone sets that are hardcoded to the ACD queue 4179. Right? They are not. They are happening all over the place and not just in those seats.

Very confused but, thank you for keeping me on the right track and thinking.




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.

 

[dj4020]

Rachelle the CDN is a Control Directory Number if a call were to follow its routing it would go to the far end PBX it would only default to 4179 if 4100 was unavailable for a call to go to.

 

[dj4020]

Another though might be do you have agent transfer calls directly to another number in case they end up in the wrong place maybe they are coming from there? ? ? Its a thought. . .

 

[dj4020]

Actually the 4100 has got to be a steering code allowing 4 digit routing across your T1's

 

[rachelle]

Right. My point exactly. None of the station sets that have reported this issue are built with key 0 in this ACD queue. That is why I don't believe that these calls are by-passing the CCM.

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.

 

[rachelle]

Transfer could be an issue but, I have no clear method of testing.
4100 is a CDN and is associated to the dialable DN of that network site.

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.

 

[Milesprower]

I'm sorry, you have lost me. You should be able to see and run reports for both sites. The CCMA application should be attached to both sites so you can manage your networked system.

The Network script at the far end handles calls when reserved agents are not available when call is delivered to the far end site.

My SWAG: you have a timing issue (others have suggested to look at the timing parameters) and agents are not reserved long enough for the call to be delivered under high call conditions (or agents are not paying attention to reserved state on their display).

If the network script has not been updated from the default Nortel text, it will not provide treatment while the call is being requeued to the far end skillset. Callers hear dead air (and because the system is busy it takes a while to find another agent to deliver the call).

 

[rachelle]

I think that we do have an issue of agents going off-hook without regard for the Reserved Status of the set.

With regard to the Network_Script that was placed in our systems, at the time of installation, what triggers this code to come in to play? I don't see any other _ap that reference this _ap. Is the Network_Script a default script that the system must have, because its name is hard coded in the Nortel application software? If it isn't driven by the Nortel software then, I don't see where any of my callers have hit this Network_Script. Below is the script. This has been in place since 2006. What are the best practices and recommendations for how this should or should not be changed?


/* Network application for network calls routed from Jeffersonville to Tucson that have been rejected by a reserved
agent at the Tucson site.

This application is responsible for providing treatment while the caller is routed to another agent within the original skillset.
If the call becomes dequeued, caller is either queued to the Supervisor skillsets or routed to a mailbox.

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

GIVE RINGBACK
WAIT 2 /* required to avoid race conditions with music */


SECTION WaitLoop
WAIT 10
IF NOT QUEUED THEN
IF NOT OUT OF SERVICE Supervisors_sk THEN
QUEUE TO SKILLSET Supervisors_sk WITH PRIORITY 3
WAIT 2
ELSE
ROUTE CALL 0000
END IF
END IF

EXECUTE WaitLoop



Again, you have my continued thanks, for working so closely with us.

Cheers,
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.

 

[yyrkroon]

You're not going to find a root cause for an intermittent issue without running some traces, looking at the CBC report isn't enough, especially if you're trying to find the call using CLID vs Call ID.

Every call coming into the PBX and CCMS is assigned a unique Call ID for the life of the call. CLID is auxillary data to the CCMS, the data is there, but depending on several other factors may or may not show in the CBC.

You'll need to turn on AML, EB and ASM traces on both the local and remote CCMS. You'll have to rely on the agents/supervisor to inform you of the problem so you can stop the traces and capture the data.

You'll need to know when the event happened, the CLID of the caller and the number that was dialed.

Note: Since your sites are networked, you'll have a Call ID and a Network Call ID when the call goes across the network

You start with the AML trace to get the Call ID. To find the correct Call ID you'll need the CLID of the call and approx time of the call to narrow down your search - note: CLID is always present in the AML trace.

Once you have the Call ID, check the EB trace, this will give you a hint if events are out of order or not. Then on too ASM to find out what was going on with the agent set during that time frame.

Follow the Call ID/Network Call ID.

 

[rachelle]

I have never performed any tracing from these areas before. Are these logs always up or do I need to turn them up? From where on the CCMS do I access these items? Sorry for the basics but, I typically don't touch the server, I only work through the CCMA interface. 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.

 

[dj4020]

Rachelle I just want to reiterate the CDN can bypass the CCM your CDN is directed to go to site b because it is built as a steering code. To jump back to a question from CaptainGadget what happens when you dial the CDN 4100 ? ? ? Does it get treatment from CCM or does it just go to Agent at site b? ? ? ?