Załącznik nr 1 SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA SPECYFIKACJA TECHNICZNA

Załącznik nr 1 SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA SPECYFIKACJA TECHNICZNA NAZWA ZAMÓWIENIA NADANA PRZEZ ZAMAWIAJĄCEGO Zakup i wdrożenie central VoIP z licencjami dostępowymi do centrali jako rozbudowa istniejącego systemu telekomunikacyjnego UW PRZEDMIOT ZAMÓWIENIA Projekt ma na celu wdrożenie systemu komunikacji VoIP dla potrzeb Uniwersytetu Warszawskiego. System VoIP musi zapewnić pełną integrację z posiadaną obecnie przez UW infrastrukturą teleinformatyczną oraz zapewnić możliwość łatwej migracji użytkowników do nowego systemu. Zakres projektu obejmuje: a) Dostawa, uruchomienie i wdrożenie centrali telefonicznej typu Softswitch SIP o funkcjonalnościach i na warunkach określonych w Rozdziale 2; b) Dostawa, uruchomienie i wdrożenie modułów do posiadanych przez Zamawiającego central TDM o funkcjonalnościach i na warunkach określonych Rozdziale 3; c) Dostawa, uruchomienie i wdrożenie systemu bilingowego o funkcjonalnościach i na warunkach określonych w Rozdziale 4; d) Dostawa, uruchomienie i wdrożenie systemu poczty głosowej o funkcjonalnościach i na warunkach określonych w Rozdziale 5; e) Dostawa, uruchomienie i wdrożenie systemu faksowego o funkcjonalnościach i na warunkach określonych w Rozdziale 6; f) Dostawa, uruchomienie i wdrożenie licencji użytkowników końcowych oraz terminali końcowych o funkcjonalnościach i na warunkach określonych w Rozdziale 7; g) Integracja działania wszystkich komponentów Systemu oraz Infrastruktury w zakresie i na warunkach określonych w Rozdziale 8; h) Usługa szkoleń dla personelu Zamawiającego, w zakresie i na warunkach określonych w Rozdziale 9; i) Usługa opieki serwisowej przez 12 miesięcy od podpisania Protokołu odbioru prac wskazanych w punktach a) g), w zakresie i na warunkach określonych w Rozdziale 10. Poniżej przedstawiona została szczegółowa specyfikacja techniczna poszczególnych elementów systemu, wymaga się aby wyspecyfikowane funkcjonalności były dostępne w dniu składania oferty, a nie rozwijane w trakcie realizacji zamówienia. Ogólne warunki zakupu i wdrożenia zostały określone w Rozdziale 1. - 1 -

Zakres systemu jest zgrupowany w 3 części A), B) i C), zestawienie ilościowe komponentów systemu w poszczególnych częściach zostało przedstawione w Rozdziale 11. 1. OGÓLNE WARUNKI ZAKUPU I WDROŻENIA 1.1. Dostawa poszczególnych elementów systemu i produkcyjne uruchomienie Systemu musi zostać przeprowadzone w terminie do 6 tygodni od momentu podpisania umowy. 1.2. Przeprowadzanie szkoleń musi odbyć się w terminie do 8 tygodni od odbioru działającego Systemu. 1.3. System musi być kompletny, tj. musi posiadać wszystkie niezbędne elementy sprzętowe (hardware konieczny do uruchomienia systemu zgodnie z wymaganiami), programowe oraz licencyjne. 1.4. Wszelkie dostarczone licencje muszą być udostępnione Zamawiającemu bezterminowo. 1.5. Wykonawca w ramach realizacji projektu dostarczy instrukcje obsługi w języku polskim dla użytkowników końcowych do wszystkich elementów rozwiązania (telefony, awizo, aplikacje użytkowników). 1.6. Sprzęt dostarczony w ramach realizacji umowy musi być sprzętem nowym, nieużywanym wcześniej (wyprodukowany nie wcześniej niż w 2011 roku). Niezbędne licencje muszą być przeznaczone wyłącznie na potrzeby korzystania ze sprzętu będącego przedmiotem dostawy na cały czas jego użytkowania. Licencje nie mogą pochodzić z systemów demo i systemów innych użytkowników. 1.7. Sprzęt dostarczony w ramach realizacji umowy musi składać się wyłącznie z oryginalnych części producenta. Zamawiający nie dopuszcza zamienników sprzętowych ani programowych. 1.8. Sprzęt dostarczony w ramach realizacji umowy musi być zakupionym w oficjalnym kanale sprzedaży producenta na rynek polski, musi być sprzętem nowym i posiadającym stosowny pakiet usług gwarancyjnych kierowanych do użytkowników z obszaru Rzeczpospolitej Polskiej. 1.9. Wykonawca odpowiedzialny za instalację i serwisowanie systemu musi posiadać status partnera przyznany przez producenta oferowanego systemu na terytorium Polski. 1.10. Wszelkie dostarczone serwery komputerowe muszą spełniać następujące warunki: 1.10.1. Obudowa przystosowana do montażu w szafie rack 19 z zestawem szyn do mocowania 1.10.2. Płyta główna dedykowana do prasy w środowisku serwerowym wyprodukowana przez producenta serwera 1.10.3. Redundantny zasilacz co najmniej jeden więcej niż niezbędna do poprawnego działania ilość 1.10.4. Wsparcie dla systemów MS Windows Server 2003, 2008, Linux Redhat, Linux SUSE 1.10.5. Serwery muszą być wyposażone w karty zdalnego zarządzania pozwalające na: 1.10.5.1. Włączenie/wyłączenie/restart serwera - 2 -

