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

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, b. 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ń, c. Współpraca z urządzeniami Gatekeeper H.323, d. 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, e. 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, f. 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, g. System powinien realizować funkcjonalność poczty głosowej z możliwością tworzenia skrzynek poczty głosowej dla użytkowników, h. System powinien realizować funkcjonalność tworzenia i obsługi indywidualnych zapowiedzi poczty głosowej przed przekierowaniem połączenia do skrzynki, i. System powinien realizować funkcjonalność tworzenia i obsługi indywidualnych zapowiedzi abonenckich przed zestawieniem połączenia przychodzącego do abonenta posiadającego pocztę głosową, j. 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ą, k. 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. System komunikacyjny powinien realizować funkcje zapowiedzi słownych IVR, 2. 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

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), 3. 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. 4. 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. 5. Musi współpracować z systemem nagrywania rozmów w celu rejestracji połączeń telefonicznych. 6. 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. 7. 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ń. 8. System powinien realizować funkcje nadzorcze w zakresie podglądu stanu kolejek ACD w Contact Center oraz poszczególnych agentów. 9. 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. 10. 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. 11. System musi być wspierany przez producenta do pracy w środowisku zwirtualizowanym. 12. 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. 13. 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. 14. System powinien mieć możliwość rozbudowy funkcji Contact Center dla helpdesku o kolejnych agentów dla co najmniej 400 aktywnych agentów łącznie. 15. 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. 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ę. 2. Możliwość pracy w klastrze w celu podniesienia niezawodności. 3. System powinien zapewniać przechowywanie indywidualnych list kontaktowych dla danego użytkownika. 4. System powinien wspierać protokoły standardowe SIP oraz XMPP. System powinien obsługiwać federację z innymi systemami XMPP. 5. System powinien wspierać funkcję group chat (czat z wieloma osobami jednocześnie) 6. 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. 7. 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. 8. 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 ). 9. 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. 10. 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. 11. 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

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. 3. 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. 4. 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. 5. System nagrywania rozmów musi pracować w klastrze dwóch serwerów (w trybie HA) oraz musi rejestrować 25 jednoczesnych połączeń audio. 6. Musi rejestrować połączenia audio w oparciu o standardowe kodeki głosowe: G.711, G.729 oraz G.722. 7. 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. 8. 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. 9. 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. 10. 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). 11. Aplikacja musi udostępniać interfejs programistyczny API umożliwiający realizację funkcji, co najmniej: str. 11

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. 12. 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. 13. Aplikacja musi być zintegrowana z systemem komunikacyjnym w zakresie autentykacji oraz autoryzacji użytkowników uprawnionych do dostępu do nagrań. 14. 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 15. 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ę. 16. Aplikacja musi mieć interfejs WWW dla administratorów oraz użytkowników. 17. 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. 18. 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. 19. Aplikacja musi zostać dostarczona wraz z licencją na system operacyjny, o ile taka dodatkowa licencja jest wymagana. 20. Aplikacja musi mieć możliwość pracy w trybie zwirtualizowanym oraz posiadać wsparcie techniczne producenta w tym trybie pracy. 21. Aplikacja powinna być zainstalowana na platformie serwerowej, np. wspólnie z innymi aplikacjami systemu komunikacyjnego. Dostawa platformy sprzętowej nie jest wymagana. 22. Z uwagi na wymaganą stabilność oraz niezawodność aplikacji, system operacyjny platformy powinien blokować możliwość instalacji innych aplikacji. 23. 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. Obsługa skrzynek osobistych i grupowych musi obejmować zarówno wysyłanie, jak i odbieranie faksów. 6. 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. 7. 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. 8. 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. 9. Musi wspierać protokoły SIP, H.323, T.38 oraz G.711 pass-through. 10. 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. 11. Musi mieć możliwość pracy w trybie wysokiej dostępności. 12. Musi generować alerty administracyjne na bazie SNMP oraz przez email. 13. 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). 14. System fax serwer należy dostarczyć jako kompletne rozwiązanie obejmujące aplikację oraz system operacyjny. 15. System fax serwer musi posiadać licencję na pracę klastra HA load balancing. IX. Skalowalność i architektura systemu zunifikowanej komunikacji: 1. 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. 2. 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. 3. 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 Opis Ilość UCS SP B22 ENTRY BDL 2x6248 1xCH UCS-SP6-ES-B22 2xB22w/2xE52420 48GB No 1 str. 13

