Комплексные неполадки при трансляции

[Pavel P.]

День добрый.
Сегодня столкнулись с довольно крупной проблемой. Был демо-показ, во время которого проявлялись сразу несколько проблем:

• у пользователей, подписанных на потоки сильно тормозило видео;
• наблюдалась рассинхронизация видео и аудио;
• на плеере у пользователей неравномерно шел таймер трансляции (фризился на несколько секунд).

Не подскажете, в чём может заключаться проблема?
Сессия проводилась в районе 11:00 - 11:20 по Мск. Отчёт прикрепляю дополнительно через соответствующую форму.

 

[Max]

Здравствуйте.

Судя по отчетам и IP адресам в конфиге, серверы находятся в Калифорнии.
Т.к. указываете московское время, то можно предположить, что тестирование (подача стримов и их воспроизведение) осуществлялось из Москвы. Если так, то это очевидная проблема, т.к. обычно пинг и канал до сильно удаленных серверов оставляет желать лучшего.

Рекомендуем перенести серверы в тот регион, в котором планируются пользователи сервиса.

 

[Pavel P.]

Приветствую.

Это довольно странно, потому что наша инфраструктура располагается в AWS, регион eu-central-1 (Frankfurt). Потому возможность наличия IP из Калифорнии довольно сомнительная. А в какой конкретной части отчёта вы наблюдаете этот адрес? Все адреса, что я встречал в логах или из Германии, или из России.

Передаю вам через форму отчёта ещё данные мониторинга в период происшествия. Возможно это поможет в процессе анализа ситуации и локализации проблемы.

 

[Max]

По графикам видно, что в потоке 7400bMcaZPeVf4vb6bC, который был обозначен, как проблемный, в 15:15 по меткам на графиках была просадка по всем основным метрикам в течение 15 секунд. Это выходной поток микшера. При этом просадка по времени совпадает с просадкой метрик VIDEO_FPS. VIDEO_GOP_SIZE, VIDEO_K_FRAMES, VIDEO_RATE единственного входящего потока этого микшера.
Это выглядит как проблема с каналом между публикующим клиентом и сервером, о чем мы и писали Выше (и в других Ваших темах). Рекомендации остаются прежними: переместить Origin ближе к публикующим клиентам, либо снизить разрешение и битрейт публикации. TCP транспорт Вы уже используете, судя по отчету.
Также обращаем Ваше внимание, что проблемы могут быть и у зрителей: выходной поток микшера 1080p с высоким битрейтом может не укладываться в канал зрителя, в этом случае у зрителя будет тот же комплект симптомов, который вы перечислили.

 

[Pavel P.]

15:15 - это ошибка? Логи и данные мониторинга в пределах ~ 10 - 12 часов. Имелось в виду 11:15?

Во время этой трансляции, ближе к концу, была пауза в сессии, вероятно описанная вами просадка ей и является. Могу я запросить ориентир в логах, где наблюдается данная ситуация?

Проблемы, в свою очередь, наблюдались на протяжении всей трансляции и касались всех зрителей. При этом тестовый прогон за день до, с тем же расположением серверов и параметрами потока полностью удовлетворял заданные требования. Как и последующее тестирование с надеждой определить причину. Так же на мониторинге не наблюдаются проблемы с сетью. Просадка происходит только в паузу, что закономерно.

Может есть ещё какие-то предположения по возможным причинам подобного поведения или факторы, которые могут его вызывать?

 

[Max]

15:15 - это ошибка? Логи и данные мониторинга в пределах ~ 10 - 12 часов. Имелось в виду 11:15?
Во время этой трансляции, ближе к концу, была пауза в сессии, вероятно описанная вами просадка ей и является. Могу я запросить ориентир в логах, где наблюдается данная ситуация?

Вероятно, снапшот отображает время в том часовом поясе, где его просматривают (в данном случае из GMT+7)

Время в логах в этом случае будет 8:15
По логам origin сервера видно, что в 8:18 поток, который заходил в микшер, был остановлен, и в 8:19 опубликован заново. По Вашему flow, в происходит попытка создать микшер заново с тем же именем, что и видно далее в логах:

08:19:03,182 ERROR ixerStreamController - HTTPS-pool-5-thread-1 startup exception localStreamName '7400bMcaZPeVf4vb6bC' already exists

Ранее Вам уже неоднократно рекомендовалось проверять, существует ли микшер, перед его созданием, для этого есть запрос /mixer/find_all