1.10.5.2. Dostęp do konsoli szeregowej serwera 1.10.5.3. Dostęp do ekranu, klawiatury i myszy serwera 1.11. Przed przystąpieniem do wdrożenia Wykonawca dostarczy projekt wdrożeniowy, zawierającego co najmniej szczegółową specyfikację dostaw, plan numeracyjny, fizyczne rozmieszczenie urządzeń, adresację oraz wymagania wobec Zamawiającego. 1.12. W ramach wdrożenia Wykonawca przeprowadzi testy poprawności działania poszczególnych komponentów Systemu i przedstawi z nich raport. 1.13. Zamawiający dopuszcza użycie / migrację dla potrzeb nowego systemu VoIP posiadanych przez Zamawiającego 400 licencji Comscendo do central HiPath 4000 v3. 1.14. Wykonawca musi podsiadać certyfikat systemu zarządzania jakością ISO 9001 w zakresie sprzedaży, wsparcia technicznego i serwisu rozwiązań telekomunikacyjnych (lub równorzędny). Producent musi posiadać certyfikację ISO 14001 (lub równorzędny). 2. CENTRALA TELEFONICZNA TYPU SOFTSWITCH SIP 2.1. System do realizacji usług głosowych w sieci IP musi opierać się na architekturze Softswitch i protokole SIP RFC3261 i działać wyłącznie w oparciu o komutację pakietów w sieci IP. 2.2. System musi charakteryzować się otwartą architekturą, musi umożliwiać przyłączanie terminali użytkowników różnych dostawców w oparciu o protokół SIP. 2.3. System musi pozwalać na korzystanie z łączy SIP trunk, łącza SIP trunk i kanały głosowe w SIP trunk nie mogą być ograniczane licencjami (dodawanie kanałów głosowych w SIP trunk nie może wymagać wykupienia dodatkowych licencji). 2.4. System musi charakteryzować się otwartą architekturą, musi umożliwiać przyłączanie aplikacji różnych dostawców np. IVR w oparciu o protokół SIP. 2.5. Podłączanie terminali obcych dostawców nie może wymagać wykupienia dodatkowych licencji lub dodatkowej liczby licencji innych niż dla telefonów dostawcy systemu, jeśli licencje takie są wymagane, należy doliczyć je w cenie do pełnej pojemności systemu. 2.6. System musi pozwalać na rozszerzenie liczby użytkowników do co najmniej 20 000 jedynie poprzez zakup odpowiednich licencji. Rozbudowa ta nie może w sposób zauważalny dla użytkowników pogorszyć parametrów wydajnościowych systemu. 2.7. System musi być w stanie obsłużyć jednocześnie 20 000 aktywnych połączeń. 2.8. Pojedyncza licencja musi umożliwiać zarejestrowanie minimum 5 urządzeń o tym samym numerze. 2.9. System musi zostać dostarczony w wersji redundantnej składającej się z co najmniej dwóch w pełni funkcjonalnych węzłów, które zostaną zainstalowane w różnych serwerowniach UW. - 3 -

2.10. Podczas wyłączenia jednego z węzłów wszyscy abonenci VoIP będą obsługiwani przez drugi węzeł. Wyłączenie i ponowne włączenie węzła nie może powodować przerw w dostępności usługi VoIP dla użytkowników końcowych. 2.11. W trybie pracy normalnej klastra, węzły muszą działać w trybie aktywny-aktywny, obsługiwany ruch musi być dystrybuowany równo pomiędzy oba serwery, a jednocześnie każdy z serwerów musi służyć jako węzeł backupowy dla drugiego, utrzymując kontekst połączenia przetwarzanego na drugim serwerze w jego kolejnych krokach. 2.12. Klaster serwerów Softswitcha VoIP musi pozwalać na bezprzerwowe upgrady, tzn. kolejne upgrady węzłów bez przerywania pracy całego systemu. 2.13. System musi pozwalać na rozdzielenie redundantnych węzłów za pomocą sieci LAN połączonej w warstwie 2 tj. w tej samej podsieci IP. 2.14. System musi pozwalać na rozdzielenie redundantnych węzłów za pomocą sieci WAN połączonej w warstwie 3 tj. sieci rutowalnej w różnych podsieciach IP. 2.15. System musi pozwalać na realizację scenariusza niezawodnościowego z podwójną rejestracją telefonów SIP - rejestracja w systemie głównym i bramie z funkcją przetrwania w oddziale. 2.16. W przypadku scenariusza z podwójną rejestracją telefony pracujące w trybie awaryjnym i rejestrujące się do lokalnej bramy z funkcją przetrwania powinny cyklicznie sprawdzać dostępność głównego SIP Registrara. W takiej sytuacji system powinien umożliwiać losowy dobór czasu po którym następują takie próby. 2.17. System musi być certyfikowany przez producenta do pracy w środowisku zwirtualizowanym w oparciu o standard Open Virtualization Format (OVF). 2.18. Nie dopuszcza się stosowania przez Wykonawcę wersji testowych (ang. trial) oprogramowania komercyjnego. 2.19. System musi zapewniać nieograniczoną ilość konferencji trójstronnych SIP. 2.20. System musi zapewniać możliwość jednoczesnego prowadzenia co najmniej 20 konferencji wielostronnych (co najmniej 8 uczestników każda). 2.21. System musi wspierać realizację co najmniej 4 wielostronnych wideokonferencji HD (dla co najmniej 6 uczestników każda). 2.22. System musi być w stanie obsłużyć sygnalizację odpowiadającą BHCA 252 000. 2.23. System musi być kompletny, tj. posiadać wszystkie niezbędne elementy sprzętowe i programowe i licencyjne. 2.24. System musi posiadać wbudowaną funkcjonalność firewall pozwalającą na blokowanie ruchu na podstawie parametrów warstw 2, 3, 4 modelu ISO/OSI. - 4 -

2.25. System musi pozwalać na realizowanie połączeń przez użytkowników z zewnątrz sieci IP Zamawiającego bez względu na lokalizację (wsparcie dla przekierowania połączeń NAT przez Internet). 2.26. System musi umożliwiać uruchomienie oddziału z funkcjami autonomii w oparciu o środowisko w pełni wirtualne. Tzn. w oddziale musi znajdować się platforma wirtualizacyjna realizująca usługi: SIP Proxy, zapowiedzi i konferencje (serwer mediów), automatyczne awizo, oraz łącze do miasta typu SIP Trunk. 2.27. System musi dostarczać następujące funkcje dla użytkowników końcowych: 2.27.1. Prezentacja numeru abonenta dzwoniącego (CLIP) oraz blokada prezentacji numeru abonenta dzwoniącego (CLIR). 2.27.2. Interkom jednostronny - system musi realizować funkcję jednokierunkowego połączenia interkomowego. Uprawniony użytkownik aparatu systemowego (Abonent A) może wybrać kod dostępu do funkcji a następnie odbiorcę wyposażonego w aparat systemowy (Abonent B). Powoduje to zestawienie jednostronnego kanału komunikacji głosowej od abonenta A do abonenta B. Po użyciu funkcji głośnik w aparacie odbiorcy zostanie automatycznie włączony, a po rozłączeniu się abonenta A połączenie zostanie zakończone. 2.27.3. Funkcja Interkom jednostronny musi działać zarówno pomiędzy abonentami wewnątrz systemu, jak również pomiędzy abonentem systemu softswitch a abonentem istniejącego systemu Hipath 4000. 2.27.4. Interkom dwukierunkowy - system musi realizować funkcję dwukierunkowego połączenia interkomowego. Uprawniony użytkownik aparatu systemowego (Abonent A) może wybrać kod dostępu do funkcji a następnie odbiorcę wyposażonego w aparat systemowy (Abonent B). Powoduje to zestawienie dwukierunkowego kanału komunikacji głosowej pomiędzy abonentami A i B. Po użyciu funkcji głośniki i mikrofony w obu aparatach zostaną automatycznie włączone. 2.27.5. Funkcja Interkom dwukierunkowy musi działać zarówno pomiędzy abonentami wewnątrz systemu, jak również pomiędzy abonentem systemu softswitch a abonentem istniejącego systemu Hipath 4000. 2.27.6. Prezentacja numeru abonenta, z którym jest zestawione połączenie (COLP) oraz blokada prezentacji numeru abonenta, z którym jest zestawione połączenie (COLR). 2.27.7. Prezentacja nazwy abonenta dzwoniącego (CNIP) oraz blokada nazwy abonenta dzwoniącego (CNIR). 2.27.8. Prezentacja nazwy abonenta, z którym jest zestawione połączenie (CNIP) oraz blokada prezentacji nazwy abonenta (CNIR), z którym jest zestawione połączenie. 2.27.9. Wizualna sygnalizacja rozmowy przychodzącej dla aparatów systemowych. - 5 -