UCS-SP-ENTS-B22M3 (Not a standalone SKU) B22M3 w/2xe5-242048gbvic1240 No 2 CON-SNT-SPENTS22 SMARTNET 8X5XNBD Smart Play B22 M3 Server No 2 N20-BBLKD UCS 2.5 inch HDD blanking panel Yes 4 N20-BHTS1 CPU heat sink for UCS B22 M3 and B200 M1/M2 Blade Servers Yes 4 UCS-CPU-E5-2420 1.90 GHz E5-2420/95W 6C/15MB Cache/DDR3 1333MHz Yes 4 UCS-MR-1X082RY-A 8GB DDR3-1600-MHz RDIMM/PC3-12800/dual rank/1.35v Yes 12 UCSB-MLOM-40G-01 Cisco UCS VIC 1240 modular LOM for M3 blade servers Yes 2 UCS-SP-INFRA-CHSS UCS SP BASE 5108 Blade Svr AC Chassis No 1 SMARTNET 8X5XNBD 5108 Blade Server CON-SNT-SPINFRAC Chassis No 1 N01-UAC1 Single phase AC power module for UCS 5108 Yes 1 N20-CAK Accessory kit for UCS 5108 Blade Server Chassis Yes 1 N20-CBLKB1 Blade slot blanking panel for UCS 5108/single slot Yes 8 N20-FAN5 Fan module for UCS 5108 Yes 8 N20-FW011 UCS Blade Server Chassis FW Package 2.1 Yes 1 UCS-IOM-2208XP UCS 2208XP I/O Module (8 External, 32 Internal 10Gb Ports) Yes 2 UCSB-PSU-2500ACPL 2500W Platinum AC Hot Plug Power Supply for UCS 5108 Chassis Yes 4 CAB-AC-2500W-EU Power Cord, 250Vac 16A, Europe No 4 UCS-SP-INFRA-FI UCS 6248 FI w/ 12p LIC Cables Bundle No 2 CON-SNT-SPINFRAF SMARTNET 8X5XNBD 6248UP Fabric Interconnect No 2 DS-SFP-FC8G-SW 8 Gbps Fibre Channel SW SFP+, LC Yes 12 SFP-10G-SR 10GBASE-SR SFP Module Yes 4 SFP-H10GB-CU3M 10GBASE-CU SFP+ Cable 3 Meter Yes 8 UCS-ACC-6248UP UCS 6248UP Chassis Accessory Kit Yes 2 UCS-BLKE-6200 UCS 6200 Series Expansion Module Blank Yes 2 UCS-FAN-6248UP UCS 6248UP Fan Module Yes 4 UCS-FI-DL2 UCS 6248 Layer 2 Daughter Card Yes 2 UCS-PSU-6248UP-AC UCS 6248UP Power Supply/100-240VAC Yes 4 CAB-9K10A-EU Power Cord, 250VAC 10A CEE 7/7 Plug, EU No 4 N10-MGT011 UCS Manager v2.1 Yes 2 UCSB-B200-M3-U UCS B200 M3 Blade Server w/o CPU mem HDD mlom/mezz (UPG) No 4 CON-SNT-B200M3-U SMARTNET 8X5XNBD UCS B200 M3 Blade Se No 4 UCS-CPU-E5-2630 2.30 GHz E5-2630/95W 6C/15MB Cache/DDR3 1333MHz No 8 UCS-MR-1X162RY-A 16GB DDR3-1600-MHz RDIMM/PC3-12800/dual rank/1.35v No 24 UCSB-MLOM-40G-01 Cisco UCS VIC 1240 modular LOM for M3 blade servers No 4 UCS-SD-16G 16GB SD Card module for UCS Servers No 4 UCSX-TPM1-001 TPM Module For UCS No 4 str. 14

N20-BBLKD UCS 2.5 inch HDD blanking panel Yes 8 UCSB-HS-01-EP CPU Heat Sink for UCS B200 M3 and B420 M3 Yes 8 UCSB-B200-M3-U UCS B200 M3 Blade Server w/o CPU mem HDD mlom/mezz (UPG) No 2 UCS-CPU-E5-2630 2.30 GHz E5-2630/95W 6C/15MB Cache/DDR3 1333MHz No 4 UCS-MR-1X162RY-A 16GB DDR3-1600-MHz RDIMM/PC3-12800/dual rank/1.35v No 4 UCSB-MLOM-40G-01 Cisco UCS VIC 1240 modular LOM for M3 blade servers No 2 UCS-SD-16G 16GB SD Card module for UCS Servers No 2 UCSX-TPM1-001 TPM Module For UCS No 2 N20-BBLKD UCS 2.5 inch HDD blanking panel Yes 4 UCSB-HS-01-EP CPU Heat Sink for UCS B200 M3 and B420 M3 Yes 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. 5. 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. 6. Wymaganie wysokiej dostępności dotyczy aplikacji systemu, nie wysokiej dostępności oferowanej w ramach platformy wirtualizacyjnej (np. VMWare HA). 7. 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. 8. System komunikacyjny powinien obejmować wszystkie wymagane licencje dla aplikacji oraz systemów operacyjnych. 9. 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. 10. 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

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. 11. 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. 12. 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. 13. 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 14. 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 15. 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.). 16. System komunikacyjny musi obejmować licencje na 20 portów serwera faksów do obsługi faksów. 17. System komunikacyjny musi obejmować licencje na 300 portów IVR 18. System komunikacyjny musi obejmować licencje dla 5 jednoczesnych agentów Contact Center dla usług helpdesku i infolinii 19. Integralną częścią systemu są bramy głosowe. Wymagane jest skonfigurowanie dwóch bram głosowych, które są w posiadaniu Zamawiającego. 20. Serwis producenta powinien obejmować subskrypcje uprawniające do nowych, bieżących wersji wszystkich aplikacji systemu w okresie serwisu. 21. Subskrypcje serwisowe powinny obejmować oprogramowanie dla całego systemu zunifikowanej komunikacji wraz z aplikacjami i systemami operacyjnymi na okres serwisu. str. 16