Contact Center question relating to Network Skillsets 1

[MrPederman]

I have two CCMS locations with a NCC server. If the NCC server is down, the documentation says network skillset calls will still be sent between the two locations. My question is, how does the system keep track of agents longest wait times, agents status etc. between the two locations? Is it the ELAN, CLAN MCDN D-Channel or ??.

 

[picklemogg]

It is true- NCC has nothing to do with the actual routing of network calls. You setup the local CCMS sites in the NCC server and the NCC propogates data to those CCMS sites. After this initial config all CCMS sites know about the others based on the data propogated from the NCC.

So when a call is networked- the local CCMS "1" application controlling call sends a request via CLAN to the other CCMS "2" server requesting an agent available in skillset ABC. If CCMS 2 has an agent available it sends a response back to CCMS 1 with info indicating longest idle agent and idle time.

So when CCMS 1 sends network call across tieline to CCMS 2 it already knows what agent call is destined for. Local application CCMS 1 sends call to CCMS 2 and pegs through CCMS net appl at site 2.

Hope that helps some- I'm in a hurry else would explain things better. Good luck.

 

[MrPederman]

Thanks for the response!

If you have a chance to get back to this post, what is the roll of our MCDN PRI TIE trunks between these two CCMS's?

Is the MCDN D-Channel what allows the call, call detail, skillset name, etc... to actually make it to the targeted agent across campus to CCMS 2?

 

[picklemogg]

No problem. The PRI tie is of course required for the actual voice path between the 2 sites. After you update NCC with CCMS sites it propagates data to the local CCMS nodes. After this "sync" happens, on your CCMS servers you define Network Communication Parameters under configuration. One parameter to define is the dialable DN used when sending a network call to another site. So in CCMS 1 you setup dialable DN to reach site 2 across your PRI tie route. The number you send it to has to be configured as a network CDN in your CCMS 2 server. So if site 1 is sending network call by dialing 8000 to site 2, site 2 must have 8000 built as a network CDN and acquired by CCMS.

So to go back to my previous post once a decision is made for CCMS site 1 to send call to a reserved agent at site 2 (which happens over CLAN) it sends the call essentially by dialing what is configured as dialable DN across PRI tie route.

I'm not 100% sure exactly what messaging happens across PRI but 1 thing is the original Call ID. I know that when CCMS 2 gets the initial request for agent from site 1 across CLAN it knows what skillset is being looked for and the PBX call ID from site 1 at that point. When site 1 sends call to site 2 CCMS network CDN via PRI route it passes PBX call ID from site 1 with call. I'd guess at that point the call ID that passes across PRI is matched up with the previous request CCMS knew about across CLAN and routes to agent that was originally reserved for that call.

I'm more than happy to help out if you need anything else. We have 6 sites networked and I had to learn the hard way since we had little vendor support.

 

[MrPederman]

That is a great detailed response. It all gets a bit confusing when you think of all the communication going on behind the scenes.

Can you think of any other info that you were surprised to learn as you troubleshot issues in your configuration? Or helpful tips and tricks?

Thanks again.

 

[picklemogg]

A couple things to note:

Make sure you establish a network routing plan that works for you. We use ESN- we have 6 sites but an example: site 1 has an HLOC of 441 and site 2 has an HLOC of 226. Network CDN at site 2 is 8000. We use 69 to use AC2 (opposed to 9 using AC1). Under AC2 we define LOCs of other sites and send to appropriate RLI. In CCMS we configure site 1 to send a call to site 2 by dialing 692268000. 69 looks to AC2- LOC 226 in AC2 says use RLI 1. RLI 1 says use Route 1 (route 1 is tie route to site 2). So when site 2 gets that call we send digits 2268000. The 226 is ultimately stripped and left with 8000. 800 terminates to CCMS network CDN at site 2. You can do this other ways like CDP, but just come up with a solid plan.

On the tie routes on both ends you need to make sure your PNI parm defined in RDB is the same. I believe by default PNI is 00001. If they do not match CCMS network calls will fail.