2.27.10. Przekierowanie wszystkich połączeń (natychmiastowe CFU). 2.27.11. Przekierowanie przy zajętości (CFB). 2.27.12. Przekierowanie w przypadku nie odbierania (CFNR). 2.27.13. Przekierowanie w przypadku braku rejestracji. 2.27.14. Przekierowanie zależne od czasu wszystkich połączeń (natychmiastowe CFU np. tylko w godzinach pracy). 2.27.15. Przekierowanie zależne od czasu przy zajętości (CFB np. tylko w godzinach pracy). 2.27.16. Przekierowanie zależne od czasu w przypadku nie odbierania (CFNR np. tylko w godzinach pracy). 2.27.17. Możliwość zdalnego aktywowania przekierowania za pomocą aparatu (RCF) z podaniem kodu PIN. Przekierowanie może być zdefiniowane na numer wewnętrzny, zewnętrzny lub zbiorowy numer grupy poszukiwania. 2.27.18. Przekazywanie połączeń bez konsultacji. 2.27.19. Przekazywanie połączeń z konsultacją. 2.27.20. Szybkie wybieranie (speed dialing). 2.27.21. Restrykcje dostępu do sieci minimum dla połączeń wewnętrznych, lokalnych, krajowych, międzynarodowych. 2.27.22. Możliwość zastosowania wymogu podania kodu PIN dla połączeń wychodzących. 2.27.23. Możliwość rozliczania rozmów dla danego projektu/konta oraz rozliczania kosztów poprzez podanie odpowiedniego kodu PIN. 2.27.24. Bezpośrednie wybieranie numerów wewnętrznych. 2.27.25. Zestawianie połączeń w oparciu o zdefiniowany plan numeracji. 2.27.26. Przekierowanie wszystkich połączeń oparte na serwerze (protokół CSTA). 2.27.27. Przekierowanie połączeń nie odbieranych oparte na serwerze (protokół CSTA). 2.27.28. Przekierowanie połączeń przy zajętości oparte na serwerze (protokół CSTA). 2.27.29. Funkcjonalność nie przeszkadzać DND w oparciu o serwer z możliwością konfiguracji zachowania dla abonenta A: zastosowania przekierowania warunkowego lub odrzucenia połączenia z komunikatem o niedostępności. 2.27.30. Obsługa połączeń oczekujących w sytuacji pracy normalnej i dla oddziałów wyposażonych w funkcje przetrwania również w czasie awarii WAN. - 6 -

2.27.31. Obsługa klawiszy szybkiego wybierania numerów. 2.27.32. Transferowanie połączeń. 2.27.33. Callback oddzwonienie. 2.27.34. Automatyczne wybieranie najlepszej drogi (z uwzględnieniem wag łączy). 2.27.35. Narzędzia dynamicznego uaktualniania oprogramowania systemowego telefonów. 2.27.36. Możliwość generowania raportów połączeń (Call Detail Reports) z aplikacji taryfikacyjnej. 2.27.37. Funkcjonalność sekretarsko-dyrektorska. 2.27.38. Realizacja usługi wideotelefonii z wykorzystaniem kamery i aplikacji instalowanej na stacji roboczej lub dedykowanego zestawu wideokonferencyjnego. 2.27.39. Współpraca z aparatami telefonicznymi wspierającymi certyfikaty x509v3. 2.27.40. Zabezpieczenie protokołów sygnalizacyjnych protokołem IPsec lub TLS. 2.27.41. Zestawianie połączeń szyfrowanych na trasie od telefonu IP do telefonu IP protokołem SRTP. 2.27.42. Mechanizm Call Admission Control, uwzględniający minimum połączenia głosowe, faksowe i wideo. 2.27.43. Profil Użytkownika zdefiniowany w systemie telefonii (związany z numerem wewnętrznym i uprawnieniami do wykonywania połączeń międzymiastowych, międzynarodowych) oraz logowanie się do aparatu telefonicznego przy użyciu zdefiniowanego profilu w celu pobrania na dany telefon własnego numeru, spersonalizowanych funkcji i opisów klawiszy, list połączeń, członkostwa w numerach zbiorowych, oraz przeniesienia uprawnień. 2.27.44. Musi posiadać kompatybilne rozwiązanie poczty głosowej, możliwe do zintegrowania z systemami poczty elektronicznej, zarządzane przez przeglądarkę WWW. 2.27.45. Musi posiadać funkcjonalność generowania raportów bilingowych (poprzez wykorzystanie rozwiązania firmy trzeciej). 2.27.46. Zapewni współpracę z bramami głosowymi. 2.27.47. Zapewni współpracę z SIP Proxy Server. 2.27.48. Zapewni współpracę z urządzeniami klienckimi (telefony IP, oprogramowanie dla stacji roboczych) z wykorzystaniem protokołu SIP. 2.27.49. Połączenia oczekujące. 2.27.50. Wstrzymanie połączenia Hold. 2.27.51. Przejęcie połączenia. - 7 -

