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 strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Multiple SCCS on one switch 1
- Thread starter johnjacop
- Start date
brewerdude
IS-IT--Management
Do you want them as redundant servers or as a 2nd instance?
- Thread starter
- #3
I am not sure you can ... Partly due to the AML 16 functionality. I don't think you can configure two elan's or elinks to be running at the same time on the same switch customer. You have a secondary and a primary but not a dual.
Even if you could you would have to have two seperate Call Pilots to provide seperate sets of access ports. Additionally, agent phones would have to be seperated between systems and switch customers.
Not sure what your situation is but you would probably be better off with two seperate switches networked together.
Even if you could you would have to have two seperate Call Pilots to provide seperate sets of access ports. Additionally, agent phones would have to be seperated between systems and switch customers.
Not sure what your situation is but you would probably be better off with two seperate switches networked together.
- Thread starter
- #5
Thanks for the input, the NTPs state that it can be done with the programming of a separate ELAN connection and the use of SEPARATE switch resources, i.e., CallPilot, CDNs, phonesets, etc. I'll let you know how the install goes. Thanks again.............
Hello,
technically you can, having same Elan (and Ip, only one on each Cpu, and one active in all), but a new VSId. I did try that some years ago, not with a CCS but with two different generations of NTSP with Direct Connect. According to cgilmer, i would say that it's not ... wise. You will augment your risks and your work, with no real improvement.
Are you sure that your customer can not do other way ? It's fun for a salesman to sale a new CCS indeed, but not sure the tech guys will like it much
Regards,
PG
technically you can, having same Elan (and Ip, only one on each Cpu, and one active in all), but a new VSId. I did try that some years ago, not with a CCS but with two different generations of NTSP with Direct Connect. According to cgilmer, i would say that it's not ... wise. You will augment your risks and your work, with no real improvement.
Are you sure that your customer can not do other way ? It's fun for a salesman to sale a new CCS indeed, but not sure the tech guys will like it much
Regards,
PG
Yea the NTP's require you to build a new "customer" on the switch but I believe there are still some shared limitations. Thus building new phones and CDN's and such on a separate customer on your switch which make those dedicated resources to the 2nd system.
-
1
- #8
Symposium Call Center Server Release 5.0 introduces support for up to three
separate servers in Symposium Call Center Server connected to a single
Meridian 1/Succession 1000 switch. Each instance of Symposium Call Center
Server is a logically independent call center, controlling separate switch
resources.
I have this configuration in my lab. 3 SCCS, 1 SWC, 1 CP, 4 ELAN all on customer 0. Each SCCS is using 2 ports of the CP, 1 for ACCESS and 1 for IVR. All switch resources ARE NOT shared. Works like a champ...of course this is a lab environment...it always work like a champ in the lab...
separate servers in Symposium Call Center Server connected to a single
Meridian 1/Succession 1000 switch. Each instance of Symposium Call Center
Server is a logically independent call center, controlling separate switch
resources.
I have this configuration in my lab. 3 SCCS, 1 SWC, 1 CP, 4 ELAN all on customer 0. Each SCCS is using 2 ports of the CP, 1 for ACCESS and 1 for IVR. All switch resources ARE NOT shared. Works like a champ...of course this is a lab environment...it always work like a champ in the lab...
Hmmm... interesting that they have changed this. I can't imagine the confusion among using the same pool of agent ID's on a large call center between 3 servers considering all outage scenario's.
This would also require all Call Pilots and no Meridian Mails with the physical connection required on MerMail for enhanced services.
This would also require all Call Pilots and no Meridian Mails with the physical connection required on MerMail for enhanced services.
yeah, its pretty slick, but haven't quite figure out why anyone would need 3 SCCS on 1 PBX, unless its a multi tenant thing or they have that many agents...would hate to support that site.
Note: from experimenting: As long as they're seperate and not part of a network SCCS configuration everything seems to work just fine, very clean. As soon as you try to network them though...all hell break loose, having quite figure it out yet. The PBX INI, SCCS services crashes or the whole server just locks up
Note: from experimenting: As long as they're seperate and not part of a network SCCS configuration everything seems to work just fine, very clean. As soon as you try to network them though...all hell break loose, having quite figure it out yet. The PBX INI, SCCS services crashes or the whole server just locks up
coolicepbx
Programmer
Yyrkroon this setup might work in a lab but put it in a real call centre with some real volume, i wouldn't bet on that setup being very stable.
Martin
Martin
Well, I'll let you all know by June 1st. I'm installing 2 SCCS, a 96 port CP and a CS1000E for one of our customer. Currently their call volume is approx. 10K+/day (6AM-6PM)and they're expecting to increase that this summer.
Our SE along with Nortel SE sold them the soln and me and the rest of the boys gotta put it together and make it work...this is going to be interesting...
Our SE along with Nortel SE sold them the soln and me and the rest of the boys gotta put it together and make it work...this is going to be interesting...
- Thread starter
- #14
The installation went pretty well, there was only 1 major gotcha with the new 1000E/T pbx but we were able to work around that issue with Nortel TAC.
Apparently, passing DNIS from the 1000T to the 1000E turned out to be quite a hassle. The only way to get DNIS over the H.323 trunk was to set the routes up as DNIS routes but when you FNA to CP internally...the call would fail with CP picking up the main messagin DN and saying it doesn't subscribe to the service. Nortel provided a PI patch to fix the problem. This will be fixed in release 4.5.
When Nortel designed the E/T combination, they kinda forgot about the DNIS types calls. According to the feature specification, DNIS number does not propragate across the network unless using NACD or Network SCCS. Well, the designed of the 1000E and 1000T system was to act as 1 PBX but the coding sees this as 2 seperate PBX system so DNIS wasn't going to go get passed without NACD or Networked SCCS...only problem is you can't have an SCCS on the 1000T and we used up all 240 ACD-DN on the 1000T for the customer configuration.
Apparently, passing DNIS from the 1000T to the 1000E turned out to be quite a hassle. The only way to get DNIS over the H.323 trunk was to set the routes up as DNIS routes but when you FNA to CP internally...the call would fail with CP picking up the main messagin DN and saying it doesn't subscribe to the service. Nortel provided a PI patch to fix the problem. This will be fixed in release 4.5.
When Nortel designed the E/T combination, they kinda forgot about the DNIS types calls. According to the feature specification, DNIS number does not propragate across the network unless using NACD or Network SCCS. Well, the designed of the 1000E and 1000T system was to act as 1 PBX but the coding sees this as 2 seperate PBX system so DNIS wasn't going to go get passed without NACD or Networked SCCS...only problem is you can't have an SCCS on the 1000T and we used up all 240 ACD-DN on the 1000T for the customer configuration.
- Status
Similar threads
- Locked
- Question