Make sure your Net Comm Parms defined in CCMS are defined correctly. Pay special attn to dialable DN and Nodal Request Wait Timer. Wait Timer refers to time local CCMS waits for responses back from network sites before it makes a routing decision. Can't remember default, but if we use anything other than 1 second we have probs. So I would say set this to 1- I think default could be 2 ironically. Funny story- I went to Net CCMS training and in lab i was seeing weird things like calls not completing, RNA, etc. It was new to me at time so I didn't know what to check for- instructor said it was prob cuz everyone was making changes to system. Once we deployed in our environment and I got to perform some additional testing I realized the reason I was seeing weird things in training was because the Wait timer was set to 2. I could reproduce exact scenarios in our environment. So I would set to 1 like I said. Maybe our environment is unique for some other reason but it works for us.

Make sure you provision correct amount of tie trunks. You need to provision based on how many network agents could be on calls at same time. Calls wait at local site until net agent is avail so you don't really provision based on call volume. For example I have 20 agents at site 2 and 20 agents at site 1. Let's say both sites networked back and forth. The most trunks you could ever possibly need for CCMS calls would be 40 if all agents at both sites were on net calls. You could have a million calls waiting at each local CCMS but since a tie trunk is not used until a net agent is avail you will never exceed 1:1 to agent. This is an easy example- when you have multiple sites and 1000s of agents it gets a little more complicated but wanted to illustrate the point. Not sure if Nortel meant it but 1 good design feature- If you queue a call to the same skill at both local and network site and a net agent is reserved for call. If for some reason (not enough tie trunks or tie route is down, CCMS is smart enough to know and will keep the call queued up locally. It's better than a busy signal.

Make sure you have your network CCMS appl configured for default treatment. When call is sent to net agent the call can be bumped back to queue. If it is bumped it will still remained queued to that skillset at the net site only. If the call was bumped and nobody was left logged into that skill- the net appl takes over call control. You need to have treatment setup such as if call is not queued- queued to skillset ABC or whatever.

Make sure you have appropriate SU and PEPs. We are running SU07 on CCMS 6.0 and we required what we call a network patch. We also had a DP on SU6 for this. We had an issue where 1 of our CCMS servers had a hardware failure and was offline. It impacted 3 other CCMS servers in network and they stopped processing calls. Never got a real answer but my hunch: we had many network calls queued up at time from site that went off network. When other sites tried to respond back to down site over ELAN they couldnt communicate back. As a result some process hung ultimately causing some sort of ELAN congestion back to PBX and we had to restart all 4 servers.

Understand impact on reports. Calls peg as ans through local appl even if ans at net site. However peg as call ans at net site from skill perspective. Know diff between skill and appl reporting. Also on agt perf rpt there is a field called reserved for call. You can have a net agent reserved for a call but not actually see the call delivered because an agent at another site could have been idle longer. So it is common to see reserved for call and no ans, but doesn't indicate call avoidance. It means the system didnt deliver call most likely cuz it found an agent that was idle longer or tie route issue.

When you have NCC in environment we have seen when NCC goes offline (reboot, etc...) the local CCMS server lose sync with NCC and it causes the HDM service on CCMS to hang. Anytime we restart NCC we check all CCMS servers to make sure HDM (historical data manager) is running. Half the time we need to restart since it shows unknown in sys mon. Never figured out why this happens but we just have learned to deal with it- not like we take NCC down often.

You need to add net skills from NCC. After you config in NCC it propagates that net skill to all CCMS sites. Once you see net skill in CCMS you can configure it. One parm around this is LNI (local node inclusion). If LNI is set to yes through scripting u can queue to both local and net agents in same skill at same time with Queue to Network Skillset ABC. If LNI is set to no you need to queue local and net agents with 2 steps:
Queue to skillset ABC (queues local only)
wait 2
Queue to network skillset ABC (queue network only)

Last thing I want to mention- if you have your configuration correct CCMS network routing works really well. We rarely have issues at this point.

Hope that gets you started.

 

[MrPederman]

Wow, thanks for the information. I know people's time is valuable and this response must have taken a lot of it.

You have given me a lot to chew on. Thanks again.