2.27.52. Obsługa linii wirtualnych. 2.27.53. Dynamiczne licencje użytkowników. 2.27.54. Dzwonienie seryjne. Możliwość włączenia, wyłączenia funkcji, odsłuchania bądź edycji listy urządzeń (min 6) na które ma zostać wysłany kolejno sygnał dzwonienia przy połączeniu przychodzącym. Obsługa za pomocą telefonu użytkownika. 2.27.55. Dzwonienie równoległe. Możliwość włączenia, wyłączenia funkcji, odsłuchania bądź edycji listy urządzeń (min 6) na które ma zostać wysłany jednoczesny sygnał dzwonienia przy połączeniu przychodzącym. Obsługa za pomocą telefonu użytkownika. 2.27.56. Dzwonienie równoległe zdalna aktywacja. Możliwość włączenia funkcji z lokalizacji innej niż własny telefon po podaniu kodu PIN. 2.27.57. Interfejs One Number Service CSTA. Możliwość zarządzania wybieraniem i funkcjami abonenta za pomocą aplikacji komputerowej z interfejsem CSTA w taki sposób aby niezależnie od tego na jakim fizycznym urządzeniu wykonywana lub odbierana jest rozmowa abonent B widział stały numer abonenta A zdefiniowany w usłudze ONS. 2.27.58. Prywatna lista szybkiego wybierania definiowana przez użytkownika. Możliwość zdefiniowania listy do 25 numerów. 2.27.59. Prywatna lista szybkiego wybierania współdzielenie. Możliwość zdefiniowania listy jako współdzielonej z innymi użytkownikami systemu. 2.27.60. Systemowa lista szybkiego wybierania definiowana przez administratora. Możliwość zdefiniowania 10 list do 1000 numerów i przypisania min 2 list każdemu użytkownikowi. 2.27.61. Secure Shell w wersji 2 dla Interfejsu Zarządzania. 2.27.62. Wsparcie dla Native SIP Trunking. 2.27.63. Grupy Pick-Up. 2.27.64. Obsługa wieloliniowości. System musi pozwalać na kreowanie zestawów wieloliniowych tak by pojedyncza rozmowa była sygnalizowana u wielu abonentów. Rozmowa musi być sygnalizowana na stanowisku optycznie i akustycznie. 2.27.65. Obsługa wieloliniowości. System musi pozwalać na przypisanie linii jako pierwotnej do danego stanowiska, dodatkowej (pierwotnej na innym stanowisku), lub wirtualnej nie będącej pierwotnie przypisanej do żadnego stanowiska. Zależnie od trybu sygnalizacja akustyczna (dzwonienie) może być włączona, opóźniona lub wyłączona. 2.27.66. Obsługa wieloliniowości. Dodatkowo system musi pozwalać na przypisanie linii jako pierwotnej, lub dodatkowej jako prywatnej (przypisanej wyłącznie do jednego stanowiska). 2.27.67. System musi pozwalać na równoległe wykorzystanie wieloliniowej grupy wyszukiwania - 8 -

(multiline hunt grup) oraz usługi One number Service sterowanej przez CSTA. Softswitch musi przekazywać do serwera UC informacje pozwalające na rozróżnienie pomiędzy rozmowami automatycznie dystrybuowanymi w grupie i rozmowami nie skierowanymi do grupy. 2.28. Zarządzanie systemem musi być realizowane co najmniej za pomocą interfejsu www oraz w postaci interfejsu SOA/WebService. Wykonawca dostarczy dokumentację interfejsu i niezbędne licencje. 2.29. System musi posiadać możliwość grupowej i zdalnej konfiguracji terminali VoIP. 2.30. System musi posiadać możliwość zdalnej aktualizacji oprogramowania terminali VoIP. 2.31. System musi posiadać możliwość tworzenia kopii zapasowej konfiguracji terminali VoIP. 2.32. System musi posiadać możliwość rejestracji użytkownika na gościnnym terminalu przyłączonym do systemu z przeniesieniem wszystkich ustawień z terminala podstawowego (między innymi konfiguracja przycisków funkcyjnych oraz książki telefonicznej). 2.33. System musi posiadać funkcje backup systemu. 2.34. System musi pozwalać na wykorzystanie kodu uwierzytelnienia pozwalającego na rozróżnienie rozmów prywatnych i służbowych dla danego użytkownika w danej grupie biznesowej. 2.35. System musi dostarczać funkcjonalność powiadamiania alarmowego o następujących parametrach: 2.35.1. Możliwość powiadamiania wszystkich użytkowników centrali (możliwość powiadamiania do 20 000 użytkowników) 2.35.2. Liczba jednocześnie odtwarzanych komunikatów nie mniejsza niż 4 (system powiadamiania alarmowego musi posiadać co najmniej 4 równoległe kanały głosowe). 2.35.3. System alarmowo-rozgłoszeniowy musi umożliwiać dystrybucję wcześniej przygotowanych informacji słownych poprzez automatyczne wykonywanie połączeń na zdefiniowane numery telefonów, z kontrolą faktu odebrania połączenia. Musi istnieć możliwość zainicjowania rozgłoszenia przez użytkownika systemu z poziomu aparatu telefonicznego. 2.35.4. Dystrybucji informacji słownej musi towarzyszyć dedykowana informacja na wyświetlacz aparatu systemowego stacjonarnego (VoIP). 2.35.5. Aktywacja dystrybucji informacji słownej poprzez aparat telefoniczny VoIP, bramy multimedialne. 2.35.6. Aktywacja dystrybucji informacji słownej poprzez dedykowaną aplikację operatora, dedykowane styki wejściowe, automatycznie według harmonogramu terminarza. 2.35.7. System alarmowo-rozgłoszeniowy musi być wyposażony w integralne styki wejściowe na potrzeby dołączania zewnętrznych czujników. - 9 -

2.36. System musi dostarczać funkcjonalność rejestracji rozmów dla stanowisk awizo 2.36.1. Rejestracja treści rozmów telefonicznych musi odbywać się w postaci zapisu cyfrowego. 2.36.2. System musi umożliwiać zapisanie minimum 5000h nagrania. 2.36.3. Rejestrator musi archiwizować nagrania na zewnętrznym nośniku danych (płyta DVD, dysk twardy) oraz na udostępnionym zasobie sieciowym. Wymaga się archiwizacji w trybie automatycznym i manualnym. 2.36.4. Rejestrator rozmów musi natychmiast raportować o błędach lub awariach urządzeń wchodzących w skład rejestratora. 2.36.5. Rejestrator rozmów musi opatrywać nagrania głosowe dodatkowymi informacjami tj.: 2.36.5.1. numer abonenta dzwoniącego (w ruchu przychodzącym), 2.36.5.2. numer wewnętrzny, 2.36.5.3. numer wybrany, 2.36.5.4. data i godzina połączenia, 2.36.5.5. czas trwania połączenia, 2.36.5.6. kierunek rozmowy, 2.36.6. Rejestrator rozmów musi umożliwić wyszukiwanie nagrań co najmniej według następujących kryteriów: 2.36.6.1. data i czas nagrania, 2.36.6.2. numer dzwoniący, 2.36.6.3. numer wewnętrzny, 2.36.6.4. kierunek połączenia. 2.36.7. Zarządzanie i administracja rejestratora oraz odsłuch nagrań musi się odbywać poprzez sieć IP. 2.36.8. Rejestrator musi być wyposażony w funkcję eksportu nagrań do pliku (np. pliku wav). Format pliku wyeksportowanego nagrania musi umożliwiać jego odsłuch z zastosowaniem dostępnego oprogramowania np. Windows Media Player bez konieczności komunikacji z rejestratorem, który daną rozmowę nagrał. 2.37. System musi pozwalać na generowanie trapów SNMP w przypadku wykonywania rozmów na numery alarmowe. Wygenerowany w takim przypadku event SNMP musi zawierać co najmniej: wybrany numer, identyfikację numeru dzwoniącego, ELIN/LIN, oznaczenie czasu. - 10 -