Проблемы, в свою очередь, наблюдались на протяжении всей трансляции и касались всех зрителей. При этом тестовый прогон за день до, с тем же расположением серверов и параметрами потока полностью удовлетворял заданные требования. Как и последующее тестирование с надеждой определить причину

Вероятно, условия тестового прогона отличались. Например, во время трансляции публикующий клиент или зрители использовали мобильную сеть, а во время тестового прогона - WiFi или проводное подключение. Данные мониторинга содержат только замеры на стороне сервера, поэтому по предоставленным данным невозможно сделать вывод о качестве канала между зрителем и сервером.
Общие рекомендации будут следующими:
1. Для клиентов в РФ использовать серверы в датацентрах на территории РФ.
2. Во всех случаях желательно использовать серверы ближе к клиентам.
3. По настройкам видно, что отправка битрейта на клиента для контроля качества канала у Вас включена только на origin сервере, т.е. проверяется только качество канала публикации. Учитывая, что зрителям раздается выходной поток микшера с параметрами, согласно настройке микшера, 1080p 4500 kbps, необходимо контролировать качество канала и на стороне зрителей тоже, т.е. на edge сервере.
Также отметим, что настройки

webrtc_cc_max_bitrate=500000
webrtc_cc_min_bitrate=30000

влияют только на публикацию, зрителю поток будет отдан с тем битрейтом и разрешением, с которым его опубликовали. Поэтому на edge сервере они неэффективны, их нужно убрать.
4. На origin сервере у вас подписчиков немного, т.к. зрители подключаются к edge серверу. В связи с этим, рекомендуем отключить на origin сервере многопоточную доставку

streaming_distributor_subgroup_enabled=false

При этом на edge сервере этот параметр лучше оставить в true
5. Если каналы клиентов не дают доставить им 1080p поток с битрейтом 4500 kbps, рекомендуем снизить выходной битрейт микшера

mixer_video_bitrate_kbps=2000

Если это не подходит, рекомендуем рассмотреть транскодирование потока на выделенном сервере в CDN по профилям. В этом случае можно будет при снижении качества канала переключать зрителя на поток с меньшими параметрами (например, 360p 500 kbps)

 

[Pavel P.]

Снова здравствуйте.

Нам наконец-то удалось воспроизвести проблему снова и собрать больше диагностических данных, в том числе дамп трафика во время неполадок. Трансляция началась 01.06 около 09:05 (время сервера и логов, соответственно), и длилась около часа. Проблемы сохранялись на протяжении всей сессии.

Несколько слов по поводу рекомендаций из прошлого вашего ответа. На текущий момент было возможно выполнить только 3 и 4 пункт. Однако после их применения поведение трансляции резко ухудшилось. Возможно это совпадение, но возникла необходимость убедиться в этом. Потому на момент снятия данных, о которых идёт речь, их снова откатили. Из-за сложности воспроизведения и необходимости вводить данные настройки поэтапно, для локализации проявившихся проблем, предоставляем на этот момент доступные диагностические данные.

 

[Max]

По предоставленным логам, поток, который Вы указали как проблемный 7440srrvxJTMsFn6jEZ, был опубликован на Origin в 09:02:14,686, при этом websocket соединение было установлено в 09:02:13,303, событие publishStream было получено от клиента в 09:02:14,669

Затем в 09:02:18,291 поток 7440srrvxJTMsFn6jEZ был успешно добавлен в микшер 7440fpBzcwFrp3E7Oev

В клиентском логе потока видно, что ключевые фреймы приходят неравномерно и с большим интервалом, например, здесь интервал составил более минуты:

После этого в 09:05:10,158 публикация потока 7440srrvxJTMsFn6jEZ была остановлена на стороне клиента

Websocket сессия была закрыта клиентом в 09:05:10,170

В 09:05:10,914 поток был удален из микшера

В 09:05:11,248 микшер 7440fpBzcwFrp3E7Oev был остановлен

После этого поток 7440srrvxJTMsFn6jEZ (и любой другой поток с именем, начинающимся с 7440) не публиковался.
Однако, далее в 09:10:06,489 был опубликован поток 7441nVhb3z6tSAK85St с того же IP адреса клиента и был добавлен в микшер 7441zPpqreBm8MoHZtJ. Публикация этого потока продолжалась до 09:48:53,839, была остановлена без закрытия websocket соединения, затем возобновлена в 09:48:56,919 и окончательно остановлена с закрытием websocket соединения в 09:48:58,988. По логу этой сессии для того же самого клиента снова видна неравномерность и большой интервал получения ключевых кадров

