Business Phone Systems

Previous Thread
Next Thread
Print Thread
Rate Thread
Page 1 of 2 1 2
Joined: Oct 2017
Posts: 20
Member
OP Offline
Member
Joined: Oct 2017
Posts: 20
Currently, we have 4 ACD queues on our SV9100 that appear to be working properly. In the UC Dashboard, all the queues show active and are showing activity in the "Queue Performance". However, all of the agents in Queue 1 appear to be "out". Agents in Queue 2-4 will show "ready, on call, break, etc". In the UC admin, all the agents and queues show up. If I delete an agent, then make them logout and back in, it recreates that agent. So communications appears to be there. We are only using the Web-Based UC and not the desktop app.

I also noticed that in the UC Admin that is says 91 out of 160 Extensions are registered. All the SLT and IP phones show registered. Only partial MLT phones are registered. All the MLT phones associated with Queue 1 show "not registered". But some of the phones in Queue 2-4 show registered, while others do not. Doesn't appear to be any logic (chassis, card, etc)

All the agent phones in all the queues are digital (not IP) phones; with most being the same model and installed around the same time.

Back-story: We have been having minor issues for a few weeks. I think there was previous/partial configurations, possibly some database corruption of the Contact Center/UC SQLLite database. Two weeks ago, we reinstalled everything, but did not delete the directories, nor prior data. Last week, I didn't get a chance to work on it, but picked it back up this week. Tuesday, I uninstalled all the UC software, CTI Driver, Contact Center Server, etc. Renamed the directories to force it to truly recreate the database and configurations files. Once everything was reinstalled, it appeared to sync with the SV9100, as the Queue, Agent, Extension, COS, etc imported in. I made a simple name change and the SV9100 and UC software updated each other without me manually forcing a sync or rebooting the server (Yes, the server has been rebooted several times since the reinstall!). I thought everything was good, until I started re-creating the Dashboard Users and Tabs. That's when I noticed the Queue 1 Agent status was not getting updated; but other agents in other queues were.

I'm at a loss on where to look. I feel like I've looked over everything multiple times.

1) Why does UC Server think that some of the MLT phones are "not registered"? It says "160 extensions defined", "78 registered extensions".

2) Any suggested troubleshooting methods to see why these agents' status is not being updated?

-JA-

Atcom VoIP Demo
VoIP Demo
Joined: Sep 2004
Posts: 4,127
Likes: 1
Member
*****
Offline
Member
*****
Joined: Sep 2004
Posts: 4,127
Likes: 1
What versions of software are you running?

Have you gone into the web portal on the UC to configure everything?

How are you logging agents in. What method?

Are you and end user or installer and if either are you certified? (I ask because there is a lot to go through if not)

Joined: Oct 2017
Posts: 20
Member
OP Offline
Member
Joined: Oct 2017
Posts: 20
What versions of software are you running?
SV9100 is currently on 8.00.00; UC Service is 5.5.6; CTI Driver is 3.0.002; Contact Center Server is 2.2.6

Excluding the UC Suite; the Agents are able to log into the ACD group and calls are routing/queuing like they should.


Have you gone into the web portal on the UC to configure everything?
I did configure the UC Service Configurations (Server Settings, Web Settings). On the UC Admin, all the agents; except for the one queue imported without any problems. The queues, trunks, etc imported. Only thing I really setup was user access for myself and two others. The others mainly access the UC Dashboards.

As for the SV9100, I verified the ports, addresses and settings in 10-20, 10-69, 10-70, 10-71. I verified the settings in 20-57 through 20-64.

How are you logging agents in. What method?
There is a ACD Login/Logout on each agent's phone. Their login type is "Normal Login Mode" defined in 41-17. This queue is does not implement any skill based routing. It's just a basic ACD group.

Are you and end user or installer and if either are you certified? (I ask because there is a lot to go through if not)
I am an End-User; but work really close with the installer company. I did go through the Foundations course and certified with that. I am still in progress of working through other training modules on the Anytime site to increase my skill and knowledge. If we need, them, they will come back on site and are willing to contact their distributor; but it will be a few weeks before they can get back on site.


