Функционально-технические требования

Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
Функционально-технические требования
к развертыванию услуг
«Rich Communication Services»
Москва
2015
Page 1 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
Оглавление
1
2
3
4
5
6
7
8
9
10
11
12
Функция документа ............................................................................................................................................... 3
Язык предложений ................................................................................................................................................. 3
Терминология ........................................................................................................................................................... 3
Описание технического решения ................................................................................................................... 5
Общие требования к участнику ....................................................................................................................... 6
Потребительские свойства продукта ........................................................................................................... 6
Функциональные требования ...........................................................................................................................12
СОРМ ................................................................................................................................................................................21
Требования к управлению проектом со стороны участника ............................................................21
Лицензионная информация ................................................................................................................................21
Требования по защите инвестиций ................................................................................................................21
Требования по гарантийному и техническому обслуживанию оборудования .......................22
Page 2 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
Функция документа
Настоящий документ описывает функционально-технические требования к Системе,
обеспечивающей функционирование услуги Rich Communication Services (далее RCS), а также
требования к поставке, пуско-наладке и интеграции оборудования в существующую сеть ОАО
МГТС.
Данные требования определяют набор интерфейсов и функционала, обязательных к
исполнению производителем, для признания Системы пригодным к использованию в процессе
оказания услуг абонентам ОАО МГТС.
В рамках настоящего запроса информации Участник должен представить предложение по
поставкам оборудования и программного-обеспечения, включая все элементы, обязательные и
опциональные, а также по пуско-наладке и интеграции оборудования в существующую сеть
ОАО МГТС.
Предложение должно быть представлено в виде прайс-листа с указанием спецификации и
отдельно стоимости оборудования и работ по каждому объекту и суммарно.
Компания оставляет за собой право включать дополнения и изменения в технические
требования, спецификации работ и сроки их исполнения при заключении договора с
Участником.
Язык предложений
Язык подачи предложений Участниками процедуры запроса информации ОАО МГТС и всей
сопроводительной документации по проекту - Русский
Терминология
Наименование термина
Сокращение
Определение термина (расшифровка
сокращения)
Основные определения:
Rich Communication Services
Система
RCS
Система
Платформа, позволяющая совершать телефонные и
видео звонки, отправлять SMS, MMS, мгновенные
сообщения и обмениваться файлами между
различными устройствами.
Совокупность Программного обеспечения и
Оборудования, обеспечивающая функционирование
RCS
Вводимые определения:
Операционная Система
ОС
Техническое задание
ТЗ
Multipurpose Internet Mail
Extensions
Network Time Protocol
MIME
NTP
Комплекс программ, обеспечивающий управление
аппаратными средствами компьютера, работу с
файлами, ввод и вывод данных, а также выполнение
прикладных задач и утилит.
Исходный документ для конструирования
технического устройства либо разработки
информационной системы. ТЗ содержит основные
технические требования, предъявляемые к изделию.
Набор стандартов описывающих передачу различных
типов данных посредством электронной почты и
других средств.
Протокол сетевого времени. Протокол, с помощью
которого производится синхронизация системного
времени компьютера с временем NTP-сервера.
Page 3 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Наименование термина
Сокращение
Версия 1.4
Дата 04.06.2015
Определение термина (расшифровка
сокращения)
Протокол копирования файлов, использующий в
качестве транспорта протокол SSH.
Протокол, предназначенный для обмена и управления
данными поверх какого-либо криптографического
протокола (обычно SSH).
Протокол, позволяющий передавать данные и
производить удалённое управление операционной
системой по защищенному каналу.
Криптографический протокол, обеспечивающий
конфиденциальность и целостность данных при их
передаче по сети.
Приложение для работы с услугой, устанавливаемое на
мобильном устройстве абонента
Персональный компьютер
Клиент, установленный на PC
Совершение абонентом услуги голосового и видеовызова, отправка SMS-сообщения или текстовые
сообщения.
Secure copy
SCP
SSH File Transfer Protocol
SFTP
Secure Shell
SSH
Transport Layer Security
TLS
Мобильное приложение
МП
Personal computer
PC-клиент
PC
Коммуникация
---
Business requirement
BR
Бизнес требование
Functional requirement
FR
Функциональное требование
---
Требования, отсутствие которых, не может служить
отказом от рассмотрения коммерческого предложения,
но которые могут быть учтены на этапе выбора
поставщика, при прочих равных условиях.
Опционально
Page 4 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
Описание технического решения
Необходимо развернуть Систему для оказания услуг Rich Communication Services (RCS 5.1) и
интегрировать ее в существующую IMS-платформу Huawei.
В рамках проекта предполагается использовать существующий TAS (Telephony Application
Server) компании Huawei. Система должна иметь возможность интеграции с RCS-клиентом
(мобильная и PC-версии) на базе стандарта RCS Crane компании Summit-tech. Участник вправе
предложить своего RCS-клиента, если он соответствует требованиям RFI.
Система должна позволять осуществлять коммуникации с любыми номерами (мобильная
связь, фиксированная связь, внутренние и международные звонки) через МП, PC-клиент или
Web-приложение, с возможностью тарификации коммуникаций по тарифам, действующим на
тарифном плане абонента. Под коммуникацией понимаются: голосовые и видео вызовы, SMS и
MMS сообщения, мгновенные текстовые сообщения и передача файлов. В качестве
идентификатора используется фиксированный номер абонента МГТС, поэтому должна быть
обеспечена интеграция с лицевым счетом абонента МГТС. Коммуникация может
осуществляется по каналам передачи данных (Wi-Fi, GPRS, UMTS, LTE).
При работе Системы должна использоваться абонентская база, хранящаяся на HSS, все услуги
должны тарифицироваться с привязкой к абонентскому счёту, который закреплён за
домохозяйством. Система не должна являться отдельной коммутационной платформой, а
должна выполнять функции AS IMS.
Система должна поддерживать работу и быть проинтегрирована с основным и резервным
ядром IMS.
Должна быть предусмотрена возможность ограничения услуг в зависимости от способа
подключения МП или PC-клиента (IP адрес, MAC адрес, dhcp opt.82). Предполагается
ограничивать клиенту возможность использования услуги зоной домашней точки Wi-Fi.
Page 5 of 23
Версия 1.4
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Дата 04.06.2015
Общая архитектурная схема реализации услуг RCS
Элементы, взятые в красную
рамку – новые и должны
поставляться в рамках проекта
Existing Apps (МТС)
Оборудование, расположенное
на технологических площадках
ОАО «МГТС» в г. Москва
SMSC
MMSC
Интеграция по интерфейсам,
выделенным синим цветом!
SIP, SMPP
MM7
IMS Application level
Billing (CDRs)
(HP-IUM)
Instant
message
TAS
Provisioning
CRM / FORIS
SOAP
ISC
Chat
ISC
Presence
ISC
ISC
File/Pics.
sharing
ISC
EAB
ISC
WebRTC
-GW
ISC
IMS CORE
FTP, SFTP
Fault Management
(HP TeMIP)
СОРМ передачи
данных в Москве
HSS
хCSCF
MRFC
IM-SSF
MGCF
CCF
OAM
SBC
PDF
IMMGW
IP
SIP
RTP
SIP,
RTP
Доступ по IP из сети
МГТС посредством
клиента на
телефоне или на
компьютере
Доступ по IP из
других сетей
посредством
клиента на
телефоне или на
компьютере
SIP,
RTMPS
Доступ по IP
посредством WEBинтерфейса
Рис.1 Общая архитектурная схема реализации услуг RCS
Общие требования к Участнику.
Участник должен быть официальным дилером, либо производителем Системы,
предлагаемой к поставке. Документооборот Участника должен
соответствовать
действующему законодательству РФ. При исполнении обязательств по договору с Заказчиком
не допускается смена юридического лица компании и переуступка обязательств по договорам
третьим лицам. Участник обязан иметь центр сервисного обслуживания товара на территории
РФ или договор об оказании услуг по гарантийному и послегарантийному обслуживанию
Системы с уполномоченным сервисным центром, квалифицированный менеджмент,
выделение сотрудника для работы с Заказчиком. Участник должен гарантировать готовность
к оперативному реагированию в процессе переговоров, к конструктивному диалогу с
Заказчиком.
Потребительские свойства продукта
Общие требования
BR.1. Прогноз по количеству абонентов в течение 12 месяцев – не более 50 тыс. абонентов.
Планируется, что в течение трех лет количество абонентов составит не более 300 тыс.
абонентов.
BR.2. Одна лицензия должна позволять пользоваться
одновременно на МП, PC и на web-интерфейсе.
сервисами
услуги
абоненту
Page 6 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
BR.3. Необходимо предоставить предложение для следующего количества пользовательских
лицензий: 10 тыс., 50 тыс., 100 тыс. и 300 тыс. абонентов.
BR.4. Реализация Rich Communication Services (RCS 5.1).
BR.5. Язык интерфейса русский/английский.
BR.6. Автоматическое определение возможности общения через сервис с выбранным
абонентом (capability discovery) (если не будет реализован Presence).
BR.7. Возможность воспользоваться сервисом абонентам любого тарифного плана.
BR.8. Единый лицевой счет абонента.
Поддерживаемые режимы работы RCS-клиента
BR.9.
BR.10.
BR.11.
BR.12.
Доступность и
статус
режима
ПодВозможности
Используемый Предоставляемая
Режим
«максимальн
держка
терминала
доступ
услуга телефонии
устройства
о доступного
качества» для
Голоса/Видео
Максимально
доступное качество
LTE
Доступно
RCS-AA
Голосового и Видео
IP-Вызова
Максимально
доступное качество
HSPA
Доступно
RCS-AA
Голосового и Видео
Best Effort IP
IP-Вызова
Voice & Video
Максимально
Call
доступное качество
3G/2G
Доступно
RCS-AA
Голосового и Видео
IP-Вызова
Максимально
Доступ не в режиме доступное качество
Доступно
RCS-AA
3GPP/3GPP2
Голосового и Видео
IP-Вызова
Таблица 1: Поддерживаемые режимы работы RCS-клиента
Автоконфигурация RCS клиента
BR.13. RCS приложение должно поддерживать автоконфигурацию согласно RCS 5.1, RCS-e 1.2.2
и выше.
BR.14. Поставщик
должен
предоставить
автоконфигурирования.
все
диаграммы
protocol
flow
для
BR.15. Должна поддерживаться автоконфигурация RCS-клиента через WLAN и другие виды
bearer. Поставщик должен перечислить все поддерживаемые виды bearer и связанные
ограничения при их использовании.
BR.16. Если автоконфигурация RCS-приложения закончилась неуспешно по причине отказа
bearer, то приложение должно поддерживать повторную попытку.
Page 7 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
Звонки
BR.17. Возможность принимать входящие вызовы с любых номеров и совершать исходящие
вызовы на любые номера.
BR.18. Абонент должен иметь возможность определять место приема вызова: PC, web или
телефон.
BR.19. АОН.
BR.20. Возможность переключать вызов с PC на абонентский терминал и обратно (например,
вызов может одновременно приходить на PC или МП, а абонент сам решает, как на него
ответить, одновременный ответ с двух устройств запрещен).
BR.21. Ожидание/удержание вызова.
BR.22. RCS-клиент должен поддерживать следующие кодеки: 16 kHzHD audio, G.722, iLBC, OPUS
(RFC 6716), G.729, G.711.
BR.23. RCS-клиент должен поддерживать Emergency call. Поставщик должен описать связанные
protocol flows.
Видео звонки
BR.24. Возможность совершения видео вызовов, а также возможность перехода в режим видео
вызова во время разговора.
BR.25. Возможность предоставления функции video sharing, a также демонстрации ранее
записанных видеороликов во время разговора.
BR.26. RCS-клиент должен поддерживать следующие видео кодеки: H.263-1998, H.263-2000, H264, WebM, H.265.
Page 8 of 23
Версия 1.4
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Дата 04.06.2015
Качество связи
BR.27. Приложение должно самостоятельно определять технические параметры передачи
данных на основании автоматического мониторинга каналов связи. Если качество
канала связи недостаточно для передачи голоса, видео должно появиться
предупреждение о том, что качество канала связи недостаточно для полноценной
работы сервиса.
RCS-клиент должен поддерживать in-band операции upgrade и downgrade качества голоса и
переключения кодеков. Поставщик должен описать связанные protocol flow.
Instant messaging / Мгновенная передача сообщений
BR.28. Чат 1&1.
BR.29. Групповой чат до 20 участников.
BR.30. Получение отчётов о доставке сообщений.
BR.31. Информирование о том, что вторая сторона печатает.
BR.32. Сигнализация о приходе нового сообщения.
BR.33. RCS-клиент должен поддерживать единый IMчат для SMS, MMS, RCS для частного
контакта.
File Sharing / Передача файлов
BR.34. Обмен файлами любого формата.
BR.35. Передача файлов между абонентами с возможностью контроля процесса передачи с
обеих сторон, а также независимо от статуса принимающей стороны.
BR.36. Возможность отправка карточки контакта другому контакту (vCard).
BR.37. Журнал обмена и передачи файлов.
BR.38. Просмотр загруженных файлов.
BR.39. Возможность отправки фотографий, как сделанных ранее, так и сделанных специально
для отправки.
BR.40. Прием файлов возможен только в случае подтверждения принимающей стороны,
возможно добавление отправителя в списки: “Никогда не принимать”, “Всегда
принимать”.
SMS
BR.41. Возможность отправлять стандартные SMS-сообщения.
BR.42. Получение отчётов о доставке SMS-сообщений.
Контакты
BR.43. Синхронизация адресной книги с порталом услуги, телефоном и PC.
BR.44. Просмотр, сортировка, группировка, управление группами (переименование, различные
варианты представления контактов в группе).
BR.45. RCS-клиент должен поддерживать конвергентную адресную книгу, которая бы
объединяла контакты телефона, социальных сетей, RCSи тп.
Page 9 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
Presence
BR.46. RCS-клиент должен поддерживать следующую базовую функциональность presence:
Доступность, Тип доступности: Voice, Video, IM, social network, Геолокацию, Никнейм, VIP
или не-VIP контакт.
BR.47. RCS-клиент должен поддерживать случай multi-device presence, как абонента, так и его
контактов.
BR.48. RCS-клиент должен поддерживать возможность изменения статуса.
BR.49. RCS-клиент должен поддерживать фильтрацию контактов по статусу (Свободен, Занят,
Не беспокоить и настраиваемые статусы) (в случае реализации Presence).
Интеграция с социальными сетями
BR.50. Возможность интеграции с социальными сетями.
BR.51. В клиенте необходимо предусмотреть различные обозначения для Абонентов
различных сообществ (Facebook, VK и т.п).
МMS (опционально)
BR.52. Получение отчётов о доставке MMS-сообщений, отправленных с PC, web-клиента или
MП.
BR.53. Возможность отправки IM сообщений в формате MMS(IM 2 MMS) (в этом случае должна
быть реализована проверка размера файлов).
Web-интерфейс
BR.54. Сервис должен запускаться c любой звуковой картой и любыми подключенными или
встроенными звуковоспроизводящими устройствами и микрофонами.
BR.55. Web-интерфейс сервиса должен быть брендирован (прототипы пользовательских
интерфейсов будут предоставлены ОАО «МГТС» на этапе начала разработки Системы в
рамках Приложения к настоящим функциональным требованиям).
BR.56. Должно быть реализовано меню “Справка” на русском языке.
BR.57. Доступ осуществляется через web-интерфейс, интегрированный в сервис “Личный
кабинет МГТС” через процедуру авторизации в WEB-SSO.
BR.58. Должна быть предусмотрена мобильная версия web-интерфейса.
BR.59. Должна быть обеспечена корректная работа веб-интерфейса полной и мобильной
версии (отображение в соответствии с предоставленными прототипами,
предоставления заявленных функций) в следующих браузерах, а также на всех новых
версиях данных браузеров, вышедших в течении 3-х лет, после запуска услуг в
коммерческую эксплуатацию:
BR.60. Microsoft Internet Explorer v8 и выше;
BR.61. Opera v3 и выше;
BR.62. Mozilla Firefox/ OS X 4 и выше;
BR.63. Mozilla Firefox/Windows v4 и выше;
BR.64. Google Chrome/ Windows v12 и выше;
BR.65. GoogleChrome/ OSX 4 и выше;
BR.66. Safari/ iOSv4 и выше;
Page 10 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
BR.67. Safari/ OSXv5 и выше.
PC-клиент
BR.68. PC-клиент должен быть брендирован (прототипы пользовательских интерфейсов
будут предоставлены ОАО «МГТС» на этапе начала разработки Системы в рамках
Приложения к настоящим функциональным требованиям).
BR.69. Сервис должен запускаться c любой звуковой картой и любыми подключенными или
встроенными звуковоспроизводящими устройствами и микрофонами.
BR.70. Для начала использования услугой на PC-абоненту достаточно ввести DEF-номер и
пароль, другие настройки должны быть подключены автоматически.
BR.71. Загрузить ПО можно с сайта МГТС с любого компьютера подключенного к интернет,
без ограничений. При этом программное обеспечение должно быть подписано
известным публичным удостоверяющим центром (Microsoft Code sign и тд.). Данные
подписи должны проверяться при инсталляции и работе ПО. В случае невозможности
проверки целостности и аутентичности ПО, его работа должна блокироваться.
BR.72. Доступ к сервису должен быть возможен через PC-клиент, на следующих ОС, а также на
всех новых версиях данных ОС, вышедших в течении 3-х лет, после запуска услуг в
коммерческую эксплуатацию.
BR.73. Windows XP, Windows Vista, Windows 7, Windows 8;
BR.74. MACOSX10.5 и выше.
Мобильное приложение
BR.75. Необходимо обеспечить возможность сохранения аутентификационных данных услуги
в памяти клиента, чтобы Абоненту не приходилось вносить их всякий раз, когда он
захочет воспользоваться Услугой.
BR.76. Мобильное приложение должно соответствовать гайдалйнам компании МГТС, будут
предоставлены на этапе разработки.
BR.77. Должно быть разработано МП, поддерживаемое следующими платформами, а также на
всех новых версиях данных операционных систем, вышедших в течение 3-х лет после
запуска услуг в коммерческую эксплуатацию:
BR.78. Android(v. 2.1и выше);
BR.79. iOS (v. 5 и выше);
BR.80. WinPhone(v.7и выше)(опционально);
BR.81. bada (опционально);
BR.82. Symbian (опционально).
BR.83. Возможность получения сообщений голосовой почты по протоколу IMAP, через
интерфейс услуги Голосовая почта + (Visual Voicemail) (Опционально).
BR.84. Отображение баланса.
BR.85. Передача координат местоположения в сообщении.
Page 11 of 23
Версия 1.4
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Дата 04.06.2015
Функциональные требования
Режим использования услуги
FR.1. Круглосуточно: 24 часа 7 дней в неделю. Показатель надежности – не менее 99,5%
(минимальное время бесперебойной работы).
Основные принципы построения платформы
Система и входящее в её состав оборудование должны соответствовать следующим
требованиям:
FR.2. Сертификаты соответствия (Декларации о соответствии) Минсвязи РФ, Сертификаты
соответствия ГОСТ Р;
FR.3. Для компонентов RCS обязательно требование реализации ф-й сервера приложений и
интерфейсов в соответствии с рекомендациями 3GPP/TISPAN. Более конкретно –
реализация интерфейсов IMS (для функционирования, билинга, управления): ISC (SIP),
Rf, Rf, Sh (DIAMETER), Ut, дата модели AS согласно стандартам TISPAN, 3GPP и IETF (3GPP
TS 23.002, 3GPP TS 23.218, 3GPP TS 23.228, 3GPP TS 24.229; 3GPP TS 29.364, ETSI TS 182
006, ETSI ES 283 003; RFC2976, RFC3261, RFC3262, RFC3265, RFC3311, RFC3323, RFC3325,
RFC3327, RFC3455, RFC3608, RFC3680, RFC3840, RFC3841, RFC4028, RFC4168, RFC4244).
FR.4. иметь настроенную службу NTP;
FR.5. иметь настроенную службу SNMP;
FR.6. поддерживать и, по возможности, иметь в наличии SNMP агенты;
FR.7. иметь настроенный консольный доступ ко всему серверному оборудованию и сетевым
элементам (ALOM/iLO/serial console). При использовании интерфейсов Serial console на
серверном оборудовании Системы в её состав должен входить консольный сервер;
FR.8. серверное оборудование и сетевые элементы, входящие в состав Системы, должны быть
зарезервированы по схеме n+1 (где n – количество активных единиц оборудования) и
работать в одном из отказоустойчивых режимов: active/standby или active/active;
FR.9. иметь настроенный инструментарий резервного копирования и восстановления данных
ключевых компонентов. Резервное копирование должно осуществляться ежедневно в
автоматическом режиме и без влияния на оказываемый сервис, а данные храниться не
менее 1 (одного) месяца;
FR.10. осуществлять централизованное резервное копирование на выделенный для этих нужд
сервер Компании;
FR.11. ОС серверного оборудования Системы должны быть установлены на RAID-массивах не
ниже 1-го уровня, каждый из которых должен оснащаться 1 (одним) резервным
дисковым накопителем в конфигурации горячей замены (hot spare),
FR.12. поддерживать возможность переноса БД Системы на серверы БД Компании;
FR.13. ОС, установленные на серверном оборудовании Системы, должны быть серверной
версии. Версии ОС и программных модулей должны быть из стабильных релизов не
ниже предпоследней версии на момент поставки Системы;
FR.14. поддерживать возможность
администраторов Системы;
управления
ролями
абонентов,
операторов
и
Page 12 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
FR.15. иметь криптографически защищенный GUI-интерфейс управления абонентскими
профилями (настройка, подключение/отключение услуг и т.д.) с поддержкой
возможности пакетной загрузки;
FR.16. иметь документированный API;
Требования к присоединению к IP-сети Компании
Для интеграции с IP-сетью МГТС в состав Системы должны входить соответствующие
сетевые элементы - коммутаторы, маршрутизаторы, межсетевые экраны и т.д.. Все
указанные сетевые элементы должны быть зарезервированы по схеме n+1 и
поддерживать работу в одном из следующих режимов резервирования:
FR.17. active/standby
FR.18. active/active.
Конкретный режим резервирования указанных сетевых элементов определяется для
каждой Системы индивидуально в зависимости от технических особенностей
оборудования и критичности сервиса, оказываемого на ее основе.
FR.19. Присоединения Системы к сетевой инфраструктуре Компании осуществляется на
уровне L3 модели OSI, для чего в составе платформы должны быть предусмотрены
соответствующие L3-коммутаторы. Указанные L3 коммутаторы Системы должны иметь
встроенный функционал узла CE в сети IP\MPLS и в обязательном порядке
поддерживать протоколы динамической маршрутизации OSPF, BGP и EIGRP.L2 и L3
FR.20. Коммутаторы Системы, указанные выше, должны иметь шасси не менее чем на 24
сетевых порта и uplink-интерфейсы со скоростью не менее 1Гбит/с.
Требования по информационной безопасности
FR.21. RCS-клиент должен иметь встроенный контроль целостности приложения и
компонентов с использованием электронной цифровой подписи с приведенной
стойкостью не менее 128 бит и использованием распознаваемых OS корневых
сертификатов.
FR.22. Целостность RCS-клиента и его компонентов должна криптографически проверяться
при каждом запуске клиента (trusted boot).
FR.23. RCS-клиент должен иметь встроенный функционал и возможности по ограничению
доступа к данным, функциями памяти Voice, Video, IM, Address book, File sharing, Social
Page 13 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
network со стороны других приложений. Данное ограничение должно действовать как
при работе через GUI, так и через различные API.
FR.24. Возможности по ограничению доступа к данным и функциям Voice, Video, IM, Address
book, File sharing, Social network со стороны других приложений должны настраиваться
пользователем и по умолчанию доступ должен быть блокирован.
FR.25. RCS-клиент должен использовать управление доступом с использованием принципа
“data caging”, при котором данные отделены от кода.
FR.26. Поставщик должен описать какие функции RCS-клиент публикует для использования
сторонними приложениями в OS.
FR.27. RCS-клиент должен иметь функционал удаленной очистки локальных данных и учетных
записей при утере устройства (remote device wiping & deactivation).
FR.28. RCS-клиент не должен иметь debug функциональности и компонентов.
FR.29. RCS-клиент не должен требовать прав root для работы.
FR.30. RCS-клиент и его компоненты, должны быть скомпилированы так, чтобы процесс
декомпиляции был невозможен: обфурскация или преобразование в машинный код.
FR.31. RCS-клиент должен иметь функционал блокирования паролем, при этом должны быть
две опции: блокирование всего приложения, блокирование частной функциональности
Voice, Video, IM, Address book, File sharing, Social network. По умолчанию RCS клиент
должен быть разблокирован.
FR.32. RCS-клиент должен поддерживать функционал black lists как для частных адресатов, так
и для частной функциональности: Voice, Video, IM, Address book, File sharing, Social
network.
FR.33. RCS-клиент должен использовать криптографические алгоритмы с приведенной
стойкостью 128 бит и более.
FR.34. Поставщик должен указать весь функционал RCS-клиента который использует
криптографию и указать используемые протоколы, алгоритмы и режимы их работы на
всех OS, для которых предоставляется клиент.
FR.35. Управление криптографическими ключами RCS-приложения должно быть реализовано
через использование криптографической функциональности OS. Поставщик должен
описать, как это реализуется на всех OS, для которых предоставляется клиент.
FR.36. Генерирование ключевого материала в RCS-клиенте должно осуществляться только с
использованием криптографически стойких датчиков случайных чисел. Поставщик
должен описать, какие ДСЧ используются и для каких целей.
FR.37. Доступ к данным учетных записей используемых в RCS-клиенте должен быть
блокирован для сторонних приложений или через API имеющиеся в OS. Поставщик
должен описать, как это реализовано.
FR.38. Данные учетных записей используемых в RCS-клиенте должны храниться в
зашифрованном виде с гарантией целостности. Поставщик должен описать, как это
реализовано. Access Security for the User-to-Network Interface (UNI).
Методы обеспечения безопасности сигнализации доступа
FR.39. Некоторые методы защиты доступа и аутентификации для протокола сигнализации SIP
определены в документах Error! Reference source not found. и Error! Reference source not
found. в части доступа к ядру системы IMS и службам, основанным на IMS, таким, как RCS.
Page 14 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
Возможность применения и выбор метода в высшей мере зависит от клиента RCS и типа
доступа (например, доверенный или сомнительный), включая то, что поддерживается ядром
системы IMS или требуется для него.
Дайджест-аутентификация SIP и TLS
FR.40. SIP-Дайджест представляет собой аутентификацию, основанную на запросе имени
пользователя и пароля (основанном на HTTP-Дайджест), которая подходит для
широкополосного доступа к IMS или для клиентов RCS, которые не имеют основанные
на AKA мандаты (например, xSIM) или не поддерживают протокол IPsec, основанный на
IMS AKA. SIP-Дайджест широко реализуется в клиентах SIP, основанных на стандартах и
протоколах Целевой группы инженерной поддержки интернета (IETF) и часто
применяется с TLS. Поддержка для SIP-Дайджест с/без TLS определена в документах
Error! Reference source not found. и Error! Reference source not found. в части доступа
к IMS из сетей, доступ которых определен как «не-3gpp» (например сети с
широкополосным/фиксированным доступом).
FR.41. Если клиент RCS задействован для дайджест-аутентификации SIP, клиент будет
использовать предварительно сконфигурированное имя пользователя и пароль SIP для
аутентификации в ядре IMS. В первоначальном сообщении SIP REGISTER (перед
проверкой дайджеста) клиент RCS должен будет добавить заголовок авторизации (в
соответствии с Error! Reference source not found.), который включает в себя дайджест
имени пользователя SIP и пустой параметр ответа дайджест-аутентификации. Это
позволяет ядру IMS обрабатывать дайджест имени пользователя SIP, как
конфиденциальный идентификатор пользователя IMS (IMPI), который отличается от
общедоступного идентификатора пользователя IMS (IMPU), позволяя зарегистрировать
один и тот же общедоступный идентификатор пользователя SIP (или IMPU) из
многочисленных клиентов/устройств RCS.
FR.42. Последовательность операций регистрации IMS для дайджест-аутентификации SIP
показана на Error! Reference source not found.. В этой примерной последовательности
операций клиент RCS подключен к ядру IMS через широкополосное Интернетсоединение стандарта Wi-Fi.
Рисунок 1: Регистрация с дайджест-аутентификацией SIP
Page 15 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
FR.43. Примечание: Если Дайджест-аутентификация два раза заканчивается неудачей с
ответом SIP 401 UNAUTHORIZED (SIP 401 НЕ РАЗРЕШЕНО), клиент не должен делать
дальнейших попыток регистрации, а скорее посчитать текущую конфигурацию
недопустимой и при следующей перезагрузке мобильного телефона принудительно
запустить процесс повторной конфигурации с использованием процедур, описанных в
главе Error! Reference source not found..
FR.44. SIP-Дайджест с TLS рекомендуется использовать для доступа из сетей сомнительного
доступа (включая WLAN без шифрования). TLS предусматривает аутентификацию по
каждому сообщению, защиту целостности и шифрование для сигнализации SIP. TLS с
серверными сертификатами также предусматривает аутентификацию ядра IMS для
клиента RCS. Обратите внимание на то, что для этого требуется, чтобы клиент имел
корневой или промежуточный сертификат Органа сертификации (CA), который
находится в цепочке подписания сертификатов TLS для ядра IMS (например, P-CSCF).
FR.45. Если клиент RCS задействован для использования SIP/TLS, он должен использовать порт
SIP TLS, полученный посредством процедур обнаружения P-CSCF (например,
посредством записей DNS SRV [Служебных записей]) или конфигурации. Однако если
клиент RCS не способен определить порт SIP TLS посредством этих мер, он должен
использовать стандартный порт SIP для TLS, как определено в документе Error!
Reference source not found..
FR.46. Клиент RCS, задействованный для использования SIP/TLS, должен сначала использовать
соглашение об обеспечении безопасности SIP (sec-agree) Error! Reference source not
found., как определено в документе Error! Reference source not found. для первого
согласования использования TLS с его прокси-сервером SIP (P-CSCF). В качестве
альтернативы клиент RCS может сначала попытаться организовать сеанс TLS с проксисервером SIP (P-CSCF) перед отправкой первоначального сообщения «SIP Register»
(«Регистрация SIP»), которое не включает в себя sec-agree для TLS. Однако при таком
подходе S-CSCF может запрашивать последующие сообщения о нерегистрации («nonRegister») с ответом 407 (Proxy Authentication Required – Требуется аутентификация
прокси-сервера), если он не настроен на доверие SIP-Дайджест без указания
обеспечения безопасности сигнализации, или если P-CSCF способен предоставить такое
указание, несмотря на то, что не используется sec-agree.
FR.47. Необходимо обратить внимание на то, что в обоих случаях прокси-сервер SIP (P-CSCF)
аутентифицирует клиент RCS с использованием сертификата сервера TLS.
FR.48. Если SIP-Дайджест не используется с TLS, ядро IMS может потребовать аутентификации
запросов о нерегистрации SIP («non-REGISTER SIP») с использованием тех же самых
механизмов запроса SIP-Дайджест, какие используются во время регистрации. Однако в
этом случае запрос SIP-Дайджест отсылается в ответе 407 (Требуется аутентификация
прокси-сервера). Клиент RCS, принимающий ответ 407 (Требуется аутентификация
прокси-сервера), должен ответить отправкой запроса аутентифицированного SIP,
который включает в себя заголовок «Proxy Authorization» («Авторизация проксисервера») с дайджест-ответом. Клиент RCS должен кэшировать данные дайджестпроверки (например, случайный код сервера («nonce»)) для использования в
последующих аутентифицирующих запросах SIP с использованием счетной величины
«nonce» (для защиты от воспроизведения) в соответствии с Error! Reference source not
found. и включения заголовка «Proxy Authorization» («Авторизация прокси-сервера») в
обновленный дайджест-ответ. При этом исключается необходимость проверки ядром
IMS каждого запроса SIP перед тем, как данные аутентификации потеряют силу. Как
только данные дайджест-аутентификация теряют силу, выпускается новый запрос.
Page 16 of 23
Версия 1.4
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Дата 04.06.2015
FR.49. Примечание: ядро IMS также может поддерживать привязку идентификаторов IMS
клиента RCS, аутентифицируемых во время регистрации к IP-адресу источника (и порту,
если используется Error! Reference source not found. “SIP Outbound” («Исходящий SIP»).
В таких случаях, ядро IMS может не потребовать последующей нерегистрации на основе
сообщений SIP, аутентифицируемых с использованием SIP-Дайджест, если
идентификаторы и адреса источников в сообщениях совпадают с привязкой,
полученной в процессе дайджест-аутентифицированной регистрации.
Профили обеспечения безопасности сигнализации доступа для RCS
FR.50. Для доступа к услугам RCS должен использоваться механизм аутентификации и
обеспечения безопасности сигнализации SIP-Дайджест или SIP-Дайджест с TLS .
Устройство
FR.51.
Задействован
широкополосн
ый доступ
(режим RCS-AA)
Доступ
Применяемые
методы
защиты
SIP-Дайджест
или SIPДайджест с TLS
Возможность
применения и
пригодность
При использовании
больше предпочтения
рекомендуется отдавать
SIP-Дайджест с TLS по
сравнению с SIP-Дайджест
без TLS
SIP-Дайджест используется
для мобильных устройств,
которые не поддерживают
IMS AKA для доступа к
WLAN.
Таблица 2: Профили обеспечения безопасности сигнализации доступа для RCS
Безопасность среды доступа
Безопасный RTP (SRTP)
FR.52. SRTP Error! Reference source not found. может использоваться для обеспечения
аутентификации по каждому сообщению, защиты целостности и шифрования, как для
потоков RTP, так и для потоков RTCP, участвующих в сеансах голосовой и видео связи
реального времени. SRTP рекомендуется использовать для обмена информацией в
любой сомнительной сети, в которой конфиденциальность (или ее отсутствие)
вызывает озабоченность. Для примера, голосовой или видео вызов в сети Wi-Fi
(например, «Точка беспроводного доступа») без какого-либо шифрования в WLAN
(Беспроводная локальная сеть) весьма допускает прослушивание.
FR.53. Установление связи и обмен ключами для SRTP в RCS должны быть основаны на SDES
(Описания безопасности медиа-потоков в Протоколе описания сеанса, ср. Error!
Reference source not found.), которые транспортируются в SDP, следуя модели
Page 17 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
предложения/ответа SIP SDP. Профили SDES и SRTP для обеспечения безопасности
среды в IMS определены в документе Error! Reference source not found..
FR.54. Обратите внимание на то, что документ Error! Reference source not found. определяет
для работы SDES/SRTP два режима: режим e2ae («от конца до границы доступа» –
полный доступ) и режим e2e («от конца до конца» – ограниченный доступ). В режиме
e2ae SDES работает между клиентом IMS и граничным прокси-сервером SIP, т.e. P-CSCF
(IMS-ALG). Шлюз доступа IMS, контролируемый P-CSCF (IMS-ALG [Шлюз уровня
приложений]), обеспечивает прерывание SRTP на «Границе доступа» (“Access Edge”). В
режиме e2e, SDES и SRTP транспортируются от конца до конца между двумя конечными
пользовательскими клиентами.
FR.55. Клиент RCS, поддерживающий SRTP и SDES и поддерживающий режим e2ae, должен
указывать это во время регистрации IMS в соответствии с документом Error! Reference
source not found.. P-CSCF (IMS ALG), если он поддерживает режим e2ae, указывает об
этом оборудованию пользователя (UE) в ходе процедур регистрации IMS в соответствии
с документом Error! Reference source not found.. Использование SRTP активизируется
при помощи параметров конфигурации клиента (см. раздел Error! Reference source not
found.).
FR.56. Однако не все конечные пользовательские клиенты могут поддерживать SRTP. Поэтому
сетевое оборудование поставщика услуг должно поддерживать режим e2ae. Клиент RCS,
поддерживающий SRTP и SDES, также должен поддерживать режим e2ae.
FR.57. При использовании SRTP/SDES, клиент RCS может включать предпочтения для
использования режима обеспечения безопасности в соответствии с документом Error!
Reference source not found.. Режим e2ae рекомендуется использовать на UE, если также
указывается, что его поддерживает P-CSCF. В противном случае, клиент RCS может
попытаться использовать режим e2e, не указывая никаких предпочтений во время
установления сеанса. Обратите внимание на то, что не исключает возможности того, что
сеть поставщика услуг по-прежнему может решить ограничить обеспечение
безопасности среды в сети (P-CSCF).
FR.58. Для завершения сеанса, P-CSCF (IMS ALG), если он поддерживает режим SRTP / SDES e2ae,
принимает решение на основе локальной политики, применять или нет SRTP / SDES в
отношении UE.
MSRP / MSRP
FR.59. MSRP используется во многих службах RCS, которые связаны с обменом изображений,
файлов и мгновенными сообщениями (например, на основе сеанса). Подобно RTP, MSRP
устанавливает связь посредством обменов SDP в сигнализации SIP и он во многом
полагается на безопасность, предусмотренную в сигнализации. Использование
криптографически стойких случайных значений, добавляемым к идентификаторам URI
MSRP, обмен которых происходит в пределах SDP, обеспечивает связывание между
сеансами SIP и MSRP и любыми идентификаторами, обмен которых происходит в
пределах SIP.
FR.60. Режим TLS, как определено в документе Error! Reference source not found.,
рекомендуется использовать для RCS, если MSRP транспортируется по сомнительной
сети (например, Wi-Fi). Поэтому, в разделе Error! Reference source not found. определен
параметр конфигурации клиента, активизирующий Протокол ретрансляции сеанса
передачи сообщения через Протокол защиты транспортного уровня (MSRPoTLS).
Page 18 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
FR.61. Самоподписанные сертификаты TLS рекомендуется использовать для генерирования
контрольных сумм (например, защищенный хэш) сертификата, обмен которыми
происходит во время согласования SDP, связанного с приглашением и процедурой
установления связи MSRP. Контрольная сумма сертификата, используемая для MSRP
подчиняется тому же самому механизму использования контрольных сумм, какой
определен в документе Error! Reference source not found.. Такое связывание
контрольной суммы сертификата и сигнализации SIP основывается на лежащей в основе
безопасности и доверии, предоставляемых сигнализацией SIP (например, IPsec, SIPoTLS
(SIP через TLS) и т. д.). Как следствие, предполагается, что соединения MSRPoTLS
должны возникать только в сочетании с использованием шифруемой сигнализации SIP.
FR.62. При использовании MSRPoTLS, и при выполнении следующих двух задач:
FR.63. исключение сложного сквозного («от конца до конца») согласования, и
FR.64. обеспечение соответствия законным процедурам перехвата.
FR.65. Зашифрованное соединение MSRP должно прерываться в элементе сети поставщика
услуг, предоставляющего услугу для данного UE.
FR.66. Если для MSRP используется альтернативная модель соединения, как определено в
документе Error! Reference source not found. (см. раздел Error! Reference source not
found.), сеанс TLS для MSRP может быть инициирован любой конечной точкой MSRP
канала связи MSRP.
Page 19 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
Аутентификация и безопасность хранилища содержимого сообщений
FR.67. Клиент RCS должен поддерживать механизмы аутентификации и обеспечения
безопасности, описанные в документе Error! Reference source not found. для доступа к
Хранилищу содержимого сообщений с использованием IMAP.
FR.68. Аутентификация должна быть основана на имени пользователя и пароле, хранящихся в
клиенте RCS и одном из следующих методов аутентификации IMAP:
FR.69. Имя пользователя и пароль отправляются открытым текстом с использованием
команды LOGIN (РЕГИСТРАЦИЯ), как определено в документе Error! Reference source
not found.
FR.70. Механизм, основанный на Простом уровне аутентификации и безопасности (SASL) с
использованием команды AUTHENTICATE (АУТЕНТИФИКАЦИЯ), как определено в
документе Error! Reference source not found.
FR.71. Для аутентификации, основанной на SASL, должен использоваться “PLAIN” метод
аутентификации SASL, как определено в документах Error! Reference source not found.
и Error! Reference source not found.
Рисунок 2: Аутентификация IMAP с использованием SASL или логина открытым текстом
FR.72. TLS должен использоваться для обеспечения аутентификации сообщений, защита
передаваемой информации от изменения и конфиденциальности для протокола IMAP,
как определено в документе Error! Reference source not found.. TLS должен сначала
установить связь с использованием команды STARTTLS (ЗАПУСК TLS) прежде, чем будет
выполнена какая-либо основанная на IMAP аутентификация, с использованием либо
команды LOGIN, либо команды AUTHENTICATE
Сервер Хранилища содержимого сообщений должен аутентифицироваться по отношению к
клиенту RCS с использованием аутентификации, основанной на сертификате TLS.
Клиент должен поддерживать сертификаты, основанные на Инфраструктуре открытых
ключей (PKI), для которых клиент RCS предварительно конфигурируется с
Page 20 of 23
Версия 1.4
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Дата 04.06.2015
использованием корневого или промежуточного сертификата Органа сертификации
(рекомендуется, чтобы он был государственным корневым органом сертификации) в
цепочке подписания сертификата.
Конфиденциальность
Обзор
FR.73. Ключевым элементом стимулирования принятия пользователем RCS является
обретение пользователем доверия в отношении конфиденциальности. Поставщикам
услуг необходимо предусмотреть механизмы обеспечения безопасности, чтобы
нежелательные абоненты не смогли получить доступ к средствам связи пользователя
RCS и предусмотреть адекватные механизмы, позволяющие пользователям
контролировать информацию, которой они обмениваются.
Конфиденциальность информации о присутствии
FR.74. Пользователь RCS должен иметь возможность контроля того, с кем они обмениваются
информацией о присутствии, посредством процесса принятия, блокировки или
игнорирования приглашения установить взаимоотношения о присутствии.
Конфиденциальность видео
FR.75. Клиент RCS должен предоставлять пользователю RCS контроль, когда активна любая
камера на устройстве.
Конфиденциальность информации о социальном присутствии
FR.76. Пользователь RCS должен иметь возможность отключения обмена информацией о
социальном присутствии.
Конфиденциальность сетевой адресной книги
FR.77. Поставщик услуг должен обеспечить контроль за доступом к Сетевой адресной книге
посредством процесса аутентификация.
Конфиденциальность местоположения
FR.78. Пользователь RCS
местоположении.
должен
иметь
возможность
контроля
информации
о
Обмен сообщениями и чат
FR.79. Пользователи RCS должны иметь возможность контроля сообщаемой информации о
своих действиях во время обмена сообщениями и сеансов чата, включая блокировку
уведомлений “display” («отображение») и “IsComposing” («Составляется»).
Требования к схемам
FR.80. Схемы должны быть предоставлены в формате Microsoft Visio.
Требования к документации
FR.81. Минимальный набор необходимой документации должен включать:
FR.82. общее описание каждого приложения;
FR.83. описание логики и протокольных последовательностей предоставления сервисов
(use-cases);
Page 21 of 23
Версия 1.4
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Дата 04.06.2015
FR.84. общую схему организации связи (функциональную схему);
FR.85. справочное руководство по каждому приложению;
FR.86. схему организации взаимодействия с внешними программно-аппаратными
комплексами Компании (SDP, ИБС, SMSC и т. д.);
FR.87. руководство администратора;
FR.88. инструкцию по поиску и устранению неисправностей;
FR.89. описание provisioning-интерфейса;
FR.90. описание методов сбора и анализа статистической информации;
FR.91. документацию с детальным описанием конфигурационных и журнальных
файлов.
FR.92. Для передачи в эксплуатацию, должна быть предоставлена программа и методика
испытаний, которая должна быть согласована с МГТС.
FR.93. Документация должна передаваться на компакт-диске или flash-карте в двух
экземплярах.
СОРМ
FR.94. Обеспечение требований СОРМ для всех услуг, реализованных на Системе, включая
голосовые вызовы, видеовызовы, мультимедийные и сетевые сервисы.
FR.95. МП, Web-приложение и PC-приложение должно иметь возможность административного
запрета прямой передачи информации между клиентами (передача файлов, IM, SMS,
голос, видео и т.п.). Любой обмен информацией между клиентами должен
проксироваться через IMS-ядро.
Требования к управлению проектом со стороны участника
FR.96. Со стороны участника запроса должен быть выделенный менеджер проекта с опытом
внедрения как минимум одного проекта в данной области, специалисты по предметным
блокам и технические специалисты.
Лицензионная информация
FR.97. Исполнитель обязан предоставить полную информацию о стоимости лицензий на
программное обеспечение от сторонних поставщиков в зависимости от их типов и
количества и стоимости расширении на каждый этап.
FR.98. Лицензируются активные пользователи услуг, активным пользователем считается
абонент, использовавший приложение за последние 30 дней.
Требования по защите инвестиций
FR.99. В течение первых пяти лет после коммерческого запуска не должна требоваться
модификация аппаратных элементов системы. Поддержка дополнительного
функционала в обозначенный период должна быть реализована путем обновления
программного обеспечения.
FR.100.
Необходимо предоставить Roadmap оборудования на 5 лет, с указанием дат
окончания продаж оборудования и его технической поддержки.
Page 22 of 23
Запрос информации по проекту внедрения услуги
«Rich Communication Suite»
Версия 1.4
Дата 04.06.2015
FR.101.
Все поставляемые аппаратные платформы должны поддерживаться в течении
минимум 5 лет с момента доступности коммерческого релиза. Термин
«поддерживаться» подразумевает:
FR.102.
доступность элементов оборудования для ремонта и расширения;
FR.103.
доступность сервисного обслуживания аппаратной части;
FR.104.
доступность сервисного обслуживания программного обеспечения;
FR.105.
возможность выполнения запросов на доработку программного обеспечения;
FR.106.
в случае невозможности обновления программного обеспечения ввиду
ограничений со стороны аппаратной части, данный факт должен быть
задокументирован в явном виде и передан за 6 месяцев до выхода коммерческого
релиза.
Требования
по
оборудования
гарантийному
и
техническому
обслуживанию
FR.107.
Участник должен оказывать услуги технической поддержки в гарантийный
период.
FR.108.
Предложение по технической поддержке в гарантийный период должно
охватывать все предлагаемое оборудование, а также все системы управления и
программного обеспечения.
FR.109.
Срок гарантийных обязательств участника будет исчисляться с даты подписания
Акта приемки поставляемого оборудования. Срок гарантии на поставляемое
оборудование должен составлять не менее 48 месяцев.
FR.110.
Участником должно быть предусмотрено бесплатное обучение персонала работе
с оборудованием, управлению и конфигурацией оборудования (не менее 8 человек).
Page 23 of 23