Также однократно зафиксирована ошибка при разборе полученного пакета данных

09:20:37,683 ERROR       VideoProcessor - VideoProcessor-7441nVhb3z6tSAK85St-a01eeb00-e18a-11ec-9a1c-39f68ca7c06a processor stopped, reason: 
java.lang.IndexOutOfBoundsException

Это говорит о том, что пакет с медиаданными был поврежден.
Неравномерность прихода ключевых кадров и повреждения пакетов с медиаданными сигнализируют о проблемах с каналом данного клиента. Кроме того, это может приводить к фризам у зрителя.
В настройках Origin сервера у вас отключен периодический запрос ключевых кадров. Рекомендуем его включить

periodic_fir_request=true

В этом случае ключевые кадры буду запрашиваться у клиента каждые 5 секунд, это должно помочь с фризами. Однако, если канал клиента плохой, рекомендуем контролировать качество канала и перепубликовывать поток с меньшим разрешением/битрейтом.
Предоставленные дампы трафика бесполезны, поскольку у Вас используется TCP транспорт, и разбор пакетов невозможен. Кроме того, трафик на Origin сервере снят до начала трансляции, и проблемную трансляцию он не содержит, поэтому даже количество перепосылок TCP пакетов (retransmit) оценить не представляется возможным.
Больше информации могли бы дать дебаговые логи, но их нет.
Что касается возможных проблем у зрителей, рапорты с Edge серверов не содержат клиентских логов вообще, поэтому диагностировать возможные проблемы невозможно. По зрителям рекомендации остаются прежними (п. 5)

 

[Max]

Также просим уточнить, как играет поток участника в момент, когда проблема воспроизводится, если играть его непосредственно с Origin сервера? Как играет поток микшера непосредственно с Origin сервера? Если поток участника играет плохо с Origin сервера, это также может показывать проблему с входящим потоком.

 

[Pavel P.]

Удалось локализовать причину неполадок после применения некоторых из рекомендаций. Отключение на origin сервере многопоточной доставки (п. 4) вызывает резкое ухудшение картинки, проявление графических артефактов. В связи с чем удалось полноценно применить только рекомендацию из п. 3, в свежем воспроизведении проблемы эти параметры уже фигурируют.

Дампы трафика снимались ближе к концу трансляции, потому странно, что они не содержат данные о проблемном потоке. Но раз это всё равно невозможно полноценно анализировать, отправка этих данных не имеет особого смысла.

Что имеется в виду под дебаговыми логами и как их можно включить/получить? Почему рапорты с Edge могут не содержат клиентских логов, в чём возможная проблема и как это можно исправить? "client_log_level=DEBUG" и подключение контроля качества канала никак на это не повлияли.

На текущий момент складывается чёткое понимание, что проблема заключается в одном из edge. Так как подписка с одного из edg'ей работает стабильно, а при переключении на другой начинаются проблемы в микшированном потоке у всех участников. Жалоб, связанных с воспроизведением с origin не наблюдается.

 

[Max]

Есть два типа логов на стороне сервера.
- глобальные (логгируют события сервера без привязки к конкретной сессии)
- клиентские (или Extended, логируют события, привязанные к конкретной сессии)

Extended-логи могут быть включены для всех сессий, с помощью настроек:

enable_extended_logging=true
client_log_level=DEBUG

Extended-логи могут быть включены/отключены для конкретной сессии с использованием REST API

/logger/enable_client_log
/logger/disable_client_log

Если у вас хорошо воспроизводится проблема на конкретном стриме, в идеале, нужно собрать логи конкретной сессии (sessionId).

1. Например, на Origin-сервере работает микшер, который здесь же на Origin сервере создает стрим, например stream1-mixer, который будет иметь статус PUBLISHING. У этого стрима будет уникальный sessionId. Для того, чтобы найти sessionId стрима, надо выполнить два запроса:
/rest-api/stream/find_all
/rest-api/connection/find_all
Имея sessionId стрима микшера, можно включить для этого стрима дебаг-логи, используя запрос: /logger/enable_client_log

