SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

Projekt „Budowa budynku dydaktycznego dla potrzeb Wydziału Lingwistyki Stosowanej oraz Wydziału Neofilologii Uniwersytetu
Warszawskiego w rejonie ulic Lipowej - Dobrej - Wiślanej - Browarnej w Warszawie - Etap I” współfinansowany przez Unię Europejską
ze środków Europejskiego Funduszu Rozwoju Regionalnego w ramach Regionalnego Programu Operacyjnego Województwa
Mazowieckiego 2007 – 2013
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
e)
Dostawa, uruchomienie i wdrożenie systemu faksowego o funkcjonalnościach i na warunkach
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
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-
Projekt pn. Centrum Nauk Biologiczno-Chemicznych Uniwersytetu Warszawskiego - Kampus Ochota (CENT III) współfinansowany przez Unię Europejską z Europejskiego Funduszu Rozwoju Regionalnego w ramach Programu
Operacyjnego Innowacyjna Gospodarka na lata 2007–2013
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
odpowiedniej licencji.
jedynie poprzez zakup
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
funkcyjnych z diodami LED.
7.2.3.
Sekretarz musi
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.
programowalnych klawiszy
mieć możliwość kontroli i administracji połączeń przychodzących do
1x Dyrektor i 1x Sekretarz
- 16 -
7.2.9.
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.
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.
9.
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.
SZKOLENIA
9.1.
9.2.
10.
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.
Dostawca zapewni przeprowadzenie egzaminu z zakresu szkoleń dla ich uczestników.
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 BiologicznoChemicznych 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 -
11.2.8. Terminal końcowy – wideotelefon – sztuk 10
11.2.9. Terminal końcowy – stanowisko operatorskie awizo – sztuk 1
11.3. Część C) – zakup licencji i telefonów na potrzeby użytkowników budynku dydaktycznego dla potrzeb
Wydziału Lingwistyki Stosowanej oraz Wydziału Neofilologii w rejonie ulic Lipowej – Dobrej – Wiślanej
– Browarnej w Warszawie
11.3.1. Licencja użytkownika (numer telefonu) dla centrali telefonicznej typu SoftSwitch SIP – sztuk 200
11.3.2. Licencja użytkownika (numer telefonu) dla systemu bilingowego – sztuk 200
11.3.3. Licencja użytkownika (numer telefonu) dla systemu poczty głosowej – sztuk 10
11.3.4. Licencja użytkownika (numer telefonu) dla systemu obsługi faksów – sztuk 10
11.3.5. Licencja użytkownika mobilnego (numer telefonu) pozwalająca na pracę z zewnątrz sieci IP
Zamawiającego – sztuk 10
11.3.6. Terminal końcowy – telefon VoIP – sztuk 30
11.3.7. Terminal końcowy – zestaw sekretarsko-dyrektorski – sztuk 10
11.3.8. Terminal końcowy – wideotelefon – sztuk 10
11.3.9. Terminal końcowy – stanowisko operatorskie awizo – sztuk 1
- 21 -

SZCZEGÓŁOWY OPIS PRZEDMIOTU ZAMÓWIENIA

Transkrypt

Podobne dokumenty

Wydział Neofilologii UW Warszawa, dn. 6 lutego 2017 r. Znak: WNf

klasa humanistyczno-artystyczna

Wydział Zarządzania Dziekan Wydziału Zarządzania Uniwersytetu

Wersja FS - Program Infrastruktura i Środowisko 2007-2013

POLITECHNIKA WARSZAWSKA WYDZIAŁ MATEMATYKI

załącznik - Wydział Studiów Nad Rodziną UKSW