Я хочу создать аудио (mi c) и видео (камера) чат-комнату с 12 людьми, используя webRT C. Я понимаю сигнализацию и потребность во внешних сервисах, таких как ICE и STUN, чтобы помочь одноранговым узлам соединяться друг с другом.
Но я не хочу использовать полную архитектуру me sh, где все подключаются ко всем остальным, потому что это менее эффективен. Я не хочу пользоваться дорогими услугами ретрансляции TURN. Я хочу, чтобы рой автоматически распространял потоки, чтобы, если прямое соединение невозможно, сеть автоматически маршрутизировала пакеты потока через одноранговые узлы с использованием инкапсуляции.
Я не хочу использовать звездную архитектуру, потому что я не Мне не нужен узкий узел.
Я бы хотел, чтобы одноранговый узел подключался, возможно, к 2 или 3 другим одноранговым узлам (макс.) и транслировал свои мультимедийные данные по сети, не беспокоясь о ретрансляции между узлами. Маршрутизация, очевидно, должна контролироваться какой-либо службой, но я не вижу возможности выполнить инкапсуляцию потока с помощью RTCPeerConnection. Поскольку WebRT C допускает только объект RTCPeerConnection (от 1 однорангового узла к 1 одноранговому), одноранговому узлу необходимо различать guish, откуда приходит входящий поток и нужно ли его ретранслировать другому одноранговому узлу.
Существует ли технология, которая расширяет WebRT C, чтобы обеспечить эту архитектуру с более эффективным использованием полосы пропускания?