2. Допустим, этот стрим stream1-mixer забирает Edge-сервер. В этом случае, на Origin сервере будет стрим со статусом PLAYING и у этого стрима будет sessionId, который содержит IP адрес Edge - сервера. Таким образом мы знаем sessionId, по которому можно включить дебаг логи стрима, который уходит с Origin на конкретный Edge.

3. И наконец на Edge сервере, мы увидим стрим с именем stream1-mixer, который будет иметь статус PUBLISHING и по sessionId этого стрима можно включить дебаг.

Т.е. можно ответить на вопросы:
1. Как стрим заходит с микшера на Origin.
2. Как стрим уходит с Origin на Edge.
3. Как стрим приходит на Edge.

Если нагрузка небольшая и диска и памяти достаточно, то логи можно включить сразу для всех сессий:

enable_extended_logging=true
client_log_level=DEBUG

Это даст доп. нагрузку на сервер.

Если вы используете SRT-протокол между Origin и Edge, попробуйте переключить на UDP или TCP
Т.к. если действительно все так, как вы говорите, и с одного Edge стрим играет, а с другого проблемы, то может помочь откат к более проверенным протоколам.

cdn_transport=udp
или
cdn_transport=tcp

 

[Max]

В последнем предоставленном Вами рапорте на поток, указанный, как проблемный 7446jg7PQNcq9PddKG4, успел подписаться только один edge edge1, причем логи с него относятся к более раннему времени (7:00-7:59, а проблемный поток публиковался в 8:32-8:43 по времени из логов origin).
Поэтому все, что видно из предоставленных логов - это относительно большие скачки временных меток для последовательных кадров (до 80 мс, в предыдущих логах наблюдалось и до 150 мс), полученных сервером от клиента, а также нерегулярное и редкое поступление ключевых кадров. В связи с этим повторно рекомендуем включить на origin периодический запрос ключевых кадров

periodic_fir_request=true

В связи с чем удалось полноценно применить только рекомендацию из п. 3, в свежем воспроизведении проблемы эти параметры уже фигурируют.

Настройки, рекомендованные в п.3, никак не влияют на публикацию или проигрывание, они служат только для проверки качества канала в реальном времени в ходе трансляции.
Уточните, пожалуйста, как Вы используете контроль качества канала на origin и на edge? Какое качество фиксируется на стороне публикующего клиента (для origin) и играющего клиента (для edge): PERFECT, GOOD, BAD? Как именно качество коррелирует с проблемами?

Так как подписка с одного из edg'ей работает стабильно, а при переключении на другой начинаются проблемы в микшированном потоке у всех участников.

По логам, в микшере всегда только один входящий поток. Уточните, пожалуйста, наблюдаются ли проблемы при проигрывании с edge оригинального потока (не потока микшера)? Также уточните, правильно ли мы понимаем последовательность воспроизведения проблемы:
- подписчик подключается к edge1, поток играет хорошо
- подписчик отключается от edge1 и подключается к edge2, поток играет плохо
- подписчик отключается от edge2 и подключается к edge1, поток играет хорошо

 

[Pavel P.]

Приветствую снова.

Проблему удалось воспроизвести снова с новыми расширенными параметрами логирования. Новые отчёты прикрепляю в форму репорта. В данном промежутке была только одна трансляция (с 07:01 по 07:26).

Логов с воспроизведением на другом протоколе транспорта в данный момент нет. Но во время первого инцидента мы меняли SRT на TCP и на наблюдаемых неполадках это никак не сказывалось.

С подключением периодического запроса ключевых кадров для origin возникали проблемы в прошлом. После вашей рекомендации, данная настройка снова включена но для тестовой среды. Если не возникнут проблемы снова, со временем она появится на актуальном для этого обсуждения. Но на данный момент результаты с ней продемонстрировать не можем.

Контроль качества использовался только на origin до этого. С данной проблемой корреляции качества публикуемого потока замечено не было. Но и сами неполадки, судя по всему, origin не затрагивают. На данный момент настройка включена так же и для edge, но данных по корреляции ещё нет. Если только что-то попадает в отчёт.

Да, алгоритм воспроизведения проблемы правильный. Возможны незначительные изменения вариаций:
- попадание сразу на проблемный edge, плохое воспроизведение, переключение на другой edge, нормальное воспроизведение
- попадание на проблемный edge, переключение на нормальный, возвращение на проблемный

Эксперимент с проигрыванием оригинального потока с edge не проводили. Затрудняюсь ответить по поводу возможности на данный момент.

 

[Max]

