Гумвс україни в Донецькій області затверджую
Вид материала | Конкурс |
- Автогосподарство при гумвс україни в Донецькій області затверджую, 871.02kb.
- Порядок надання гумвс україни в донецькій області дозволу про відповідність вимогам, 71.67kb.
- Держкомстат Головне управління статистики у Донецькій області, 47.43kb.
- Довідка про підсумки роботи Держуправління охорони навколишнього природного середовища, 888.56kb.
- При гумвс україни в Автономній Республіці Крим, 32.73kb.
- Держстат України Головне управління статистики у Донецькій області, 363.51kb.
- Нституції України та Кримінально-процесуального кодексу України (далі кпк) Верховний, 278.55kb.
- Держкомстат Головне управління статистики у Донецькій області, 423.57kb.
- Держкомстат Головне управління статистики у Донецькій області, 126.15kb.
- Розробка регіональної програми проведення екологічного та радіаційного моніторингу, 2667.66kb.
(посада особи) (підпис) (розшифрування підпису (П.І.Б.))
М.П.
Додаток 2
ЗАЯВА-ПРОПОЗИЦІЯ
Ми, (назва Учасника), подаємо свою пропозицію конкурсних торгів щодо участі у торгах на закупівлю (найменування предмету закупівлі) згідно з вимогами документації конкурсних торгів Замовника торгів на загальну суму _(цифрами та прописом)_ грн. відповідно до відомості(ей) цін, що входить(ять) до складу нашої пропозиції конкурсних торгів, та є її невід’ємною(ими) частиною(ами).
Наші умови оплати даної закупівлі: __________________________________________
Ми зазначаємо, що, відповідно до вимог чинного законодавства України, маємо право на здійснення господарської діяльності, передбаченої цією закупівлею, маємо всі необхідні документи, вимоги до обов’язкової наявності яких містяться в законодавстві України, а також повідомляємо, що на предмет закупівлі, який ми пропонуємо поставити у разі перемоги у торгах, відсутні права третіх осіб (права наймача, право застави, право довічного користування тощо).
Вивчивши Вашу документацію конкурсних торгів ми погоджуємося виконати всі її вимоги та вимоги договору про закупівлю (далі - Договір) на умовах, зазначених у цій пропозиції.
Якщо ця наша пропозиція буде акцептована, ми зобов’язуємося підписати Договір у строки та на умовах, зазначених у документації конкурсних торгів, та взяти на себе зобов'язання виконати всі умови, передбачені в Договорі.
Ми погоджуємося дотримуватися умов цієї пропозиції протягом _(цифрами)_ календарних днів з дати розкриття пропозицій конкурсних торгів. Наша пропозиція буде обов'язковою для нас і може бути акцептована Вами у будь-який час до закінчення зазначеного строку.
Ми погоджуємося з умовами, що Ви можете відхилити нашу пропозицію згідно з умовами документації конкурсних торгів, та розуміємо, що Ви не обмежені у прийнятті будь-якої іншої пропозиції з більш вигідними для Вас умовами.
(посада особи) (підпис) (розшифрування підпису (П.І.Б.))
М.П.
Примітки:
1. Заява-пропозиція подається на бланку Учасника (у випадку, якщо Учасник такий бланк має).
2. Учасник-фізична особа складає заяву-пропозицію за цією ж формою, але від імені першої особи.
3. Усі зазначені в заяві-пропозиції умови мають бути узгоджені з умовами, приведеними у запропонованому Учасником проекті договору про закупівлю.
Додаток 3.1
Відомості про Учасника
(для фізичної особи)
- Прізвище, ім'я, по батькові: _____________________________________________;
- Паспортні дані (серія, номер паспорта, ким і коли виданий): _________________;
- Місце проживання: ____________________________________________________;
- Поштова адреса: ______________________________________________________;
- Ідентифікаційний номер фізичної особи - платника податків та інших обов'язкових платежів - для фізичної особи _______________________________;
- Телефон: ____________________________________________________________;
- Факс: _______________________________________________________________;
- Адреса електронної пошти: ____________________________________________;
- Найменування банку, що обслуговує Учасника: ___________________________;
- Поточний (розрахунковий) рахунок: _____________________________________;
- МФО: _______________________________________________________________;
- Інша інформація* _____________________________________________________.
(посада особи) (підпис) (розшифрування підпису (П.І.Б.))
М.П.
Примітки:
* - зазначається будь-яка інформація на розсуд Учасника.
Додаток 3.2
Відомості про Учасника
(для юридичної особи)
- Повна назва: _________________________________________________________;
- Код ЄДРПОУ (ЗКПО): ________________________________________________;
- Юридична адреса: ____________________________________________________;
- Поштова адреса: _____________________________________________________;
- Телефон: ____________________________________________________________;
- Факс: _______________________________________________________________;
- Адреса електронної пошти: ____________________________________________;
- Профілюючий напрямок діяльності: _____________________________________;
- Найменування банку, що обслуговує Учасника: ___________________________;
- Поточний (розрахунковий) рахунок: _____________________________________;
- МФО: ______________________________________________________________;
- Прізвище, ім’я, по-батькові керівника: ___________________________________;
- Найменування посади керівника: _______________________________________;
- Інша інформація* ____________________________________________________
(посада особи) (підпис) (розшифрування підпису (П.І.Б.))
М.П.
Примітки:
* - зазначається будь-яка інформація на розсуд Учасника.
Додаток 4
ВІДОМІСТЬ ЦІН
№ з/п | Найменування предмету закупівлі | Кількість | Ціна | Загальна сума |
| | | | |
| | | | |
| | | | |
| | | | |
разом: | |
(посада особи) (підпис) (розшифрування підпису (П.І.Б.))
М.П.
Додаток 5
СПЕЦІФІКАЦІЯ ЩОДО ПРЕДМЕТА ЗАКУПІВЛІ
Найменування товару | Одиниця виміру | Очікувана кількість |
Програмно-апаратний комплекс контакт центру | Комплект | 1 |
Примітки:
* - усі показники та функціональні можливості еквіваленту мають бути не гіршими, ніж у зазначеного товару
Технічні вимоги до предмету закупівлі
1. Функціонування в складі кластера, реалізовуючи відмовостійкий режим роботи. Внутрішньокластерна взаємодія повинна здійснюватися на базі протоколу IP. У одному кластері має підтримуватися робота не менш ніж 3 серверів управління, кожний з яких може виконувати встановлення з’єднань.
2. Сервери управління, що входять до складу кластера, повинні забезпечувати :
- виконання синхронізації бази даних з інформацією щодо конфігурації пристроїв, а також синхронізації інформації про доступність тих або інших телефонних служб, IP-телефонних апаратів;
- підтримку катастрофостійкого режиму роботи, тобто, сервери управління можуть знаходиться в різних частинах однієї будівлі, різних будівлях або в різних містах.
3. Смуга пропускання не більше ніж 100 мбіт/с, та затримку передачі в одному напрямі не менше 40 мс. каналами зв'язку для внутрішньокластерної взаємодії.
4. Централізоване налаштування кластера з використанням єдиного адміністративного інтерфейсу.
5. При виході сервера з ладу, голосові з'єднання, встановлені між пристроями системи не повинні примусово обриватися.
6. Здійснення оновлення програмного забезпечення без зупинки роботи системи.
7. Функціонування не менше 30000 IP-телефонних апаратів на одному кластері серверів управління.
8. Продуктивність не менше 250000 BHCC (Busy Hours Call Completions) на одному кластері серверів управління.
9. Автоматично автономну роботу телефонної системи у разі втрати з'єднання між кластером серверів управління і віддаленим майданчиком, устаткування на віддаленому майданчику.
10. Надання можливості віддаленого налаштування.
11. Надання можливості віддаленого моніторингу.
12. Надання інтерфейсів інтеграції з додатковим програмним забезпеченням – системами голосової пошти, системами інтерактивних голосових меню і т.і.;
13. Зберігання інформації про виконані з'єднання.
14. Інформація про абонентів системи повинна зберігається в службі каталогів.
15. Сервер управління може поставлятися з вбудованою службою каталогів або працювати з зовнішньою службою каталогів.
16. Підтримувати наступні служби каталогів: Microsoft Active Directory.
17. Сервер управління повинен підтримувати протокол доступу до служби каталогів LDAP, RFC 2251.
18. Підтримувати наступні протоколи і технології для стиковки із зовнішніми телефонними системами:
- стек протоколів H.323, включаючи H.225.2, H.225 RAS (для реєстрації на H.323 сторожі), H.245 та взаємодію з голосовими шлюзами і клієнтськими H.323 пристроями;
- протокол MGCP управління шлюзами (для аналогових і цифрових транкових портів). При використанні MGCP для транкових підключень технологію PRI Backhaul для передачі сигнального каналу поверх IP-мережі. Для транспорту сигнальної інформації використання протоколу з гарантованою доставкою, наприклад, reliable UDP або TCP.
19. Повинні підтримуватися наступні стандартні сигналізації:
- Q.931 і ISO Q.SIG;
- інтерфейс SMDI (Simple Message Desk Interface) для інтеграції з системами голосової пошти.
20. Володіти наступними функціями налаштування і моніторингу:
- доступ до адміністративного інтерфейсу повинен здійснюватися через web за допомогою протоколу http;
- забезпечення контрольованого доступу до адміністративного інтерфейсу управління.
21. Для ідентифікації користувачів сервер управління повинен використовувати службу каталогів, звернення до якої здійснюється за допомогою протоколу LDAP.
22. Сервер управління повинен забезпечувати формування груп користувачів і привласнення цим групам різних рівнів доступу до ресурсів системи.
23. Сервер управління повинен контролювати звернення до наступних ресурсів:
- регулювання телефонних апаратів;
- регулювання плану нумерації;
- регулювання загальносистемними налаштуваннями сервера управління;
- налаштування голосових шлюзів.
24. Дії користувачів, що виконуються при доступі до ресурсів, повинні протоколюватися сервером управління у файлі журналу;
25. Сервер управління повинен підтримувати протокол управління SNMP, RFC 2012.
26. На додаток до стандартних параметрів MIB, сервером управління повинні підтримуватися розширення, що дозволяють за допомогою SNMP отримувати інформацію про зареєстровані телефонні апарати, їх кількість, їх IP-адреси, час останньої реєстрації.
27. Відправка SNMP Trap при настанні наступних подій: відмова системи; відключення телефонного апарату; зміні стану транкового порту голосового шлюзу.
28. Підтримка протоколу syslog для повідомлення про події і виконання відладки.
29. Підтримка розвинених засобів налаштування, що включають можливість налаштування стиків із зовнішніми системами за допомогою шлюзів, контрольованих сервером управління.
30. Повне збереження інформаційного обміну в сигнальному каналі при використанні протоколів Q.931 або Q.SIG.
31. Підтримка можливості відладки функціонування стеків протоколу H.323, включаючи H.225.2, H.225 RAS і H.245.
32. Наявність вбудованого засобу моніторингу в реальному часі.
33. Підтримка моніторингу числа активних з'єднань та числа зареєстрованих пристроїв та здійснення доступу до засобу моніторингу через web-інтерфейс.
34. Зберігання інформації про встановлені з’єднання.
35. Підтримка збереження інформації в реляційній базі даних або в текстовому файлі.
36. На додаток до інформації про час виклику, абонентів, вид з'єднання, час розмови і причини завершення, зберігання інформації про якість телефонної розмови з телефонних апаратів системи відразу після завершення виклику.
37. Інформації щодо кількості втрачених пакетів і середньої варіації затримки.
38. Сервер управління повинен:
- містити вбудований засіб аналізу інформації про встановлені з'єднання;
- генерувати звіти про встановлені з'єднання за заданий проміжок часу, їх кількості і загальній тривалості, по окремих користувачах системи.
39. Інформація про користувачів системи, а також їх телефони повинні витягуватися з корпоративної служби каталогів, доступної по протоколу LDAP.
40. Засіб генерації звітів повинен мати режим автоматичної генерації звітів за день, тиждень, місяць і виконувати автоматичну розсилку цих звітів кожному з абонентів системи, або адміністраторові.
41. При підрахунку кількості дзвінків і їх загальної тривалості сервером управління повинна виконуватися деталізація до наступних типів дзвінків:
- внутрішній - в межах мережі IP-телефонії;
- міський-вихід в міську мережу;
- міжміський і міжнародний.
42. У системі повинні також підтримуватися звіти про якість телефонних з'єднань.
43. Сервер управління повинен:
- надавати програмний інтерфейс для маніпуляції базою даних пристроїв, отримання інформації про зареєстровані пристрої і їх IP-адреси. Повинні підтримуватися операції додавання нових пристроїв, зміни параметрів існуючих пристроїв, видалення пристроїв, зміни плану нумерації, встановлення обмежень по виконанню з'єднань;
- мати функції для забезпечення гарантій якості обслуговування та контролю виділення смуги пропускання (Call Admission Control). Для цієї мети пристрої системи повинні групуватися по їх територіальному розташуванню, враховуючи топологію мережі. Повинна бути можливість вказівки максимальної смуги пропускання, використовуваної для виконання голосових з‘єднань до групи пристроїв. При встановленні з‘єднань сервер управління повинен приймати до уваги поточну смугу пропускання, у разі її браку, повинна підтримуватися можливість маршрутизації через телефонну мережу загального користування;
- володіти функціями контролю виділення смуги пропускання (Call Admission Control) використовуючи протокол RSVP;
- для забезпечення високої якості переговорів в межах локальної обчислювальної мережі і економії смуги пропускання при використанні каналів зв'язку з обмеженою пропускною спроможністю в глобальній обчислювальній мережі автоматично вибирати алгоритм кодування голосової інформації між пристроями системи, виходячи з їх взаємного розташування. Наявність можливості використання в локальній обчислювальній мережі алгоритму кодування G.711, а при дзвінках між вузлами алгоритму кодування G.729 (a), iLBC, ААС.
44.Наявність наступних, призначених для користувача функцій:
- індикація виклику на екрані телефонного апарату. Повинна бути передбачена можливість відключення звукової індикації;
- можливість автоматичного підняття трубки під час надходження дзвінка;
- підтримка автоматичної перемаршрутизациії дзвінків і автоматичного вибору маршруту (Automatic Alternate Routing і Automatic Route Selection). При збої голосового шлюзу або браку смуги пропускання для встановлення з'єднання, сервер управління повинен автоматично вибирати запасний маршрут або шлюз;
- автоматичне визначення номеру (Automatic Number Identification, ANI). Номер повинен передаватися в повідомленнях Q.931 або H.225;
- перенаправлення виклику. Повинна підтримуватися можливість безумовного перенаправлення всіх викликів, перенаправлення при зайнятості
номера абонента або за відсутності відповіді протягом встановленого інтервалу часу;
- парковка викликів. Сервер управління повинен забезпечувати можливість парковки встановленого з'єднання на певний номер, для його подальшого продовження з іншого телефонного апарату;
- перехоплення викликів і групове перехоплення викликів. Сервер управління повинен забезпечувати можливість перехоплення викликів, що поступають на телефонні апарати групи, з телефонного апарату, що належить цій групі. Сервер управління також повинен забезпечувати можливість перехоплення викликів, що належать іншій групі. Для цього абонент повинен при перехопленні виклику вказати номер групи;
- виклик, що чекає. Сервер управління повинен підтримувати режим виклику, що чекає. Під час отримання другого дзвінка на зайняту абонентську лінію, повинна забезпечуватися індикація на екрані телефону і лунати звуковий сигнал. Абонент повинен мати можливість утримати поточне з'єднання і перемкнутися на дзвінок, що поступив;
- ідентифікація номера абонента, що дзвонить (Calling Line Identification ). Сервер управління повинен надавати інформацію про номер абонента, що дзвонить;
- ідентифікація імені абонента, що дзвонить (Calling Name Identification, CNID). Сервер управління повинен надавати інформацію про ім'я абонента, що дзвонить.
45. Сервер управління повинен:
- забезпечувати можливість розділення планів нумерації, і визначення класів обмежень при виконанні викликів між абонентами системи;
- забезпечувати прийом і відправку набраного номера (Dialed Number Identification Service, DNIS) і номера, з якого здійснювалося перенаправлення (Redirected Dialed Number Identification Service, RDNIS);
- підтримувати трансляцію набраних номерів або отриманих цифр;
- забезпечувати функцію Direct Inward Dialing на аналогових голосових шлюзах;
- підтримувати функцію утримання виклику і зняття з утримання. У моменти, коли дзвінок знаходиться на утриманні, абоненти системи повинні чути музику на утриманні.
- мати у складі компонент, що виконує генерацію музики на утриманні. Як джерело можуть використовуватися звукові файли у форматі WAV, програвачі, що підключаються аналоговим входом до сервера управління. Повинен забезпечуватися режим генерації потоків музики на утриманні в режимі багатоадресної розсилки (IP Multicast);
- забезпечувати призначений для користувача web-итерфейс для індивідуальної настройки параметрів телефонної системи. Користувач повинен мати можливість установки номера безумовного перенаправлення викликів для тих, що належать йому телефонних апаратів, можливість настройки кнопок швидкого набору. Призначений для користувача інтерфейс управління також повинен включати засіб пошуку користувачів в корпоративному довіднику. Повинен підтримуватися режим, при якому набір телефонного номера з
телефонного апарату користувача ініціюється безпосередньо з телефонного довідника абонентів, через web-інтерфейс;
- підтримувати створення конференцій. Конференція може бути організована «на льоту», підключенням абонентів одним з учасників в процесі телефонної розмови, або спланована наперед. У останньому випадку, учасники підключаються до конференції самостійно, подзвонивши наперед на певний номер.
- підтримувати в своєму складі програмний компонент для організації конференцій не менше чим на 48 учасників.