В марте 2026 года GSMA объявила о финализации спецификации RCS Universal Profile 4.0. Появилась функция Messaging-Initiated Video Calls (MIVC): из обычного чата 1-на-1 или группового RCS-диалога пользователь может поднять видеозвонок, а опоздавшие участники — присоединиться к уже идущему разговору с синхронизацией логов в таймлайне чата. Для выпускника ИТ-специальности это готовый полигон для ВКР: здесь одновременно живут протоколы сигнализации, вопросы совместимости Apple и Google, метрики качества связи и требования регуляторов. Разберём, как превратить этот тренд в защищаемую работу, а не в реферат из новостей.
В первую очередь направлениям «Информационные системы и технологии», «Программная инженерия», «Инфокоммуникационные технологии». Если вы специализируетесь на backend, системном анализе или сетевых протоколах — тема ложится напрямую. Для ML/Data Engineering она слабее, но можно взять смежный аспект: анализ качества видеопотока или прогнозирование QoS по телеметрии.
Да. Ниже разберу, где брать трассы, как поднять стенд и какие метрики считать. Всё воспроизводимо на одной-двух виртуалках или на локальном Docker-стенде.
Нет. В большинстве вузов достаточно прототипа сигнального слоя и эмуляции медиапотока. Но если хотите «пятёрку» — доведите до рабочего демо с двумя разными реализациями (условно «Apple-стек» и «Google-стек»).
Зафиксировать на первой встрече: формат стенда (эмуляция/реальные устройства), набор метрик (MOS, jitter, latency), и будет ли считаться экономический эффект. Это сэкономит месяцы переделок.
Актуальность: GSMA описывает MIVC как нативный мост между экосистемами Apple и Google. Проблема интероперабельности — живая боль индустрии.
Цель: спроектировать и реализовать подсистему сигнализации для升级 RCS-чата в видеозвонок с поддержкой позднего присоединения.
Задачи: анализ спецификации UP 4.0; построение C4-диаграмм; реализация state-машины сессии; интеграционные тесты двух клиентов.
Структура: Гл.1 — обзор RCS, IMS, WebRTC, обзор UP 4.0; Гл.2 — проектирование архитектуры и реализация прототипа; Гл.3 — тестирование, метрики QoS, оценка по ISO/IEC 25010.
Актуальность: MIVC обещает «непрерывность разговора» — значит, появляется класс задач по измерению QoE при переключении чат→звонок.
Цель: разработать методику измерения и визуализации метрик видеозвонка в RCS-контуре.
Задачи: выбор метрик (MOS, R-factor, jitter, packet loss); настройка сбора через OpenTelemetry; построение дашборда; сравнение сценариев 1-на-1 и группового.
Структура: Гл.1 — теория QoS/QoE, обзор ITU-T G.107; Гл.2 — архитектура сборщика метрик и прототип; Гл.3 — эксперименты, статистика, выводы.
Актуальность: перевод чата в видеозвонок расширяет поверхность атаки: перехват сигнализации, подмена идентификатора участника, spoofing логов.
Цель: провести threat modeling по OWASP и предложить защитные механизмы для RCS-звонков.
Задачи: моделирование угроз; реализация E2EE-обвязки для сигнализации; пентест прототипа; отчёт по ISO/IEC 25010 (security-характеристика).
Структура: Гл.1 — обзор угроз телеком-мессенджеров; Гл.2 — проектирование защищённого обмена сигнальными сообщениями; Гл.3 — проверка атак и результаты.
Не пересказывайте пресс-релиз GSMA — это сразу видно. Постройте схему стека: приложение → RCS-клиент → IMS → транспорт. Отметьте, где именно живёт MIVC и почему без Universal Profile он не заработает между разными вендорами. Здесь уместна C4-диаграмма уровня Context и Container — её легко защитить, потому что она отражает, что вы понимаете границы системы.
# Пример описания контейнеров в формате C4 (псевдо-YAML)
system: RCS Interop Video
containers:
- name: RcsClientApple
tech: iOS / RCS stack
responsibilities: [Signaling, MediaCapture, TimelineSync]
- name: RcsClientAndroid
tech: Android / Google Messages
responsibilities: [Signaling, MediaCapture, TimelineSync]
- name: MivcSignalingGateway
tech: Node.js + SIP over WebSocket
responsibilities: [SessionState, LateJoin, LogSync]
Ключевое место работы. MIVC — это конечный автомат: IDLE → INVITED → CONNECTING → ACTIVE → PAUSED → CLOSED. Позднее присоединение добавляет переход ACTIVE → JOIN_LATE без потери контекста. Нарисуйте UML State Diagram, затем отразите её в коде.
# Псевдокод состояния сессии
class MivcSession:
states = ["IDLE", "INVITED", "CONNECTING", "ACTIVE", "PAUSED", "CLOSED"]
def transition(self, event):
if self.state == "ACTIVE" and event == "late_join":
self.sync_timeline_logs()
self.add_participant(event.user)
return "ACTIVE"
if self.state == "ACTIVE" and event == "hangup":
return "CLOSED"
raise InvalidTransition(self.state, event)
Здесь вы доказываете, что прототип не игрушка. Соберите метрики через OpenTelemetry: время установления соединения, задержку late-join, потери пакетов, джиттер. Сведите в таблицу сравнение «чат без MIVC» и «чат с MIVC» — это и есть ваша практическая новизна.
| Метрика | Единица | Сценарий A (без MIVC) | Сценарий B (MIVC) |
|---|---|---|---|
| Время установления видеозвонка | мс | — | 820 |
| Задержка late-join | мс | — | 150 |
| Jitter | мс | — | 12 |
| Packet loss | % | — | 0.4 |
| MOS (оценка) | 1–5 | — | 4.2 |
1. Пересказ статьи вместо анализа. Статья The Verge — это новость, а не научный источник. Разбирайте первоисточник — спецификацию GSMA UP 4.0. Иначе научный руководитель увидит компиляцию и снизит балл.
2. Отсутствие работающего прототипа. На защите часто спрашивают: «Что у вас работает?» Реферат про интероперабельность без строчки кода — гарантированное «удовлетворительно». Поднимайте даже минимальный стенд на двух клиентах.
3. Метрики «на глаз». Фраза «стало быстрее» не работает. Нужны числа: 820 мс против бенчмарка, jitter 12 мс при допустимых 30. Опирайтесь на ISO/IEC 25010 performance efficiency.
Источник: A new RCS update could connect iPhone and Android video calls, someday (опубликовано 2026-03-30)
```