Проблему удалось воспроизвести снова с новыми расширенными параметрами логирования. Новые отчёты прикрепляю в форму репорта. В данном промежутке была только одна трансляция (с 07:01 по 07:26).

По логам, видим проблемы с исходным потоком (публикация на origin):
- периодические задержки при обработке входящих пакетов (от 1.5 до 5 секунд);
- ближе к середине сессии резкий скачок последовательности порядковых номеров пакетов (sequence number), как будто был пропуск нескольких пакетов
Как правило, это свидетельствует о проблемах с каналом публикации, либо о проблемах с производительностью клиента (браузера). Например, если Вы публикуете изображение с канваса, и поверх вкладки браузера открывается другое окно (даже не в полный экран), могут быть и задержки отправки данных, и пропуски пакетов.

Если только что-то попадает в отчёт.

В логи на стороне сервера замеры качества не попадают, т.к. вычисления производятся на стороне клиента. Поэтому мы и уточняем: какие именно показатели качества на клиенте отображаются при возникновении проблемы?

Да, алгоритм воспроизведения проблемы правильный. Возможны незначительные изменения вариаций:
- попадание сразу на проблемный edge, плохое воспроизведение, переключение на другой edge, нормальное воспроизведение
- попадание на проблемный edge, переключение на нормальный, возвращение на проблемный

Проблема воспроизводится только на одном из edge серверов, и всегда только на нем?
Если играть поток только с одного edge сервера, никогда не переключаясь на второй, проблема не воспроизводится?

 

[Pavel P.]

Могут ли проблемы заключаться именно в публикации, если неполадки наблюдаются сразу со всеми публикующими? То есть в микшированном потоке падение частоты кадров, торможение и рассинхронизация возникает сразу по всем публикующим пользователям. К тому же, на втором edge в этот момент сохраняется нормальное качество трансляции. И при многократных переходах слушателя между edg'ами получается то нормальная трансляция, то проблемная.

С канвасом была отдельная история до этого, действительно было замечено, что он вызывает периодические падения производительности. Но на данный момент он отключён и текущие трансляции проходят без него.

Не совсем понимаю ситуацию с показателями качества. Данные параметры вычисляются где-то на стороне WCS и как-то представлены в самом flashphoner? Можем ли мы их зафиксировать и передать вам? Или это вопрос конкретно к реализации в нашем приложении и вас интересует наличие и реализация механизма/критериев оценки качества трансляции?

Инстансы edge несколько раз пересоздавались, но из одного и того же образа. С последующим применением файлов конфигурации, одинаковых на момент применения для обоих экземпляров edge. С последнего пересоздания инстансов, проблема наблюдалась только один раз, потому сложно точно сказать, меняется ли сейчас проблемный edge. Но на прошлых стабильно наблюдалась на конкретном из экземпляров.

Ситуации воспроизведения проблемы при единичном edge тоже наблюдались. Как минимум, во время первого инцидента и попыток как-то исправить ситуацию. Так же как и воспроизводилась проблема, если не переключаться никогда, но посчастливилось изначально попасть на проблемный инстанс.

 

[Max]

Могут ли проблемы заключаться именно в публикации, если неполадки наблюдаются сразу со всеми публикующими? То есть в микшированном потоке падение частоты кадров, торможение и рассинхронизация возникает сразу по всем публикующим пользователям.

Наблюдение проблем микшированного потока не говорит о наличии проблем на Всех публикующих.
Чтобы подтвердить проблему на каждом из публикующих, надо проиграть каждый публикующий поток по отдельности напрямую с Origin.
И если выяснится, что каждый кормящий микшер поток играет корректно, а результат микширования некорректно, значит проблема где-то либо в микшере либо за ним.

Наш анализ логов лишь показывает, что были проблемы и просадки на одном из публикующих потоков на входе в Origin.

тому же, на втором edge в этот момент сохраняется нормальное качество трансляции. И при многократных переходах слушателя между edg'ами получается то нормальная трансляция, то проблемная.

Это либо сетевая задержка TCP и проблемный контент просто не успел дойти до второго Edge.
Либо можете попробовать уменьшить размер группы на Origin:

streaming_distributor_subgroup_size=5
streaming_distributor_subgroup_size=10

или

streaming_distributor_subgroup_size=1
streaming_distributor_subgroup_size=2

или же

streaming_distributor_subgroup_size=1
streaming_distributor_subgroup_size=1

Документация здесь