2.38. Wykonawca zobowiązany jest do dostarczenia plików z opisem MIB. 3. MODUŁY DO POSIADANYCH PRZEZ ZAMAWIAJĄCEGO CENTRAL TDM 3.1. Wykonawca dostarczy moduły, które zostaną zainstalowane w węzłach sieci telefonicznej UW i zostaną połączone do posiadanych przez UW central Siemens HiPath4000 v3. 3.2. Każdy z modułów musi pozwalać na co najmniej 90 jednoczesnych połączeń telefonicznych pomiędzy centralą SoftSwitch a posiadaną przez UW centralą TDM. 3.3. Brama musi posiadać co najmniej jeden port Ethernet/IP: 10/100BASE-T lub 10/100/1000BASE-T. 3.4. Wykonawca zobowiązany jest do niezbędnej rekonfiguracji posiadanych przez UW central Siemens HiPath4000 v3 na potrzeby połączenia central Softswitch z istniejącą infrastruktura TDM UW. 3.5. Moduły muszą zapewniać przenoszenie następujących usług pomiędzy centralą Softswitch a centralami TDM UW: 3.5.1. Prezentacja numeru abonenta dzwoniącego - CLIP oraz blokada prezentacji numeru abonenta dzwoniącego- CLIR (Calling Line Identification Presentation/Restriction). 3.5.2. Prezentacja numeru abonenta, z którym jest zestawione połączenie - COLP oraz blokada numeru abonenta, z którym jest zestawione połączenie - COLR (Connected Line Identification Presentation/ Restriction). 3.5.3. Prezentacja nazwy abonenta dzwoniącego - CNIP oraz blokada nazwy abonenta dzwoniącego - CNIR (Calling Name Identification Presentation/Restriction). 3.5.4. Prezentacja nazwy abonenta, z którym jest zestawione połączenie - CNOP oraz blokada nazwy abonenta, z którym jest zestawione połączenie - CNOR (Connected Name Identification Presentation/Restriction). 3.5.5. Przekierowanie wszystkich połączeń CFU (Call Forward Unconditional). 3.5.6. Przekierowanie przy zajętości CFB (Call Forward on Busy). 3.5.7. Przekierowanie w przypadku nie odbierania - CFNR (Call Forward on No Reply). 3.5.8. Przekazywanie połączeń ślepe (Blind Transfer). 3.5.9. Przekazywanie połączeń bez konsultacji (Semi-attended Transfer). 3.5.10. Przekazywanie połączeń z konsultacją (Attended Transfer). 3.5.11. Oddzwonienie przy zajętości CCBS (Call Completion on Busy Subscriber). 3.5.12. Grupa Pick up. 4. SYSTEM BILINGOWY - 11 -

4.1. System musi skalować się do obsługi co najmniej 20000 numerów jedynie poprzez zakup odpowiedniej licencji. 4.2. Rozbudowa o kolejne licencje ( do co najmniej 20000 numerów ) nie może w sposób zauważalny dla użytkowników pogorszyć parametrów wydajnościowych systemu. 4.3. Oprogramowanie systemu musi być wykonane w oparciu o centralną, relacyjną, komercyjną bazę danych SQL. Zamawiający jest w stanie udostępnić bazę danych o pojemności do 5GB. 4.4. Możliwość importu rekordów taryfikacyjnych według zadanego harmonogramu, aplikacja do pobierania danych powinna mieć możliwość pracy, jako usługa systemowa. 4.5. Funkcja ręcznego importu rekordów taryfikacyjnych (na żądanie). 4.6. System powinien posiadać architekturę, która pozwala na elastyczne jego dostosowanie do potrzeb Zamawiającego uwzględniające wewnętrzne zmiany organizacyjne, zmiany kadrowe, zmiany operatorów telekomunikacyjnych, itp. Wszystkie konieczne zmiany w systemie, wynikające z powyższego powinny być możliwe do wykonania samodzielnie przez operatora lub administratora systemu bez angażowania Wykonawcy. Procedura takich zmian musi zostać opisana w dokumentacji systemu. 4.7. Dostęp operatora systemu powinien odbywać się poprzez wbudowany system autoryzacji, umożliwiający definiowanie różnych poziomów uprawnień dla użytkowników systemu. 4.8. Pobieranie danych taryfikacyjnych z systemu SoftSwitch winno odbywać się w trybie automatycznym wg ustalonego scenariusza lub ręcznie wg potrzeb przy wykorzystaniu dostępnych interfejsów, a następnie wykonywane jest przetwarzanie rekordów do jednolitego formatu i gromadzenie w centralnej bazie danych. 4.9. Prezentacja aktualnej informacji o stanie pobierania i przetwarzania rekordów. 4.10. Automatyczne informowanie o pojawieniu się rekordów taryfikacyjnych generowanych przez nowych abonentów, linie zewnętrzne i kody PIN w momencie pierwszego pojawienia się ich w systemie. 4.11. Polskojęzyczny interfejs operatora. Wszystkie moduły oprogramowania muszą mieć interfejs użytkownika w języku polskim z poprawną wizualizacją, edycją, sortowaniem i drukowaniem wyrazów z polskimi znakami narodowymi. 4.12. Zapewnienie możliwości rekalkulacji kosztów połączeń po zmianie cenników usług telekomunikacyjnych. Rekalkulacja musi uwzględniać historię przypisania abonentów do struktury organizacyjnej oraz historię zmian w tej strukturze. 4.13. Umożliwienie dokonywania zmian w strukturze organizacyjnej i zmian w przyporządkowaniu numerów wewnętrznych i kodów PIN z zachowaniem poprzednio przypisanych danych bez konieczności archiwizacji. 4.14. Pobieranie danych o abonentach z systemu LDAP, LDAPS, AD i ich synchronizacja ze strukturą - 12 -

