Załącznik Nr 1 - Szczegółowy Opis Przedmiotu Zamówienia

Transkrypt

Załącznik Nr 1 - Szczegółowy Opis Przedmiotu Zamówienia
Zp 2130-40/15
Załącznik Nr 1 do SIWZ
(Załącznik Nr 1 do umowy)
SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA
I. Wymagania ogólne dotyczące usług wdrożenia:
Niniejszy dokument opisuje wymagania dotyczące wdrożenia Oprogramowania. Zakres budowy
obejmuje zaprojektowanie i wykonanie procesu wdrożenia Oprogramowania w środowisku
teleinformatycznym Zamawiającego.
1. Projekt wdrożenia Oprogramowania
Wykonawca, przygotuje i przedstawi Zamawiającemu Projekt wdrożenia Oprogramowania.
Dokument będzie opisywał szczegółowo architekturę systemu, sposób konfiguracji i funkcje
poszczególnych elementów systemu oraz sposób realizacji wymagań przez system.
W szczególności projekt będzie zawierał specyfikacje oprogramowania, które zostaną dostarczone
Zamawiającemu.
Warunkiem wstępnym do rozpoczęcia właściwego wdrożenia Oprogramowania jest
zaakceptowanie przez Zamawiającego Projektu wdrożenia Oprogramowania.
W ramach wdrożenia należy wykonać
A. Aktualizacja (upgrade) systemu telefonii IP do najnowszej dostępnej wersji.
B. Przeniesienie aktualnie działającego systemu, wraz z licencjami do środowiska
wirtualnego, działającego na nowej platformie sprzętowej, wraz z integracją ze
środowiskiem data center oraz sieciami LAN i WAN użytkowanymi przez
Zamawiającego.
W szczególności:
a) Instalacja i konfiguracja serwerów wraz z wdrożeniem wymaganych funkcji zunifikowanej
komunikacji IP.
b) Instalacja i konfiguracja bramy multimedialnej .
c) Instalacja i konfiguracja dwóch bram głosowych IP wskazanych przez Zamawiającego oraz
zgodnie z przekazanym przez Zamawiającego planu numeracyjnego PSTN. Konieczne jest
podłączenie stykami typu SIP Trunk z operatorem telekomunikacyjnym świadczącym
usługi dostępu do sieci PSTN. Wymaga się by konfiguracja obu bram obejmowała plan
numeracyjny sieci PSTN by w przypadku uszkodzenia podstawowej bramy głosowej
możliwe było realizowanie usług komunikacji w ramach drugiej bramy.
d) Instalacja i konfiguracja systemu nagrywania (rejestratora) rozmów bez nagrywania
zapowiedzi do systemu IVR. Gotowe nagrania w postaci odpowiednich plików dostarczy
Zamawiający.
e) Instalacja i konfiguracja terminali IP wraz z wdrożeniem planu numeracyjnego.
f) Dla terminali IP z przystawkami skonfigurowanie układu typu sekretarsko-dyrektorskiego.
g) Podniesienie wersji oprogramowania we wszystkich terminalach IP Zamawiającego
zgodnie z wymaganiami producenta.
h) Zamawiający wymaga aby przed zmianą położenia obecnych punktów bezprzewodowych
o ile zajdzie taka potrzeba przeprowadzone zostało planowanie radiowe mające na celu
optymalne rozmieszczenie punktów dostępowych.
str. 1
i) Zamawiający na potrzeby wykonania planowania radiowego dostarczy Wykonawcy:
a. rzuty budynku wraz z informacją nt. możliwości wykorzystania infrastruktury IT –
liczby oraz lokalizacji dedykowanych na potrzeby sieci WLAN punktów
dostępowych, zlokalizowanych pod sufitem lub w przestrzeni nad sufitem
podwieszanym,
b. pule adresacji IP, które mogą zostać przeznaczone na potrzeby uruchomienia
poszczególnych elementów dostarczonych w ramach niniejszego postępowania,
c. pule numerów VLAN, które mogą zostać przeznaczone na potrzeby uruchomienia
poszczególnych elementów dostarczonych w ramach niniejszego postępowania,
d. dane umożliwiające podłączenie do serwerów AAA (radiusów) Zamawiającego
poszczególnych elementów dostarczonych w ramach niniejszego postępowania.
a) Zamawiający wymaga aby rozmieszczenie punktów dostępowych na terenie siedziby
Zamawiającego zapewniało poprawne parametry do prowadzenia rozmów poprzez
posiadane bezprzewodowe terminale IP.
b) Zamawiający wymaga aby konkretne miejsca instalacji poszczególnych punktów
dostępowych WLAN oraz sposób ich montażu został zaakceptowany przez
Zamawiającego przed instalacją.
c) Wszelkie wymagane elementy okablowania, np. patchordy miedziane kat. 6
i światłowodowe wymagane do podłączenia poszczególnych urządzeń zarówno
w punktach dystrybucyjnych jak i w miejscu docelowej instalacji muszą zostać dostarczone
przez Wykonawcę.
d) Oraz wszystkie inne niezbędne elementy do prawidłowego uruchomienia systemu.
C. Instruktaż administratora systemu telefonii IP w zakresie zarządzania nowym
systemem.
Zamawiający wymaga aby Wykonawca przeprowadził specjalistyczny instruktaż obsługi
dostarczonego rozwiązania. Zamawiający dopuszcza przeprowadzenie instruktażu na
dostarczonym w niniejszym postępowaniu sprzęcie. Zamawiający wymaga aby instruktaż odbywał
się w zakresie poszczególnych części z uwzględnieniem poniższych wymagań oraz aby obejmował
swoim zakresem co najmniej następujące zagadnienia:
4.1. W zakresie elementów:
a) Instruktaż z obsługi całego dostarczonego systemu,
b) Instruktaż musi być przeprowadzony w siedzibie Zamawiającego,
c) Instruktaż musi być prowadzony przez certyfikowanego inżyniera producenta lub
dystrybutora dostarczonego sprzętu,
d) Instruktaż musi być przeprowadzony dla min 2 inżynierów Zamawiającego, w wymiarze 5
dni roboczych po 8 godzin każdego dnia,
e) Instruktaż musi swoim zakresem pokrywać zagadnienia umożliwiające kadrze inżynierskiej
Zamawiającego poprawną instalację, uruchomienie i obsługę elementów dostarczonych.
Wykonawca dostarczy materiały instruktażowe co najmniej w wersji elektronicznej. Materiały
muszą obejmować co najmniej następujące zagadnienia:
a) Procedury instalacji,
b) Podstawowe procedury administracyjne,
c) Zarządzanie aktualizacją oprogramowania urządzeń,
d) Konfiguracja aspektów sieciowych,
e) Konfiguracja usług,
f) Integracja z istniejącymi usługami i sprzętem Zamawiającego,
g) Monitorowanie i logowanie zdarzeń,
str. 2
h) Obsługę system zarządzania infrastrukturą,
i) Zaawansowane rozwiązywanie problemów (ang. troubleshooting).
Aspekty konfiguracji muszą być omówione z poziomu aplikacji web i CLI.
D. Testy akceptacyjne
Testy akceptacyjne Wdrożenia Oprogramowania będą uwzględniały:
− Weryfikację podstawowych parametrów konfiguracyjnych Systemu,
− Weryfikację konfiguracji LAN/WAN i komunikacji między komponentami Systemu,
− Weryfikację konfiguracji LAN/WAN i komunikacji między integrowanymi systemami,
− Weryfikację konfiguracji baz danych dla Systemu,
− Weryfikację poprawności monitorowania warstwy sieciowej,
− Weryfikację zbierania danych historycznych,
− Symulowaną awarię komponentów Systemu,
− Weryfikację poprawności monitorowania aplikacji,
− Weryfikację poprawności definiowania i wykonywania raportów,
− Weryfikację spełnienia wymagań niefunkcjonalnych w obszarze niezawodnościowym
i wydajnościowym,
− Weryfikację poprawności działania innych funkcjonalności/wymagań Systemu,
uzgodnionych w Projekcie Wdrożenia Oprogramowania.
Kryterium akceptacji wdrożenia jest pozytywny wynik testów akceptacyjnych
E. Dokumentacja powykonawcza nowego systemu
Wykonawca po otrzymaniu akceptacji od Zamawiającego dot. całościowego wdrożenia przygotuje
i przekaże Zamawiającemu komplet dokumentacji powykonawczej dostarczonego
Oprogramowani wraz z opisem konfiguracji urządzeń Zamawiającego w ramach systemu
zunifikowanej komunikacji IP, zawierającą opis aktualnie zaimplementowanego rozwiązania
(zawierający m.in. plan zastosowanej adresacji dla poszczególnych urządzeń, planu numeracyjnego
GDS i PSTN, miejsce instalacji, konfiguracje urządzeń na dzień zakończenia wdrożenia, rozpisanie
wykorzystanych portów na poszczególnych urządzeniach).
Dokumentacja zostanie przekazana w formie elektronicznej.
II. Opis systemu zunifikowanej komunikacji
Podstawowe cele i charakterystyka systemu zunifikowanej komunikacji:
1. System musi realizować zadania zwiększające efektywność komunikacji:
a. Połączenia głosowe wysokiej jakości z wykorzystaniem kodeków szerokopasmowych,
b. Obsługa konferencji głosowych, w tym połączeń wielostronnych,
c. Obsługa połączeń wideo, w tym połączeń wielostronnych z zastosowaniem mostków
wideo,
d. Informowanie o aktualnym stanie dostępności innych użytkowników systemu
(dostępny/niedostępny/proszę-nie-przeszkadzać) na terminalu sprzętowym oraz
komunikatorze programowym,
e. Dostarczenie interfejsu użytkownika umożliwiającego łatwy dostęp do informacji
o nieodebranych/odebranych/wykonanych połączeniach, do poczty głosowej, a także
tworzenie własnych książek adresowych.
2. Obniżenie kosztów zarządzania i utrzymania systemu telekomunikacyjnego poprzez:
str. 3
a. Zdalne zarządzanie całym systemem,
b. Łatwe i szybkie dokonywanie zmian typu instalacja nowych terminali, zmiana ich
parametrów, przenoszenie ich na nowe miejsca pracy,
c. Wykorzystanie mini-przełącznika wbudowanego w terminal do podłączenia
komputerów do sieci LAN (współdzielenie łącza przez komputer i terminal) celem
obniżenia kosztów budowy struktury sieci LAN (mniej portów na przełącznikach
LAN).
3. Zwiększenie efektywności pracy poprzez:
a. Większą mobilność i dostępność użytkowników przez umożliwienie im logowania się
do systemu z dowolnego terminalu nim objętego,
b. Możliwość dostępu z poziomu terminalu do informacji pochodzących z różnorodnych
aplikacji merytorycznych,
c. Możliwość zdefiniowania dla użytkownika pojedynczego numeru urzędowego,
obejmującego osobisty terminal użytkownika w systemie oraz jego inne urządzenie
komunikacyjne spoza niego (np. telefon komórkowy),
d. Obsługa terminali bezprzewodowych.
4. Bezpieczeństwo komunikacji:
a. Możliwość szyfrowania połączeń,
b. Możliwość identyfikacji urządzeń za pomocą certyfikatów,
Funkcje zarządzania połączeniami w systemie zunifikowanej komunikacji:
1. Funkcjonalność systemu zunifikowanej komunikacji w zakresie obsługi połączeń i terminali
w zakresie telefonii oraz wideo musi obejmować:
a) Zestawianie połączeń w oparciu o zdefiniowany plan numeracji,
b) Możliwość odrzucenia połączeń,
c) Możliwość warunkowego przekazania połączeń gdy abonent rozmawia albo nie odbiera
połączenia, albo też bezwarunkowo wszystkich połączeń,
d) Parkowanie połączeń,
e) Funkcjonalność CallPickup,
f) Obsługa połączeń oczekujących,
g) Identyfikacja połączeń przychodzących,
h) Dostęp do książki telefonicznej bezpośrednio z ekranu terminala. Książka telefoniczna
musi mieć możliwość automatycznego uaktualniania z katalogu LDAP,
i) Obsługa klawiszy szybkiego wybierania numerów,
j) Podgląd stanu innych linii/numerów,
k) Możliwość transferowania połączeń,
l) Oddzwanianie (Callback),
m) Funkcje grup huntingowych z kolejkowaniem połączeń oraz odtwarzaniem dla połączeń
oczekujących zapowiedzi powitalnej i zapowiedzi w trakcie oczekiwania,
n) Realizacja audiokonferencji aranżowanych w trybach ad-hoc (rozumianym jako:
wydzwanianie kolejno do osób, które mają uczestniczyć w konferencji i kolejne dołączanie
ich do niej) i meet-me (rozumianym jako: samodzielne wdzwonienie się osób, które mają
uczestniczyć w konferencji na podany wcześniej numer), z możliwością udziału w nich
łącznie nie mniej niż 48 stron konferencji w jednej lub wielu konferencjach,
o) Realizacja wideokonferencji poprzez wdzwonienie uczestników konferencji do
indywidualnego pokoju wideokonferencyjnego wysokiej rozdzielczości HD przypisanego
do uprawnionego użytkownika (HD jest zdefiniowane w niniejszym opisie jako strumień
wideo 720p30 H264/AVC),
p) Konferencje wideo muszą być realizowane na bazie mostków wideokonferencyjnych
zarządzanych
z
systemu
sterowania
połączeniami.
Funkcja
mostków
wideokonferencyjnych powinny być realizowane na bazie mostków sprzętowych
str. 4
(dedykowany hardware) lub programowych (jako maszyna wirtualna). Możliwość
kaskadowania mostków dla celów redundancji oraz zwiększenia pojemności dla konferencji
wideo. Dostawa platformy sprzętowej do konferencji wideo nie jest wymagana,
q) Funkcjonalność sekretarsko-dyrektorską, w tym monitorowanie linii dyrektora przez
sekretariat, ograniczanie połączeń do dyrektora, możliwość włączenia przez dyrektora
statusu „nie przeszkadzać” oraz funkcję interkom,
r) Logowanie abonenta numerem PIN na telefonie IP, z zachowaniem profilu zalogowanego
abonenta (numery linii, uprawnienia abonenckie, ustawienia obsługi połączeń),
2. Funkcjonalność oprogramowania w zakresie zarządzania połączeniami musi obejmować:
a) Ograniczanie możliwości połączeń (restrykcje), w tym z wymaganiem podania kodu
dostępu,
b) Możliwość generowania raportów połączeń Call Detail Recorts (CDR), zawierających co
najmniej informacje statystyczne o numerach abonentów wywołującego i wywoływanego,
o czasie rozpoczęcia i zakończenia połączenia – dla celów późniejszego tworzenia
zestawień wykorzystania systemu telekomunikacyjnego przez jego użytkowników,
c) Możliwość generowania raportów połączeń Call Detail Recorts (CDR), zawierających co
najmniej informacje diagnostyczne o jakości połączenia (rodzaj kodeka, liczba wysłanych,
odebranych i zgubionych pakietów z próbkami głosowymi, zmienność opóźnienia
przesyłania tych pakietów a także wyliczona informacja o jakości podawana w postaci
uniwersalnej wartości MOS – Mean Opinion Score), dla celów monitorowania przez
administratorów realizacji transmisji głosu w systemie telekomunikacyjnym z właściwą
jakością,
d) Możliwość zalogowania się użytkownika na innym terminalu w systemie, co oznacza
czasowe przyjęcie na nim ustawień danego użytkownika (np. jego indywidualnych
uprawnień do wykonywania połączeń telefonicznych),
e) Możliwość zdefiniowania pojedynczego numeru biznesowego na stacjonarnym terminalu
użytkownika, którego wywołanie przez połączenie przychodzące z wnętrza systemu lub
z zewnątrz (z sieci PSTN) spowoduje automatyczne jednoczesne propagowanie tego
połączenia na inne zdefiniowane przez użytkowane numery urządzeń mobilnych (nie mniej
niż cztery). Po odebraniu takiego połączenia na którymkolwiek z nich musi być możliwe
przenoszenie połączenia pomiędzy urządzeniem mobilnym a terminalem użytkownika bez
konieczności przerywania połączenia,
f) Logiczne przypisanie do wielu terminali jednego i tego samego numeru (np. do terminala
stacjonarnego i terminala bezprzewodowego),
g) Narzędzia do centralnej konfiguracji i zarządzania systemem dla administratora, dostępne
poprzez przeglądarkę www,
h) Narzędzia zarządzania dla użytkowników końcowych dostępne przez przeglądarkę
internetową, dające im możliwość konfiguracji podstawowych parametrów ich terminala,
zrealizowane w języku polskim.
3. Funkcjonalność systemu zarządzania połączeniami musi zawierać:
a) wybór sposobu kompresji głosu dla połączenia - obsługa co najmniej standardów:
a. G.711, G.729 – dla zachowania zgodności systemu telekomunikacyjnego
ze starszymi typami telefonów IP oraz zapewnienia możliwości współpracy
z systemami telekomunikacyjnymi innych producentów,
b. G.722 – dla zapewnienia połączeń głosowych o podwyższonej jakości dźwięku,
c. iLBC – dla zapewnienia możliwości wykorzystywania terminali IP objętych
systemem telekomunikacyjnym w lokalizacjach objętych łączami o słabych lub
niegwarantowanych parametrach jakościowych QoS (np. połączenia VPN),
b) automatyczne wybieranie drogi (Auto Route Selection),
c) możliwość routingu połączeń na bazie czasu i daty,
d) narzędzia dynamicznego uaktualniania oprogramowania systemowego terminali,
str. 5
b.
c.
d.
e.
f.
g.
h.
i.
j.
k.
e) narzędzia dynamicznej wymiany routingu połączeń oraz informacji na temat planu
numeracyjnego (Call Control Discovery) z innymi systemami komunikacyjnymi,
f) obsługę standardowych protokołów komunikacyjnych,
a. H.323 - w zakresie komunikacji z bramami głosowymi oraz trunkami IP/H.323 do
innych systemów telekomunikacyjnych,
b. SIP - w zakresie: komunikacji z terminalami IP i bramami głosowymi oraz trunkami
IP/SIP do innych systemów telekomunikacyjnych a także dla zapewniania
przenoszenia informacji o dostępności użytkowników systemu,
g) System musi współpracować z bramami głosowymi w zakresie: obsługi protokołu MGCP,
obsługi przez bramę SIP Session Border Controller, obsługi przez bramę trybu awaryjnego
dla telefonii IP na wypadek awarii systemów centralnych lub sieci IP,
h) możliwość realizacji usługi wideotelefonii z wykorzystaniem terminali wideotelefonicznych
i) możliwość realizacji usługi wideotelefonii z wykorzystaniem aplikacji zainstalowanej na
stacji roboczej,
j) możliwość zabezpieczania sygnalizacji za pomocą standardowego protokołu TLS,
k) możliwość zestawiania połączeń szyfrowanych w oparciu o standardowy protokół sRTP
zarówno pomiędzy terminalami IP, jak też i do bram głosowych,
l) system sterowania połączeniami telefonicznymi oraz wideo powinien pracować w trybie
IPv4 oraz IPv6,
m) system zarządzania połączeniami powinien współpracować z systemami rejestracji rozmów
tel. w trybie aktywnym, tj. za pomocą konfiguracji przez administratora systemu
zarządzania połączeniami dla telefonu abonenta, którego rozmowy mają być nagrywane
drugiego strumienia VoIP (kierowanego do nagrywarki VoIP),
n) system sterowania połączeniami powinien realizować funkcje kontroli wykorzystania
pasma w sieci poprzez mechanizm Call Admission Control,
o) mechanizmy Call Admission Control systemu sterowania połączeniami powinny
współpracować z routerami IP w sieci LAN/WAN w celu rezerwacji pasma w sieci poprzez
protokół RSVP dla połączeń telefonicznych w sieciach rozległych,
Terminale systemu muszą mieć możliwość dowolnego przenoszenia w obszarze sieci IP (np.
przełączania do innych portów LAN) bez konieczności zmiany jakichkolwiek ustawień
w systemie. Odłączenie i ponowne podłączenie terminala nie może powodować utraty bądź
zmiany jego ustawień,
Współpraca z urządzeniami Gatekeeper H.323,
Dodawanie bram H.323, połączeń SIP trunk oraz współpraca z Gatekeeper H.323 powinno
być elastyczne i nie powinno wymagać żadnych dodatkowych licencji w systemie,
System powinien mieć możliwość rejestrowania terminali wideo na bazie protokołu SIP
w sposób umożliwiający zarządzanie nimi poprzez narzędzia administracyjne wbudowane
w system,
System powinien mieć możliwość rejestrowania mostków audio oraz wideo w sposób
umożliwiający zarządzanie nimi poprzez narzędzia administracyjne wbudowane w system,
System powinien realizować funkcjonalność poczty głosowej z możliwością tworzenia
skrzynek poczty głosowej dla użytkowników,
System powinien realizować funkcjonalność tworzenia i obsługi indywidualnych zapowiedzi
poczty głosowej przed przekierowaniem połączenia do skrzynki,
System powinien realizować funkcjonalność tworzenia i obsługi indywidualnych zapowiedzi
abonenckich przed zestawieniem połączenia przychodzącego do abonenta posiadającego
pocztę głosową,
System powinien zapewniać dostęp dla każdego abonenta posiadającego pocztę głosową do
aplikacji webowej, z której abonent może nagrać swoje powitanie oraz zmieniać ustawienia
kierowania połączeń na pocztę głosową,
Dla każdego użytkownika poczty głosowej system zapewnia integrację z pocztą elektroniczną
str. 6
w celu unifikacji wiadomości, co najmniej jako przesyłanie na konto emailowe abonenta
informacji pozostawionych na poczcie głosowej w formie emaila z załącznikiem,
l. System musi realizować funkcje pojedynczego logowania (Single Sign-On, SSO) realizowane
w oparciu o standard rynkowy Security Assertion Markup Language Single Sign-On (SAML
SSO) dla użytkowników oraz administratorów systemu komunikacyjnego dla funkcji
zarządzania połączeniami, informacji o dostępności oraz w celu konfiguracji funkcji poczty
głosowej,
m. System musi realizować funkcje emitowania muzyki podczas zawieszenia obsługiwanego
połączenia telefonicznego (ang. Music on Hold). Wymagana jest realizacja emitowania muzyki
w sieci IP w trybie rozsiewczym (multicast) oraz w postaci indywidualnych, oddzielnych sesji
(unicast),
n. System musi realizować funkcje emitowania wideo podczas zawieszenia obsługiwanego
połączenia wideo (ang. Video on Hold). Emitowanie wideo może być realizowane na bazie
dodatkowego serwera strumieniowania wideo, zdefiniowanego w systemie zarządzania
połączeniami. Zamawiający nie wymaga dostarczenia serwera strumieniowania,
o. System zarządzania połączeniami musi być zintegrowany z pozostałymi aplikacjami
i podsystemami dodatkowymi stanowiąc spójną platformę. Wymagana jest zgodność każdej
aplikacji z systemem zarządzania połączeniami, potwierdzona obustronnie przez obu
producentów producentów w formie informacji na publicznej stronie WWW. Wymaganie
zgodności z systemem zarządzania połączeniami dotyczy:
a. centralnego systemu IVR dla zapowiedzi głosowych oraz system dla
usług helpdesku,
b. funkcji informacji o dostępności,
c. zewnętrznej bramy multimedialnej,
d. systemu nagrywania rozmów.
III. Funkcje centralnego systemu IVR dla zapowiedzi głosowych:
1.
2.
System komunikacyjny powinien realizować funkcje zapowiedzi słownych IVR,
System IVR musi umożliwiać terminowanie połączeń telefonicznych i ich automatyczną
obsługę przez system zapowiedzi IVR (Interactive Voice Responder), definiowaną przez
skrypty budowane przez graficzne narzędzie. Obsługa skryptu musi umożliwiać:
a) odgrywanie zapowiedzi głosowych (pliki .wav),
b) odczyt i interpretację sygnałów DTMF,
c) możliwość sięgania do danych w źródłach HTTP/XML,
d) przekierowanie oraz zakończeniue połączenia.
3. System IVR powinien obsługiwać co najmniej 300 portów IVR jednocześnie.
4. System IVR powinny być realizowane przez aplikację opartą o protokół IP oraz zintegrowany
z systemem sterowania oraz bramami głosowymi systemu telefonii. Nie dopuszcza się
stosowania systemów hybrydowych, gdzie serwer ACD jest wyposażony w oddzielne interfejsy
TDM.
5. System IVR musi być wspierany przez producenta do pracy w środowisku zwirtualizowanym.
IV. Funkcje systemu dla usług helpdesku:
1.
System komunikacyjny powinien realizować zaawansowane funkcje zapowiedzi słownych IVR
oraz dystrybucji wywołań ACD dla grupy agentów w ramach centralnego Contact Center,
przeznaczonego dla usług helpdesku oraz infolinii.
2. System musi umożliwiać terminowanie połączeń telefonicznych i ich automatyczną obsługę
przez system zaawansowane zapowiedzi IVR (Interactive Voice Responder), definiowaną
przez skrypty budowane przez graficzne narzędzie. Obsługa skryptu musi umożliwiać:
a) odgrywanie zapowiedzi głosowych (pliki *.wav),
b) odczyt i interpretację sygnałów DTMF,
str. 7
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
c) możliwość sięgania do danych w źródłach HTTP/XML oraz baz danych poprzez
ODBC/SQL,
d) odczytywanie danych systemowych takich jak liczba osób oczekujących w kolejkach, średni
czas oczekiwania itp.,
e) możliwość przesyłania danych do programu, którym dysponuje agent systemu na swoim
komputerze PC,
f) kolejkowanie połączenia do wybranej kolejki z przypisaną do nich grupą agentów,
g) zarezerwowanie zdefiniowanego czasu dla zamknięcia połączenia, do celów sporządzenia
notatki oraz wpisania danych do innych aplikacji,
h) musi współpracować z systemami generowania automatycznych zapowiedzi głosowych
(funkcja Text to Speech, TTS) oraz systemami automatycznego rozpoznawania głosu
(ASR),
System powinien obsługiwać co najmniej 10 zaawansowanych portów IVR oraz co najmniej
5 agentów Contact Center jednocześnie. Musi umożliwiać pracę dla co najmniej 20
zdefiniowanych agentów przy założeniu, że jednocześnie pracujących (zalogowanych) jest co
najmniej 5.
W ramach kolejkowania połączeń system powinien obsługiwać wiele kanałów komunikacji,
co najmniej: telefonię (głos), połączenia wideo, czat oraz email jednocześnie, na bazie
pojedynczej aplikacji webowej agenta. Wymienione kanały komunikacji powinny być
obsługiwane przez każdego z 5 agentów Contact Center jednocześnie. Wymagana jest obsługa
połączeń w trybie dodzwaniania (inbound) oraz wydzwaniania połączeń (outbound) dla tych
agentów.
Musi współpracować z systemem nagrywania rozmów w celu rejestracji połączeń
telefonicznych.
Agenci Contact Center będący abonentami systemu są delegowani do obsługi kolejek ACD
i muszą posiadać aplikację webową na PC dedykowaną do obsługi połączeń oraz edycji stanu
gotowości (gotowy/nie gotowy/wylogowany) do przyjmowania kolejnych połączeń. Aplikacja
musi być w języku polskim.
Agenci Contact Center muszą mieć możliwość wykorzystania telefonu IP z aplikacją XML
w języku polskim (zamiast aplikacji webowej na PC) do obsługi połączeń oraz edycji stanu
gotowości (gotowy/nie gotowy/wylogowany) do przyjmowania kolejnych połączeń.
System powinien realizować funkcje nadzorcze w zakresie podglądu stanu kolejek ACD
w Contact Center oraz poszczególnych agentów.
System powinien realizować funkcje nadzorcze w zakresie generowania raportów
historycznych oraz bieżących z pracy systemu oraz pracy poszczególnych agentów. Raporty
powinny być dostępne poprzez www.
Funkcje Contact Center powinny być realizowane przez aplikację opartą o protokół IP oraz
zintegrowany z systemem sterowania oraz bramami głosowymi systemu telefonii. Nie
dopuszcza się stosowania systemów hybrydowych, gdzie serwer ACD jest wyposażony
w oddzielne interfejsy TDM.
System musi być wspierany przez producenta do pracy w środowisku zwirtualizowanym.
Funkcje Contact Center powinny uwzględniać kierowanie połączeń na bazie umiejętności
(skills based routing), co najmniej 50 zdefiniowanych kategorii umiejętności oraz 10 poziomów
umiejętności Agenta.
System powinien mieć możliwość obsługi funkcji nadzorczej (Supervisor) w Contact Center
w formie dedykowanej aplikacji na PC, do zarządzania pracą i monitorowania kolejek Contact
Center.
System powinien mieć możliwość rozbudowy funkcji Contact Center dla helpdesku
o kolejnych agentów dla co najmniej 400 aktywnych agentów łącznie.
System musi mieć możliwość rozbudowy do pracy w trybie klastra niezawodnościowego (HA),
także z możliwością pracy w trybie rozproszonym, w którym serwery klastra Contact Center
str. 8
połączone są poprzez sieć IP, co najmniej LAN oraz WAN.
V. Funkcje informacji o dostępności:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
System powinien umożliwiać agregację informacji o dostępności użytkownika korzystającego
z różnych terminali i udostępniać ją na dla komunikatorów programowych oraz innych
aplikacji wykorzystujących taką informację.
Możliwość pracy w klastrze w celu podniesienia niezawodności.
System powinien zapewniać przechowywanie indywidualnych list kontaktowych dla danego
użytkownika.
System powinien wspierać protokoły standardowe SIP oraz XMPP. System powinien
obsługiwać federację z innymi systemami XMPP.
System powinien wspierać funkcję „group chat” (czat z wieloma osobami jednocześnie)
Informacja o dostępności powinna uwzględniać kilka źródeł informacji:
a) zajętość abonenta w czasie rozmowy telefonicznej,
b) w czasie połączenia wideo,
c) zajętość wynikająca z zaplanowanego spotkania w kalendarzu,
d) zajętość zdefiniowaną samodzielnie przez użytkownika poprzez wpis statusu obecności do
komunikatora użytkownika.
System powinien zawierać aplikację komunikatora podstawowego dla użytkownika (na
komputery PC z OS Windows oraz MacOS) o funkcjonalności obejmującej:
a) informację o dostępności,
b) obsługę komunikacji tekstowej (ang. IM, „chat”),
c) sterowanie telefonem IP abonenta poprzez CTI za pośrednictwem systemu zarządzania
połączeniami,
d) współdzielenie pulpitu PC w środowisku OS Windows.
System powinien zawierać aplikację komunikatora podstawowego na urządzenia mobilne dla
użytkownika (co najmniej iPad, iPhone, Android, RIM BlackBerry) o funkcjonalności
obejmującej:
a) informację o dostępności,
b) obsługę komunikacji tekstowej (ang. IM, „chat”).
System powinien zawierać aplikację komunikatora zaawansowanego PC/Windows (na
komputer PC z OS Windows) o funkcjonalności obejmującej:
a) informację o dostępności,
b) komunikacji tekstowej (ang. IM, „chat”),
c) sterowanie telefonem IP abonenta poprzez CTI za pośrednictwem systemu zarządzania
połączeniami,
d) odsłuchiwanie poczty głosowej,
e) obsługę połączeń głosowych na bazie standardów G.711, G.722.1 oraz G.729a,
f) obsługę połączeń wideo HD ,
g) współdzielenie pulpitu PC.
System powinien zawierać aplikację komunikatora zaawansowanego MacOS (na komputer PC
z MacOS) o funkcjonalności obejmującej:
a) informację o dostępności,
b) komunikacji tekstowej (ang. IM, „chat”),
c) sterowanie telefonem IP abonenta poprzez CTI za pośrednictwem systemu zarządzania
połączeniami,
d) odsłuchiwanie poczty głosowej,
e) obsługę połączeń głosowych na bazie standardów G.711, G.722.1 oraz G.729a,
f) obsługę połączeń wideo HD.
System powinien mieć możliwość współpracy z aplikacją programowego komunikatora
zaawansowanego na urządzenia mobilne (co najmniej iPad, iPhone, Android)
str. 9
o funkcjonalności obejmującej:
a) informację o dostępności,
b) komunikacji tekstowej (ang. IM, „chat”),
c) odsłuchiwanie poczty głosowej,
d) obsługę połączeń głosowych na bazie standardów G.711 oraz G.722.1 lub G.729a,
e) obsługę połączeń wideo na bazie standardu H.264/AVC.
VI. Funkcje zewnętrznej bramy multimedialnej:
1.
System musi realizować funkcje obsługi połączeń spoza sieci wewnętrznej LAN/WAN
(np. z sieci innych podmiotów lub z sieci Internet) poprzez trawersowanie zewnętrznych
połączeń dla głosu, wideo, czat oraz funkcji presence za pomocą dedykowanej zewnętrznej
bramy multimedialnej, stanowiącej integralną część systemu komunikacyjnego.
2. Zewnętrzna brama multimedialna musi obsługiwać protokoły i mechanizmy kontrolne: H.323,
SIP, H.460.18/19, H.460.18 client-proxy, H.460.19 multiplexed media, STUN discovery oraz
STUN relay, STUN Firewall traversal.
3. Zewnętrzna brama multimedialna musi obsługiwać media: XMPP dla usług czat oraz funkcji
obecności, RTP oraz Secure RTP (SRTP), Binary Floor Control Protocol (BFCP).
4. Zewnętrzna brama multimedialna musi obsługiwać jednocześnie protokoły sieciowe IPv4
i IPv6. Musi realizować IPv4 / IPv6 interworking.
5. Zewnętrzna brama multimedialna musi obsługiwać funkcje bezpieczeństwa: HTTPS, SSH,
TLS oraz H.235.
6. Zewnętrzna brama multimedialna musi obsługiwać specyfikacje RFC o numerach: 2543, 3261,
3264, 1889, 3265, 3325, 3515, 3891, 3892, 2327, 4566, 5626, 5627, 5389, 5766.
7. Zewnętrzna brama multimedialna musi obsługiwać połączenia z sieci Internet od wszystkich
abonentów systemu (np. praca zdalna) wyposażonych w komunikator zaawansowany oraz
komunikator zaawansowany mobilny bez konieczności zestawiania połączenia VPN na
urządzeniu abonenta.
8. Pojemność zewnętrznej bramy multimedialnej musi wynosić co najmniej 2500 jednoczesnych
rejestracji urządzeń zdalnych w systemie zarządzania połączeniami. Musi mieć możliwość
realizacji co najmniej 100 jednoczesnych połączeń wideo oraz 200 jednoczesnych połączeń
audio.
9. Zewnętrzna brama multimedialna musi obsługiwać połączenia audio i wideo z systemów
w sieci Internet. Musi mieć możliwość obsługi połączeń zewnętrznych od innych podmiotów
(tzw. połączenia business to business, B2B) oraz od indywidualnych Klientów (client
to business, C2B). Dla scenariusza B2B wymagana jest obsługa 2 sesji wideo dla połączeń typu
B2B, należy dostarczyć wymagane licencje do świadczenia tej funkcji. W scenariuszu C2B
wymagana jest możliwość rozbudowy do obsługi połączeń audio oraz wideo na bazie
przeglądarki www ze strony Internetowej do systemu komunikacyjnego, zakładając obsługę
połączenia wideo na terminalach wideo, zgodnie z planem numeracyjnym systemu
komunikacyjnego.
10. Musi wspierać pracę w klastrze dla zwiększenia pojemności oraz podniesienia niezawodności.
Wymagana możliwość obsługi do min. 6 instancji w klastrze.
VII. System nagrywania rozmów:
1.
System do nagrywania rozmów musi być dedykowaną aplikacją. Musi być rozwiązaniem
programowym, które w pełni opiera się o architekturę IP, a połączenia TDM możliwe są
jedynie na zewnętrznych bramach głosowych.
2. Musi posiadać funkcjonalność do nagrywania rozmów wg poniższych wskazań:
a) System musi umożliwiać samoczynne nagrywanie rozmów telefonicznych na wskazanych
przez Zamawiającego numerach wewnętrznych,
b) System musi posiadać zarządzającą konsolę webową administratora w celu konfiguracji
str. 10
3.
4.
5.
6.
7.
8.
9.
10.
11.
parametrów pracy oraz uprawnień dostępu do nagrań,
c) System musi współpracować z aplikacją webową za pomocą której uprawniony użytkownik
będzie mógł wyszukiwać, filtrować, sortować oraz odsłuchiwać składowane materiały
nagrań. System musi automatycznie archiwizować nagrania na zewnętrznych serwerach
plików (np. serwera Secure FTP),
d) System musi mieć możliwość integracji z nadrzędnymi aplikacjami specjalizowanymi
w centralnej archiwizacji oraz aplikacjami do analizy nagrań poprzez otwarty interfejs
programistyczny API.
Aplikacja musi rejestrować ruch głosowy z odbieranych strumieni głosowych, w szczególności
musi spełniać poniższe funkcje:
a) nagrywanie aktywne z telefonu IP - za pomocą zduplikowanego głosowego strumienia IP
RTP z telefonu IP (tryb Dual Media Streaming),
b) nagrywanie aktywne z bramy głosowej - za pomocą zduplikowanego głosowego strumienia
IP RTP z bram głosowych ISDN (tryb Media Forking z bramy głosowej),
c) nagrywanie aktywne z dowolnego głosowego RTP z połączenia SIP, skierowanego do
aplikacji do nagrywania przez system sterowania połączeniami na bazie routingu połączeń:
dla połączeń przekierowanych oraz telekonferencji, kiedy system rejestracji jest jedną
ze stron telekonferencji, zarówno dla połączeń wewnętrznych, jak i zewnętrznych z PSTN.
Aplikacja musi mieć możliwość rejestracji ruchu wideo z odbieranych strumieni wideo
zgodnych ze standardem H.264 AVC, o rozdzielczości co najmniej VGA, od telefonów
wyposażonych w kamerę wideo, w szczególności musi spełniać poniższe funkcje:
a) nagrywanie strumienia wideo IP RTP z połączenia SIP, skierowanego do systemu rejestracji
przez system sterowania połączeniami (Call Control), np. zdublowane poprzez poprzez
funkcję Media Forking na bramie lub kiedy system rejestracji jest jedną ze stron
wideokonferencji na mostku MCU,
b) nagrywanie notatek wideo poprzez wdzwonienie się abonenta z telefonu IP z funkcją wideo
na numer kierujący połączenie do aplikacji do nagrywania rozmów,
c) dopuszcza się, aby funkcja rejestrowania połączeń wideo była możliwa po dodaniu odp.
licencji rozszerzających.
System nagrywania rozmów musi pracować w klastrze dwóch serwerów (w trybie HA) oraz
musi rejestrować 25 jednoczesnych połączeń audio.
Musi rejestrować połączenia audio w oparciu o standardowe kodeki głosowe: G.711, G.729
oraz G.722.
Musi umożliwiać dostęp do nagrań:
a) do trwających połączeń audio w oparciu o strumieniowanie RTSP,
b) do zarchiwizowanych nagrań poprzez plugin HTTP oraz po konwersji do pliku według
formatu standardu MP4 AAC oraz WMV.
Aplikacja musi rejestrować ruch głosowy dla obu kierunków rozmowy oddzielnie (od
abonenta oraz do abonenta) dla połączeń telefonicznych w sieci IP złożonych z dwóch
oddzielnych strumieni RTP.
Aplikacja musi rejestrować połączenia w trybie ciągłym, tj. dla wszystkich wykonanych
rozmów dla zdefiniowanych linii abonenckich IP, według podanej ilości sesji równoczesnych.
Aplikacja musi posiadać wbudowany interfejs webowy dla funkcji wyszukiwania i odtwarzania
nagrań o funkcjonalności co najmniej:
a) Wyszukiwanie zarejestrowanych nagrań głosowych oraz wideo poprzez filtry: czas
połączenia, czas trwania, numery abonentów, numer sesji, status nagrania (zakończone,
trwające),
b) Odsłuchiwanie trwających rozmów,
c) Pobieranie i archiwizowanie zakończonych rozmów (głosowych oraz wideo).
Aplikacja musi udostępniać interfejs programistyczny API umożliwiający realizację funkcji,
co najmniej:
str. 11
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
a) Wyszukiwanie zarejestrowanych nagrań głosowych oraz wideo,
b) Tagowanie nagrań poprzez dodawanie oraz edycję opisów do zarejestrowanych nagrań
głosowych oraz wideo,
c) Kopiowanie nagrań głosowych oraz wideo.
Aplikacja musi mieć możliwość integracji polegającej na udostępnieniu zarejestrowanych
nagrań do zewnętrznych systemów do analizy głosu oraz narzędzi do monitorowania systemu
nagrywania.
Aplikacja musi być zintegrowana z systemem komunikacyjnym w zakresie autentykacji oraz
autoryzacji użytkowników uprawnionych do dostępu do nagrań.
Aplikacja musi być zintegrowana z systemem telefonii IP w sposób umożliwiający
zdefiniowanie przez administratora systemu telefonii IP klawisza nagrywania na żądanie
w telefonie IP uprawnionego użytkownika
Aplikacja musi mieć możliwość wyświetlania listy połączeń będących w trakcie trwania
i aktualnie nagrywanych, zakończonych oraz zarejestrowanych, a także błędnych, których
zarejestrowanie nie powiodło się.
Aplikacja musi mieć interfejs WWW dla administratorów oraz użytkowników.
Aplikacja musi zostać dostarczona ze wszystkimi licencjami na nagrywane połączenia, które są
wymagane po stronie telefonów IP, bram głosowych i serwera sterowania połączeniami, o ile
takie licencje są wymagane.
Aplikacja musi mieć elastyczny sposób pracy oraz licencjonowania, umożliwiający rejestrację
jednoczesnych połączeń w dowolnym scenariuszu i rozkładzie ilościowym obsługiwanych
typów połączeń: nagrywanie aktywne z telefonu IP, nagrywanie z bramy głosowej, nagrywanie
połączeń przekierowanych i telekonferencji.
Aplikacja musi zostać dostarczona wraz z licencją na system operacyjny, o ile taka dodatkowa
licencja jest wymagana.
Aplikacja musi mieć możliwość pracy w trybie zwirtualizowanym oraz posiadać wsparcie
techniczne producenta w tym trybie pracy.
Aplikacja powinna być zainstalowana na platformie serwerowej, np. wspólnie z innymi
aplikacjami systemu komunikacyjnego. Dostawa platformy sprzętowej nie jest wymagana.
Z uwagi na wymaganą stabilność oraz niezawodność aplikacji, system operacyjny platformy
powinien blokować możliwość instalacji innych aplikacji.
Producent aplikacji rejestracji rozmów powinien posiadać udokumentowaną współpracę
z systemem telefonii IP.
VIII. Serwer faksów:
1.
Funkcje Serwera Faksów powinny być realizowane przez aplikację opartą o protokół IP oraz
zintegrowany z systemem sterowania oraz bramami głosowymi systemu telefonii. Nie
dopuszcza się stosowania systemów hybrydowych, gdzie serwer faksów jest wyposażony
w oddzielne interfejsy TDM.
2. Musi zapewnić użytkownikom wysyłkę faksów poprzez:
a) funkcjonalność przetworzenia wysłanego emaila na fax (Email 2 Fax),
b) funkcjonalność wysyłki poprzez wydruk dokumentu z aplikacji PC do serwera faksów
instalowanego jako sterownik systemowy w PC (Print 2 Fax),
c) poprzez interfejs www (Web 2 Fax),
d) funkcjonalność skanowania dokumentu i wysyłki go faksem przez serwer faksów,
oferowaną przez maszyny wielofunkcyjne, takie jak drukarki sieciowe z funkcją skanera
(Scan 2 Email).
3. Funkcja email na fax musi być wspierana przez serwery email na bazie protokołów SMTP,
POP3 oraz IMAP. Wymagane jest wsparcie dla wersji szyfrowanych tych protokołów na bazie
SSL/TLS, czyli odpowiednio: SMTPS, POP3S oraz IMAPS.
4. Musi zapewniać obsługę faksowych skrzynek osobistych oraz grupowych.
str. 12
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
Obsługa skrzynek osobistych i grupowych musi obejmować zarówno wysyłanie, jak
i odbieranie faksów.
System musi zapewnić użytkownikom odbieranie faksów z serwera faksów:
a) poprzez wysyłkę do skrzynki poczty email (Fax 2 Email),
b) poprzez funkcje automatycznego drukowania otrzymanego faksu na zdefiniowanej
drukarce sieciowej,
c) poprzez podgląd faksu przez interfejs webowy (Fax 2 Web),
d) przez podgląd z aplikacji mobilnej.
Musi umożliwiać użytkownikowi następujące funkcje:
a) faksowanie z komputera PC dokumentów w formatach: doc, docx, xls, xlsx, pdf, rtf, txt,
jpg, tif oraz tiff,
b) śledzenie z komputera PC statusów dotyczących postępu w wysyłce faksu,
c) wysyłanie i odbieranie faksów z poziomu komunikatora podstawowego oraz komunikatora
zaawansowanego dla komputera PC dla MS Windows,
d) wysyłanie i odbieranie faksów z urządzeń mobilnych pracujących na bazie systemu iOS
oraz Android,
e) dodawanie wybranej strony tytułowej do faksu wysyłanego z PC, komunikatora oraz
urządzenia mobilnego.
Musi umożliwiać dodawanie odbieranych faksów do:
a) systemów obiegu dokumentów,
b) systemów CRM/ERP do zarządzania kontaktami, relacjami oraz zasobami.
Musi wspierać protokoły SIP, H.323, T.38 oraz G.711 pass-through.
Musi obsługiwać administrację użytkownikami poprzez:
a) Ręczne dodawanie i modyfikowanie danych użytkowników,
b) Import z serwera katalogowego LDAP/OpenLDAP,
c) Import z serwera katalogowego Microsoft AD,
d) Import z systemu telefonii IP Cisco UCM poprzez interfejs AXL,
e) Import danych z pliku CSV.
Musi mieć możliwość pracy w trybie wysokiej dostępności.
Musi generować alerty administracyjne na bazie SNMP oraz przez email.
Musi obsługiwać jednocześnie co najmniej 20 transmisyjnych kanałów faksowych Fax over IP
(FoIP). Musi mieć możliwość rozbudowy do co najmniej 50 jednoczesnych kanałów
faksowych Fax over IP (FoIP).
System fax serwer należy dostarczyć jako kompletne rozwiązanie obejmujące aplikację oraz
system operacyjny.
System fax serwer musi posiadać licencję na pracę klastra HA load balancing.
IX. Skalowalność i architektura systemu zunifikowanej komunikacji:
1.
2.
3.
System musi mieć możliwość rozbudowy do poziomu co najmniej 10 tysięcy użytkowników
systemu dysponujących łącznie co najmniej 10 tysiącami terminalami IP: telefonami IP,
komunikatorami zaawansowanymi lub podstawowymi, terminalami wideo do pracy grupowej,
w dowolnej proporcji ilościowej.
System musi być oparty w całości o platformę zwirtualizowaną umożliwiającą kreowanie
maszyn wirtualnych dla poszczególnych komponentów aplikacyjnych na platformie
serwerowej Zamawiającego.
Platforma serwerowa jest w posiadaniu Zamawiającego i nie należy jej dostarczać.
Zamawiający posiada platformę serwerową o następujących parametrach:
Nazwa urządzenia
UCS-SP6-ES-B22
Opis
UCS SP B22 ENTRY BDL 2x6248 1xCH
2xB22w/2xE52420 48GB
Ilość
No
1
str. 13
UCS-SP-ENTS-B22M3
CON-SNT-SPENTS22
N20-BBLKD
N20-BHTS1
UCS-CPU-E5-2420
UCS-MR-1X082RY-A
UCSB-MLOM-40G-01
UCS-SP-INFRA-CHSS
CON-SNT-SPINFRAC
N01-UAC1
N20-CAK
N20-CBLKB1
N20-FAN5
N20-FW011
UCS-IOM-2208XP
UCSB-PSU-2500ACPL
CAB-AC-2500W-EU
UCS-SP-INFRA-FI
CON-SNT-SPINFRAF
DS-SFP-FC8G-SW
SFP-10G-SR
SFP-H10GB-CU3M
UCS-ACC-6248UP
UCS-BLKE-6200
UCS-FAN-6248UP
UCS-FI-DL2
UCS-PSU-6248UP-AC
CAB-9K10A-EU
N10-MGT011
UCSB-B200-M3-U
CON-SNT-B200M3-U
UCS-CPU-E5-2630
UCS-MR-1X162RY-A
UCSB-MLOM-40G-01
UCS-SD-16G
UCSX-TPM1-001
(Not a standalone SKU) B22M3 w/2xE5242048GBVIC1240
SMARTNET 8X5XNBD Smart Play B22 M3
Server
UCS 2.5 inch HDD blanking panel
CPU heat sink for UCS B22 M3 and B200
M1/M2 Blade Servers
1.90 GHz E5-2420/95W 6C/15MB
Cache/DDR3 1333MHz
8GB DDR3-1600-MHz RDIMM/PC312800/dual rank/1.35v
Cisco UCS VIC 1240 modular LOM for M3 blade
servers
UCS SP BASE 5108 Blade Svr AC Chassis
SMARTNET 8X5XNBD 5108 Blade Server
Chassis
Single phase AC power module for UCS 5108
Accessory kit for UCS 5108 Blade Server Chassis
Blade slot blanking panel for UCS 5108/single slot
Fan module for UCS 5108
UCS Blade Server Chassis FW Package 2.1
UCS 2208XP I/O Module (8 External, 32 Internal
10Gb Ports)
2500W Platinum AC Hot Plug Power Supply for
UCS 5108 Chassis
Power Cord, 250Vac 16A, Europe
UCS 6248 FI w/ 12p LIC Cables Bundle
SMARTNET 8X5XNBD 6248UP Fabric
Interconnect
8 Gbps Fibre Channel SW SFP+, LC
10GBASE-SR SFP Module
10GBASE-CU SFP+ Cable 3 Meter
UCS 6248UP Chassis Accessory Kit
UCS 6200 Series Expansion Module Blank
UCS 6248UP Fan Module
UCS 6248 Layer 2 Daughter Card
UCS 6248UP Power Supply/100-240VAC
Power Cord, 250VAC 10A CEE 7/7 Plug, EU
UCS Manager v2.1
UCS B200 M3 Blade Server w/o CPU mem
HDD mLOM/mezz (UPG)
SMARTNET 8X5XNBD UCS B200 M3 Blade Se
2.30 GHz E5-2630/95W 6C/15MB
Cache/DDR3 1333MHz
16GB DDR3-1600-MHz RDIMM/PC312800/dual rank/1.35v
Cisco UCS VIC 1240 modular LOM for M3 blade
servers
16GB SD Card module for UCS Servers
TPM Module For UCS
No
2
No
Yes
2
4
Yes
4
Yes
4
Yes
12
Yes
No
2
1
No
Yes
Yes
Yes
Yes
Yes
1
1
1
8
8
1
Yes
2
Yes
No
No
4
4
2
No
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
No
Yes
2
12
4
8
2
2
4
2
4
4
2
No
No
4
4
No
8
No
24
No
No
No
4
4
4
str. 14
N20-BBLKD
UCSB-HS-01-EP
UCSB-B200-M3-U
UCS-CPU-E5-2630
UCS-MR-1X162RY-A
UCSB-MLOM-40G-01
UCS-SD-16G
UCSX-TPM1-001
N20-BBLKD
UCSB-HS-01-EP
4.
5.
6.
7.
8.
9.
10.
UCS 2.5 inch HDD blanking panel
CPU Heat Sink for UCS B200 M3 and B420 M3
UCS B200 M3 Blade Server w/o CPU mem
HDD mLOM/mezz (UPG)
2.30 GHz E5-2630/95W 6C/15MB Cache/DDR3
1333MHz
16GB DDR3-1600-MHz RDIMM/PC312800/dual rank/1.35v
Cisco UCS VIC 1240 modular LOM for M3 blade
servers
16GB SD Card module for UCS Servers
TPM Module For UCS
UCS 2.5 inch HDD blanking panel
CPU Heat Sink for UCS B200 M3 and B420 M3
Yes
Yes
8
8
No
2
No
4
No
4
No
No
No
Yes
Yes
2
2
2
4
4
Posiadana platforma sprzętowa jest zdublowana i musi być zweryfikowana tak, aby spełniać
wymagania producenta system oraz mieć pełne wsparcie producenta dla całego system
komunikacyjnego.
Wymaganie redundancji odnośnie systemu musi obejmować funkcje związane z realizacją
połączeń i musi dotyczyć co najmniej:
a) serwerów odpowiedzialnych za zarządzanie połączeniami (Call Control),
b) funkcji informacji o dostępności,
c) zewnętrznej bramy multimedialnej,
d) systemu nagrywania rozmów .
Wymaganie wysokiej dostępności dotyczy aplikacji systemu, nie wysokiej dostępności
oferowanej w ramach platformy wirtualizacyjnej (np. VMWare HA).
Jeżeli Oferent opiera mechanizmy HA na bazie platformy wirtualizacyjnej, to muszą być one
w pełni wspierane przez producenta rozwiązania komunikacyjnego pod względem
technicznym.
System komunikacyjny powinien obejmować wszystkie wymagane licencje dla aplikacji oraz
systemów operacyjnych.
Zamawiający posiada aktualnie następujące urządzenia końcowe:
a) Aparaty podstawowe IP typ1: typ: 7926G, ilość: 20,
b) Aparaty podstawowe IP typ2: typ: 7965G z przystawką, ilość: 14,
c) Aparaty podstawowe IP typ3: typ: 7965G , ilość: 20,
d) Aparaty podstawowe IP typ4: typ: 9951 z przystawką, ilość: 15,
e) Aparaty podstawowe IP typ5: typ: 9951, ilość: 15,
f) Aparaty podstawowe IP typ6: typ: 6901, ilość: 5,
g) Terminal konferencyjny typ7: 8831, ilość: 5.
System komunikacyjny musi obsługiwać posiadane przez Zamawiającego urządzenia końcowe
Cisco serii 6900, 7900, 8900, 9900 oraz terminal konferencyjny wideo SX20, w zakresie co
najmniej:
a) Pobierania oraz wymiany plików konfiguracyjnych oraz oprogramowania z serwerów
komunikacyjnych,
b) Obsługi oprogramowania (firmware), które jest podpisany cyfrowo przez producenta oraz
pliki konfiguracyjne zaszyfrowane przez serwery komunikacyjne,
c) Możliwości zdalnej zmiany ustawień urządzenia: numer i opis linii, funkcje przypisane do
programowalnych klawiszy funkcyjnych, uprawnienia abonenckie dla danych linii
urządzenia, przypisanie do właściwych elementów infrastruktury (bramy głosowe i mostki
MCU),
str. 15
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
d) Możliwości zdalnego restartu urządzenia lub grupy urządzeń,
e) Możliwości dystrybucji certyfikatów dla urządzeń z serwerów komunikacyjnych.
System komunikacyjny musi obejmować następujące licencje w ilości 5 dla profilu
uproszczonego z zakresem funkcjonalnym obejmującym co najmniej:
a) obsługa 1 telefonu IP Cisco typu 6901, posiadane aktualnie przez Zamawiającego.
System komunikacyjny musi obejmować następujące licencje w ilości 75 dla profilu
podstawowego z zakresem funkcjonalnym obejmującym co najmniej:
a) obsługa 1 telefonu IP Cisco – dowolny model z serii 7900, 8900 oraz 9900, posiadane
aktualnie przez Zamawiającego,
b) komunikator podstawowy dla PC/Windows oraz PC/MacOS,
c) komunikator podstawowy na urządzenia mobilne.
System komunikacyjny musi obejmować następujące licencje w ilości 25 dla profilu
zaawansowanego z zakresem funkcjonalnym obejmującym co najmniej:
a) jednoczesna obsługa łącznie co najmniej 4 dowolnych urządzeń końcowych abonenta
spośród tu wymienionych: telefony IP Cisco – dowolny model z serii 7900, 8900 oraz 9900
posiadane aktualnie przez Zamawiającego, komunikator zaawansowany dla PC/Windows,
komunikator zaawansowany dla PC/MacOS, komunikator zaawansowany na urządzenia
mobilne.
b) komunikator podstawowy dla PC/Windows oraz PC/MacOS,
c) komunikator podstawowy na urządzenia mobilne,
d) skrzynka poczty głosowej,
e) indywidualny 4-stronny pokój wideokonferencyjny HD
System komunikacyjny musi obejmować licencje w ilości 1 dla realizacji funkcji terminala
wideo do pracy grupowej dowolnego typu z poniższej listy:
a) obsługa 1 terminala konferencyjnego wideo typu Cisco SX20, posiadanego przez
Zamawiającego,
b) komunikator podstawowy dla PC/Windows oraz PC/MacOS,
c) komunikator podstawowy na urządzenia mobilne
Funkcje spotkań grupowych wideo, realizowane poprzez indywidualne 4-stronne pokoje
wideokonferencyjne HD, będące częścią profilu zaawansownego, będą realizowane
ze wspólnej puli oszacowanej na 16 licencji na sesje (porty) HD na mostku. Platformę
serwerową dla mostka zapewni Zamawiający, natomiast od Oferenta oczekuje się dostawy
elementów licencyjnych tj. licencje na mostek (1 szt.) oraz licencje na porty HD (16 szt.).
System komunikacyjny musi obejmować licencje na 20 portów serwera faksów do obsługi
faksów.
System komunikacyjny musi obejmować licencje na 300 portów IVR
System komunikacyjny musi obejmować licencje dla 5 jednoczesnych agentów Contact Center
dla usług helpdesku i infolinii
Integralną częścią systemu są bramy głosowe. Wymagane jest skonfigurowanie dwóch bram
głosowych, które są w posiadaniu Zamawiającego.
Serwis producenta powinien obejmować subskrypcje uprawniające do nowych, bieżących
wersji wszystkich aplikacji systemu w okresie serwisu.
Subskrypcje serwisowe powinny obejmować oprogramowanie dla całego systemu
zunifikowanej komunikacji wraz z aplikacjami i systemami operacyjnymi na okres serwisu.
str. 16