Если вы используете Amazon EC2, виртуального процессора VCPU может теоретически не хватать для рассылки стрима по Edge-серверам, одновременно с работой микшера. Это может давать подобные эффекты, когда один Edge получил стрим хорошо, а второй плохо.

Также можно в реальном времени понаблюдать htop
Если загрузка по отдельным ядрам достигает 90-100% время от времени, это может говорить о том, что CPU не справляется с своевременной отправкой пакетов, несмотря на то, что по другим ядрам он может быть загружен минимально и общая загрузка может быть невысокой.

Для исключения проблемы производительности, вы могли бы развернуть микширующий Origin на железном двухпроцессорном сервере, таком как equinix metal, selectel или hetzner.

 

[Max]

Не совсем понимаю ситуацию с показателями качества. Данные параметры вычисляются где-то на стороне WCS и как-то представлены в самом flashphoner? Можем ли мы их зафиксировать и передать вам? Или это вопрос конкретно к реализации в нашем приложении и вас интересует наличие и реализация механизма/критериев оценки качества трансляции?

Контроль качества канала при публикации и воспроизведении - Web Call Server 5.2 - RU - Flashphoner Documentation

docs.flashphoner.com

WCS сервер присылает данные по битрейту. На основе этих данных приложение (Web SDK) строит графики. На основании расхождения в этих двух графиках, назначает оценку качества: BAD, GOOD, PERFECT. Вопрос в том, можете ли вы добавить эти графики в приложение и показать как выглядят графики публикующего во время обнаружения проблем на этом стриме. Либо предоставить нам только цифры битрейта Server bitrate Client bitrate для построения графиков вручную и оценки качества.

Смысл оценки следующий. Если приложение отправляет сильно больше данных чем реально принимает сервер, значит есть проблема. Величина отклонения этих двух битрейтов будет сигнализировать об интенсивности проблемы с качеством. Если графики в основном совпадают, то качество будет PERFECT, т.к. сервер получает стрим почти в том виде, в котором он был отправлен, что свидетельствует о хорошей пропускной способности сети и достаточной производительности сервера и клиента.

 

[Max]

Инстансы edge несколько раз пересоздавались, но из одного и того же образа. С последующим применением файлов конфигурации, одинаковых на момент применения для обоих экземпляров edge. С последнего пересоздания инстансов, проблема наблюдалась только один раз, потому сложно точно сказать, меняется ли сейчас проблемный edge. Но на прошлых стабильно наблюдалась на конкретном из экземпляров.

Пробовали отключить проткол SRT внутри CDN?
Или это поведение всегда воспроизводилось с SRT?

 

[Pavel P.]

К сожалению, в текущей реализации приложения у нас нет возможности воспроизвести потоки-составляющие микшера отдельно и напрямую.

Размер группы на Origin был сегодня уменьшен, но пока проблема снова не воспроизводится. По htop так же нет пока данных, по той же причине.

Реализовать графики на базе нашего приложения (если я вас правильно понял) так же является затруднительной задачей. Но мы бы могли снять и передать вам данные битрейта, если бы вы подробнее описали, где их можно найти и получить после включение данных опций в конфигурациях серверов. На данный момент нам не удалось обнаружить расположение этих данных. И в статье информации по этому поводу я тоже не вижу, к сожалению.

Вы же имеете в виду настройки cdn_transport на origin и edge? Об этом я и говорил, когда шла речь о переключении протокола передачи. Проблема воспроизводится как при TCP, так и на SRT. Или я не совсем понимаю, что вы имеете в виду.

 

[Max]

Реализовать графики на базе нашего приложения (если я вас правильно понял) так же является затруднительной задачей. Но мы бы могли снять и передать вам данные битрейта, если бы вы подробнее описали, где их можно найти и получить после включение данных опций в конфигурациях серверов.

Посмотрите, пожалуйста, пример в документации: Отображение качества канала на клиенте
Также смотрите исходный код примера Media Devices

Вы же имеете в виду настройки cdn_transport на origin и edge? Об этом я и говорил, когда шла речь о переключении протокола передачи. Проблема воспроизводится как при TCP, так и на SRT. Или я не совсем понимаю, что вы имеете в виду.

Если Ваши инстансы расположены в одном и том же регионе AWS, то транспорт можно использовать UDP (по умолчанию). Переключение на другие виды транспорта имеет смысл при нестабильном канале между серверами в CDN.