As far as further troubleshooting, I do have the CTI driver in Full Trace Logging; but really haven't seen anything useful in there that would help me diagnose this.
One suggestion I read/heard was to move the In-Skin blade from the company network to the IPL network, but then I would loose access to the web interfaces (unless I made some routing changes. Right now, our IP Phones are physically separated from our corp network . I tried to move it over, but got the same results (this was before the rebuild, though). Using WebPro, I did attempt to "reset" the various cards that support those particular phones, but no change. I have not rebooted the entire chassis, but have thought about it.

It's just really messing with my head that the other three queues came over fine, but not the queue 1. Makes me really think there may be an error in the Queue Programming, but nothing has change with the queues since we initially set them up 2-3 years ago. Just not sure where to look and reaching out.

-JA-


Joined: Oct 2017
Posts: 20
Member
OP Offline
Member
Joined: Oct 2017
Posts: 20
Also, I've went through the UC suite manual, admin manual, features and specs, an older ACD programming manual, and another manual that I can't remember off the top of my head.

Joined: Sep 2004
Posts: 4,127
Likes: 1
Member
*****
Offline
Member
*****
Joined: Sep 2004
Posts: 4,127
Likes: 1
OK. Try this. If you are using PC pro to program ACD groups don't. Use Web Pro. Remove ACD members apply and logout. Then go back into Web Pro and add them back in apply and log out. Make sure they can log into group 1 etc. Then restart your UC server.

There is newer software for the SV9100 v8.00.65. No idea if that is it. I would also verify the firewall is off on the UC server. The fact the UC server on the same network as the phone system is weird. MUCH easier to setup web access the other way IMHO. Resetting the phone system is always an option as well. Sometimes with ACD groups I have seen this. The other funky thing is remember ACD group by default is tied to RING group 1 You might need to make some changes to the TRK settings on the ACD group.

Joined: Sep 2004
Posts: 4,127
Likes: 1
Member
*****
Offline
Member
*****
Joined: Sep 2004
Posts: 4,127
Likes: 1
Originally Posted by Coral Tech
OK. Try this. If you are using PC pro to program ACD groups don't. Use Web Pro. Remove ACD members apply and logout. Then go back into Web Pro and add them back in apply and log out. Make sure they can log into group 1 etc. Then restart your UC server.

There is newer software for the SV9100 v8.00.65. No idea if that is it. I would also verify the firewall is off on the UC server. The fact the UC server on the same network as the phone system is weird. MUCH easier to setup web access the other way IMHO. Resetting the phone system is always an option as well. Sometimes with ACD groups I have seen this. The other funky thing is remember ACD group by default is tied to RING group 1 You might need to make some changes to the TRK settings on the ACD group.

*The fact the UC server isn't on

Joined: Oct 2017
Posts: 20
Member
OP Offline
Member
Joined: Oct 2017
Posts: 20
Thanks for the info. So it looks like it took a bit of time for the programming changes to settle in; thus everything appears to be working as it should. I was doing everything through PCPro. I do remember making some past changes to an ACD Group that didn't immediately take into affect; but the next day, everything was good. It's odd that there is such a delay on certain tasks, but other tasks (name changes, extension swaps, etc) are much quicker.

What I ended up doing was logging into WebPro and resetting all the DLCA Cards one at a time. A reset of the phone system probably would have helped, too. Once I reset the cards and rebooted the UC Server, everything started working better and more consistent. Although it did take overnight, everything finally synced up. Just frustrating that it wasn't happening quicker! I knew there were certain options that were only available in WebPro, but didn't realize it also impacted the programming of the system differently, too.

We knew there was a new version of the SV9100, but both the installer and I felt it would have had an impact. It was part of our troubleshooting path, just wasn't there yet. We still plan to upgrade, but at a more convenient time.

So with your statement about the UC Server being on a different network. Could you clarify? Let me provide some more details that I may not have been clear about. Next year, we will be re-working the subnets of our entire network, so this could be a factor in how we change the setup. Currently the IP of our system (GCD-CP10) at 10-12-01 is on the "Company" network; altough the gateway (10-12-03 is towards our VoIP network). The IP on our GCD-SVR2 is on the "Company" network. Now we also have an IPL 84-26-01 whose IP is on the VoIP Network. The way the installers did our VoIP Network is weird from my perspective; even with the way the two Point-to-Point T1's are setup. Even though I'm still somewhat limited on the SV9100, I would have setup the network differently; which is one reason why we are re-working things. Right now, we run isolated and physically separate networks for both VoIP and Company data. We will be subnetting and vlaning our company network and I would like to converge the VoIP network as part of the scheme. Should the GCD-SVR2 and GCD-CP10 still be on the company network or should the be on the VoIP only network and I'll use a router to bridge the two? Another reason we are looking at doing this is to also support a possible rollout of the UC Web/Desktop Suite to our CS Agents (for now).





Joined: Sep 2004
Posts: 4,127
Likes: 1
Member
*****
Offline
Member
*****
Joined: Sep 2004
Posts: 4,127
Likes: 1
Ya seems awfully convoluted. I mean with QOS, Diffserve and VLAN it just seems cumbersome the way you have it. I know why a company would do it so that if there are quality issues with the phones (that is always a network issue btw) that it would be isolated. But still...meh.

Joined: Apr 2005
Posts: 2,481
Likes: 1
Member
*****
Offline
Member
*****
Joined: Apr 2005
Posts: 2,481
Likes: 1
I don't know if Cora Tech would agree but I would put all of the NEC equipment on it's own subnet, (CPU, DSP, IP phones and so on)


We get old too soon, smart too late
Joined: Sep 2004
Posts: 4,127
Likes: 1
Member
*****
Offline
Member
*****
Joined: Sep 2004
Posts: 4,127
Likes: 1
I just throw it on the highest VLAN. Done... The switches I use auto VLAN by MAC so it recognizes the NEC MAC and tags the port auto. Trunk the port the VOIP card done. Don't even have to do this if you system is small. The amount of over engineering a 10 phone system is almost laughable. I have seen the switches on these system cost more than the equipment on them for no reason.

Page 1 of 2 1 2

Moderated by  ttech 

Link Copied to Clipboard
Forum Statistics
Forums84
Topics93,827
Posts636,768
Members49,645
Most Online5,661
May 23rd, 2018
Popular Topics(Views)
Today's Birthdays
Dan Powell, EKPTECH86, History, LinuxTech, Mike Miller, ttcfcl
Newest Members
KoolBreeze, PhoneGuy827, julesm, Helen.D, AlAl
49,644 Registered Users
Top Posters(30 Days)
ramo 12
pvj 11
Toner 9
Who's Online Now
0 members (), 12 guests, and 21 robots.
Key: Admin, Global Mod, Mod
Contact Us | Sponsored by Atcom: Business Phone Systems | Terms of Service

Sundance Communications is not affiliated with any of the above manufacturers.
©Copyright Sundance Communications 1998-2023
Powered by UBB.threads™ PHP Forum Software 7.7.5