użytkowników w systemie taryfikacyjnym dane, co najmniej o imieniu i nazwisku, linii wewnętrznej i miejscu osoby w strukturze organizacyjnej klienta. 4.15. Zachowanie historii połączeń dla nieaktywnego numeru wewnętrznego. 4.16. Umożliwienie przeprowadzania obliczeń symulacyjnych na rzeczywistych rekordach poprzez definiowanie różnych taryf w celu porównania ofert operatorów. 4.17. Wyeliminowanie możliwości dublowania się połączeń (kosztów połączeń) rejestrowanych jednocześnie w różnych węzłach sieci. 4.18. Narzędzia do zaawansowanego filtrowania sortowania, wyszukiwania rekordów taryfikacyjnych wg dowolnie zadanych kryteriów (dowolny zakres czasowy, dowolny zakres numerów wewnętrznych, dowolnej grupy operatorów). Prezentacja rekordów w postaci tabelarycznej z możliwością edycji wyglądu pól (kolejności, szerokości, pokazywania lub ukrywania ich na liście) oraz ich zapis, wydruk i eksport do formatów: TXT, XLS, HTML, PDF. 4.19. System musi umożliwiać definiowanie automatycznie generowanych raportów rozsyłanych za pomocą poczty elektronicznej. 4.20. System musi umożliwiać dostęp do danych taryfikacyjnych przez interfejs WWW dla każdego użytkownika w tym samym czasie. 4.21. Administrator musi mieć możliwość przydzielania uprawnień dla dostępu do danych dla poszczególnych użytkowników lub grup użytkowników interfejsu WWW. 4.22. Konta użytkowników interfejsu WWW powinna być zintegrowana z logowaniem SSO logowanie domenowe. 4.23. Raportowanie w interfejsie WWW z możliwością wykreowania dowolnej formy zestawienia danych, wykonania statystyk ruchu i wykresów z użyciem kreatora raportów. 4.24. System powinien posiadać funkcje umożliwiające ciągły nadzór i monitorowanie kompletności pobranych danych do jednorodnej bazy danych z rozbiciem na poszczególne systemy. 4.25. System powinien umożliwiać przeglądanie logów systemowych oraz monitorować zagrożenia procesu zbierania danych taryfikacyjnych. 4.26. Możliwość wprowadzenia numeru w systemie taryfikacji, jeżeli nie ma przyznanego abonamentu i nie były realizowane rozmowy z tego numeru. 4.27. Możliwość prezentacji raportu w formie graficznej, np. wykresu. 4.28. Logowanie do systemu w oparciu o Active Directory. 4.29. Wymagana jest zdolność do taryfikacji połączeń przychodzących, wychodzących, wewnętrznych, transferowych. - 13 -

4.30. Wymagany jest mechanizm kontroli kosztów z podziałem na osoby, grupy osób i typy połączeń, możliwość tworzenia raportów na LW zdefiniowanych jednocześnie w więcej niż jednej strukturze organizacyjnej. 4.31. Archiwizacja i zabezpieczenie danych na nośnikach zewnętrznych (zapis na CD, DVD itp.). 4.32. Łącze między centralą softswitch a systemem taryfikacji musi być realizowane za pomocą połączenia IP. 4.33. Dostęp do systemu musi być realizowany przez interfejs WWW oraz w trybie graficznym za pomocą dedykowanej aplikacji instalowanej na komputerze. 4.34. Możliwość ręcznego lub automatycznego importu danych o taryfikowanych obiektach (np. linie wewnętrzne, użytkownicy) z pliku zewnętrznego, kompatybilnego z aplikacją Microsoft Excel. 4.35. Oprogramowanie musi być gotowe do udostępnienia funkcjonalności blokowania linii wewnętrznej po przekroczenia określonego limitu kwotowego za połączenia. 4.36. System bilingowy musi współpracować z istniejącym systemem HiPath 4000 firmy Siemens (wymaga się, aby przyłączanie kolejnych central odbywała się jedynie poprzez zakup dodatkowych licencji). 4.37. System musi być kompletny, tj. posiadać wszystkie niezbędne elementy sprzętowe i programowe i licencyjne. 5. SYSTEM POCZTY GŁOSOWEJ 5.1. System poczty głosowej musi pochodzić od tego samego producenta, co system Softswitch. Dopuszcza się zastosowanie rozwiązania równoważnego certyfikowanego przez producenta systemu Softswitch. 5.2. System musi pozwalać na rozbudowę do co najmniej 20 000 skrzynek głosowych jedynie poprzez zakup dodatkowych licencji. Rozbudowa ta nie może w sposób zauważalny dla użytkowników pogorszyć parametrów wydajnościowych systemu. 5.3. Każda ze skrzynek poczty głosowej musi pozwalać na przechowywanie co najmniej 10 wiadomości o długości 3 minuty każda. 5.4. System poczty głosowej musi integrować się z dowolnym systemem e-mailowym, (przesyłanie zapisanych wiadomości przez email). 5.5. Konieczna jest możliwość odbioru wiadomości głosowej za pomocą przeglądarki internetowej. 5.6. System poczty głosowej musi informować o pojawieniu się w skrzynce nowej wiadomości głosowej za pomocą dedykowanej diody LED aparatu telefonicznego oraz za pomocą wiadomości e-mail. 5.7. Zarządzanie systemem musi być realizowane co najmniej za pomocą interfejsu www. 5.8. System musi być kompletny, tj. posiadać wszystkie niezbędne elementy sprzętowe, programowe i - 14 -

licencyjne. 6. SYSTEM OBSŁUGI FAX'ÓW 6.1. System faks serwerowy musi pochodzić od tego samego producenta, co istniejący system Softswitch. Dopuszcza się zastosowanie rozwiązania równoważnego certyfikowanego przez producenta systemu Softswitch. 6.2. System musi pozwalać na rozbudowę do co najmniej 3000 skrzynek faksowych jedynie poprzez zakup dodatkowych licencji. Rozbudowa ta nie może w sposób zauważalny dla użytkowników pogorszyć parametrów wydajnościowych systemu. 6.3. Wymagana obsługa protokołu T.38. 6.4. System musi integrować się z dowolnym systemem e-mailowym. 6.5. Konieczna jest możliwość wysyłania faksów za pomocą przeglądarki internetowej. 6.6. Faks Serwer musi integrować się z oprogramowaniem Microsoft Office w wersjach XP, 2003, 2007, 2010 a w szczególności z Microsoft Word (m.in. wysyłanie faksów z poziomu dokumentu programu za pomocą dedykowanej wtyczki programowej). 6.7. Serwer musi informować o pojawieniu się w skrzynce nowej wiadomości fax za pomocą wiadomości e-mail. 6.8. Serwer musi oferować możliwość archiwizacji faksów przychodzących i wychodzących. 6.9. Konieczna jest obsługa przekazywania faksów za pomocą telefonu systemowego na skrzynkę innego użytkownika systemu. 6.10. Zarządzanie systemem musi być realizowane co najmniej za pomocą interfejsu www. 6.11. Faks Serwer musi być kompletny, tj. posiadać wszystkie niezbędne elementy sprzętowe, programowe i licencyjne. 7. TERMINALE KOŃCOWE 7.1. Telefon VoIP 7.1.1. Wyświetlacz o rozdzielczości minimum 240 x 128 pikseli co najmniej 6 linii. 7.1.2. Obsługa protokołu SIP (RFC 3261). 7.1.3. Optyczna sygnalizacja połączenia. 7.1.4. Minimum 8 stałych klawiszy funkcyjnych z diodami LED. 7.1.5. Minimum 6 programowalnych klawiszy funkcyjnych z diodami LED. 7.1.6. Minimum 5 klawiszy nawigacyjnych. - 15 -

7.1.7. Rozmowy za pomocą zestawu głośnomówiącego (full duplex). 7.1.8. Gniazdo słuchawek nagłownych. 7.1.9. Możliwość montażu na ścianie. 7.1.10. Możliwość podłączenia minimum dwóch dodatkowych modułów klawiszy. 7.1.11. Mikroswitch Ethernet 10/100/1000 Base-T. 7.1.12. Wsparcie dla kodeków audio: G.729AB, G.722, G711. 7.1.13. Wsparcie dla 802.1Q, 802.1p, DiffServ. 7.1.14. Wsparcie LLDP-MED. 7.1.15. Zewnętrzne źródło zasilania lub 802.3 af Zasilanie za pomocą sieci LAN. 7.1.16. Dostęp do katalogowej skrzynki kontaktów (Klient LDAP). 7.1.17. Szybkie wyszukiwanie i zaawansowane wyszukiwanie z różnymi kryteriami wyszukiwania. 7.1.18. Z aparatem musi zostać dostarczony zasilacz pozwalający na zasilanie z sieci elektrycznej 230V. 7.2. Zestawy terminali sekretarsko-dyrektorskich 7.2.1. Zestaw składa się z dwóch telefonów VoIP o funkcjonalności co najmniej takiej jak telefon VoIP 7.1. 7.2.2. Terminal sekretarski powinien posiadać co najmniej 15 programowalnych klawiszy funkcyjnych z diodami LED. 7.2.3. Sekretarz musi mieć możliwość kontroli i administracji połączeń przychodzących do Dyrektorów. 7.2.4. Sekretarz musi mieć możliwość odbierania wszystkich połączeń przychodzących skierowanych do Dyrektora, i możliwości dalszego sterowania tymi połączeniami. 7.2.5. Połączenia przychodzące do Dyrektora są bezpośrednio przekierowane na telefon Sekretarza. 7.2.6. Sekretarz musi mieć możliwość monitorowania wszystkich połączeń przychodzących do Dyrektora (połączenia bezpośrednio przekierowane na telefon Sekretarza). 7.2.7. Sekretarz musi mieć możliwość monitorowania wszystkich połączeń przychodzących do Dyrektora za pośrednictwem klawiszy linii i móc odpowiednio zareagować. 7.2.8. Wymagana jest co najmniej następująca możliwość konfiguracji: 7.2.8.1. 1x Dyrektor i 1x Sekretarz - 16 -

7.2.8.2. 2x Dyrektor i 1x Sekretarz 7.2.8.3. 2x Dyrektor i 2x Sekretarz: 7.2.8.4. bezpośrednie powiązanie Dyrektor 1- Sekretarz 1 oraz Dyrektor 2 - Sekretarz 2; 7.2.8.5. jeśli jeden z Sekretarzy nie jest obecny, drugi Sekretarz może działać w jego zastępstwie. 7.2.8.6. 4x Dyrektor i 2x Sekretarz: 7.2.8.7. bezpośrednie powiązanie Dyrektorzy 1+2 do Sekretarz 1 i Dyrektorzy 3+4 do Sekretarz 2; 7.2.8.8. jeśli jeden z Sekretarzy nie jest obecny, drugi Sekretarz może działać w jego zastępstwie. 7.2.9. Co najmniej 5 opcji przekierowania połączeń. 7.2.10. Informacja o Oczekującej Wiadomości (sekretarze są informowani w przypadku, gdy Dyrektor odbierze komunikat poczty głosowej). 7.2.11. Powiadomienie o zajętości linii. 7.2.12. Połączenia przychodzące muszą mieć możliwość przekierowania na zdefiniowany numer wewnętrzny zastępcy. 7.3. Wideotelefon 7.3.1. Co najmniej 7 wyświetlacz dotykowy o proporcjach 16:9. 7.3.2. Obsługa protokołu SIP (RFC 3261). 7.3.3. Obsługa polskich znaków. 7.3.4. Wirtualna klawiatura. 7.3.5. Obsługiwane kodeki: G.711 (A-law and μ-law), G.719, G.729AB, G.722, G.722.1, G.722.1C. 7.3.6. Gniazdo słuchawek nagłownych. 7.3.7. Zewnętrzne źródło zasilania lub 802.3 af Zasilanie za pomocą sieci LAN. 7.3.8. Kamera co najmniej 2 megapixele. 7.3.9. Obsługa wideo : H.261, H.263, H.263+ (1998), and H.264, rozdzielczość CIF(352x288) i SIF(352x240) co najmniej do 30 fps. 7.3.10. Wsparcie dla 802.1Q, 802.1p, DiffServ. 7.3.11. Wsparcie dla LLDP-MED. - 17 -

7.3.12. Dostęp do katalogowej skrzynki kontaktów (Klient LDAP). 7.3.13. Z aparatem musi zostać dostarczony zasilacz pozwalający na zasilanie z sieci elektrycznej 230V. 7.4. Stanowisko operatorskie awizo 7.4.1. Stanowisko operatorskie telefonistki (AWIZO) ma być zbudowane na komputerze klasy PC wyposażonym w monitor dotykowy 17 o proporcjach obrazu 4:3. 7.4.2. Usprawniony system informacji o połączeniach przychodzących za pomocą szczegółowego wyświetlania danych połączeń, statusu użytkownika i telefonu, kolejek, dostępności. 7.4.3. Skuteczne wyszukiwanie w książce telefonicznej z użyciem funkcji wyszukiwania takich jak słowa kluczowe, działy, lokalizacje, hierarchie. 7.4.4. Analiza statystyczna ilości połączeń i dostępności, jako podstawa efektywnej alokacji personelu. 7.4.5. Łatwy dostęp do informacji specyficznych dla Klienta (np.: za pośrednictwem sieci Intranet). 7.4.6. Przyciski Bezpośredniego Wybierania i Szybkiego Wybierania. 7.4.7. Bulletin Board. 7.4.8. Funkcje telefoniczne. 7.4.9. Wyświetlanie statusu i Kolejki. 7.4.10. Wyświetlanie statusu telefonu oraz możliwości zmiany statusu. 7.4.11. Listy Wybierania/ Kolejki połączeń. 7.4.12. Kolejki parkowania. 7.4.13. Dodawanie połączeń. 7.4.14. Funkcja alarmu dla połączeń niepożądanych. 7.4.15. Obsługa urządzenia możliwa przez osoby niewidome. 7.4.16. Wielowątkowość. 7.4.17. Obsługa jednej grupy biznesowej. 7.4.18. Funkcje importu danych kontaktowych (za pośrednictwem LDAP lub z pliku CSV). 7.4.19. Stanowisko Awizo musi być wyposażone w system rejestracji rozmów. 8. INTEGRACJA KOMPONENTÓW I INFRASTRUKTURY 8.1. Wykonawca musi zapewnić integrację wdrażanego Systemu z posiadaną przez Uniwersytet - 18 -

Warszawski infrastrukturą telefoniczną TDM opartą o centrale Siemens HiPath4000 v.3. 8.2. Wykonawca zapewni rekonfigurację posiadanych przez UW central TDM oraz konfigurację dostarczonych central SoftSwitch tak aby łączność dla klientów centrali SoftSwitch z siecią PSTN realizowana była za pośrednictwem dostarczonych i zainstalowanych kart specyfikowanych w Rozdziale 3. 8.3. Konfiguracja połączenia z siecią PSTN musi zapewnić niezawodność działania połączenia dla klientów SoftSwitch w przypadku awarii centrali TDM. 8.4. Konfiguracja połączeń między klientami centrali SoftSwitch a central TDM powinna być zoptymalizowana połączenie powinno angażować możliwie jak najmniej central. 8.5. Połączenie węzła głównego z bramami/modułami wyniesionymi będzie zrealizowane za pomocą łączy IP, wykorzystując do tego celu łącza dostarczone przez Uniwersytet Warszawski. 8.6. Wykonawca zapewni integrację systemów bilingowego (Rozdział 4), systemu poczty głosowej (Rozdział 5), systemu faks (Rozdział 6) z centralą SoftSwitch (Rozdział 1) w pełnym zakresie specyfikowanej funkcjonalności. 8.7. Wykonawca przeprowadzi wstępną konfigurację wszystkich terminali końcowych (Rozdział 7) i przeprowadzi przyłączenie ich do centrali SoftSwitch. 9. SZKOLENIA 9.1. Dostawca zapewni dla personelu Zamawiającego co najmniej następujące szkolenia: 9.1.1. w zakresie obsługi wdrażanego systemu co najmniej 32 godziny 4 uczestników 9.1.2. w zakresie posługiwania się narzędziem administracyjnym/taryfikacyjnym co najmniej 24 godziny 2 uczestników 9.1.3. Szkolenia muszą być przeprowadzone w j. polskim w certyfikowanym ośrodku szkoleniowym producenta oferowanego rozwiązania. Cena oferowanych szkoleń musi obejmować pełne koszty ich przeprowadzenia, w szczególności koszty materiałów szkoleniowych, podróży, zakwaterowania, wyżywienia uczestników. 9.1.4. Harmonogram i szczegółowy zakres szkoleń zostanie uzgodniony pomiędzy Zamawiającym a Wykonawcą na etapie wdrażania systemu. 9.2. Dostawca zapewni przeprowadzenie egzaminu z zakresu szkoleń dla ich uczestników. 10. OPIEKA SERWISOWA 10.1. 12 miesięczna opieka serwisowa świadczona przez Wykonawcę 10.2. Opieka serwisowa obejmuje: 10.2.1. Konsultacje techniczne dotyczące działania Systemu. - 19 -

10.2.2. Dostęp do aktualizacji oprogramowania w zakresie łat bezpieczeństwa. 10.2.3. Gwarancja usunięcia awarii Systemu. 10.3. Możliwość zgłaszania awarii systemu całodobowo telefonicznie oraz za pośrednictwem poczty e-mail. 10.4. Gwarantowany czas usunięcia awarii na poziomie 24h w dni robocze i 48h w dni wolne i święta od chwili zgłoszenia. 10.5. Gwarantowany czas usunięcia awarii poważnych (zatrzymanie systemu) na poziomie 12h w dni robocze i 24h w dni wolne i święta od chwili zgłoszenia. 10.6. Konsultacje telefoniczne oraz za pośrednictwem poczty e-mail dostępne w dni robocze w godzinach 8:00-16:00. 11. ZESTAWIENIE ILOŚCIOWE ELEMENTÓW SYSTEMU 11.1. Część A) zakup i wdrożenie Centrali VoIP; 11.1.1. Centrala telefoniczna typu SoftSwitch SIP sztuk 1 11.1.2. Moduły do posiadanych przez zamawiającego central TDM sztuk 4 11.1.3. System bilingowy sztuk 1 11.1.4. System poczty głosowej sztuk 1 11.1.5. System obsługi faksów sztuk 1 11.1.6. Integracja komponentów i infrastruktury sztuk 1 11.1.7. Szkolenia sztuk 1 11.1.8. Roczna opieka serwisowa sztuk 1 11.2. Część B) zakup licencji i telefonów na potrzeby użytkowników budynku Centrum Nauk Biologiczno- Chemicznych Uniwersytetu Warszawskiego - Kampus Ochota (CENT III) 11.2.1. Licencja użytkownika (numer telefonu) dla centrali telefonicznej typu SoftSwitch SIP sztuk 200 11.2.2. Licencja użytkownika (numer telefonu) dla systemu bilingowego sztuk 200 11.2.3. Licencja użytkownika (numer telefonu) dla systemu poczty głosowej sztuk 10 11.2.4. Licencja użytkownika (numer telefonu) dla systemu obsługi faksów sztuk 10 11.2.5. Licencja użytkownika mobilnego (numer telefonu) pozwalająca na pracę z zewnątrz sieci IP Zamawiającego sztuk 10 11.2.6. Terminal końcowy telefon VoIP sztuk 30 11.2.7. Terminal końcowy zestaw sekretarsko-dyrektorski sztuk 10-20 -