Статус WebRTC ICE и обработка номинаций

Все знают, что есть номинации на «Оскар». На самом деле, есть номинации в ICE of WebRTC. Существуют регулярные номинации и радикальные номинации, и выдвинутые кандидаты не обязательно являются лучшими кандидатами. Эта статья поможет вам исследовать тайну. Содержание статьи в основном описывает статус, связанный с ICE, и механизм номинации ICE в RFC 5245 , а также анализирует его в сочетании с версией libnice (0.14).

Автор: Диаграммы, Али
версия разработчика облачных сервисов : Тайский старший инженер по разработке облачных вычислений Али

Сцена

При анализе проблемы я столкнулся с таким сценарием: кандидат на сервере и три кандидата с разными приоритетами на клиенте, но в итоге была выбрана пара с самым низким приоритетом.

На сервере есть Relay Candidate, порт 50217.

a = кандидат: 3 1 udp 503316991 11.135.171.187 50217 тип реле raddr 10.101.107.25 rport 40821

У клиента есть три кандидата, порты 50218 (средний приоритет), 50219 (самый низкий приоритет) и 50220 (самый высокий приоритет).

Candidate 1:
candidate:592388294 1 udp 47563391 11.135.171.187 50219 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fO75 network-cost 50

Candidate 2:
candidate:592388294 1 udp 48562623 11.135.171.187 50218 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fO75 network-cost 50

Candidate 3:
candidate:592388294 1 udp 49562879 11.135.171.187 50220 typ relay raddr 0.0.0.0 rport 0 generation 0 ufrag fO75 network-cost 50

Но последний выбор - пара с самым низким приоритетом, 50219.

Remote selected pair: 1:1 592388294 UDP 11.135.171.187:50219 RELAYED

Кандидатский фонд

Фонд кандидата: Позвольте мне сначала упомянуть Фонд, который будет иметь статус замороженного.

Для одного и того же канала могут быть разные кандидаты. Например, при обнаружении Relay Candidate может быть сгенерирован новый кандидат Server Reflexive, но все они основаны на одном локальном адресе (IP, порт) и протоколе, тогда Можно считать, что эти сети похожи, и у них будет один и тот же фундамент. Среди них Foundation - это первое поле в SDP, которое в следующем примере равно «7».

a=candidate:7 1 udp 503316991 11.178.68.36 51571 typ relay raddr 30.40.198.7 rport 55896

Состояния ICE

ICE в основном имеет следующие пять состояний, из которых первые четыре являются нормальными состояниями, а пятое состояние Frozen включает алгоритм ICE Frozen .

Пять состояний ICE:

Ожидание: когда проверка подключения еще не началась (запрос привязки не был отправлен).
In Progress: Когда проверка подключения отправлена, но соответствующая транзакция проверки все еще выполняется (отправлен запрос привязки).
Успешно: проверка подключения завершена, и результат успешно возвращен (запрос привязки выполнен).
Сбой: проверка подключения была выполнена, результат не удалось (запрос привязки был выполнен).
Frozen :, все пары кандидатов находятся в этом состоянии после завершения инициализации. Для одного и того же Foundation (аналогичного кандидата) одна пара будет выбрана в соответствии с приоритетом, Unfreeze, и установлена в состояние ожидания, в то время как другие останутся Frozen. Пока выбранная пара не будет завершена, разморозить другую пару будет продолжено.

Номинация ICE

У ICE есть два метода номинации:

1.Обычная номинация

При обычной номинации основной рабочий процесс выглядит следующим образом:

L                        R
-                        -
STUN request ->             \  L's
<- STUN response  /  check

<- STUN request  \  R's
STUN response ->            /  check

STUN request + flag ->      \  L's
<- STUN response  /  check

Regular Nomination

Агент в режиме управления инициирует запрос привязки и получает ответ от противоположной стороны. В то же время завершается проверка подключения, инициированная противоположной стороной. Управляющая сторона снова отправит запрос привязки с битом флага USE_CANDIDATE. Когда управляемая сторона получит его, она примет назначение. .

2. Агрессивная номинация

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

L                        R
-                        -
STUN request + flag ->      \  L's

<- STUN response  /  check
<- STUN request  \  R's
STUN response ->            /  check

Figure 5: Aggressive Nomination

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

реальный сценарий:
Статус WebRTC ICE и обработка номинаций

Обновление состояний при выдвижении

Исходная ссылка

При создании новой номинации внутреннее состояние ICE будет соответственно изменено.

Когда в запросе на привязку на одном конце установлен флаг использования кандидата, будет сгенерирована номинация (номинация).

Независимо от того, находится ли агент в контролируемом или контролируемом режиме, рекомендуемые правила обновления статуса для обработки выдвижения следующие:

Если номинированной пары нет, продолжите процесс проверки подключения.
Если есть хотя бы одна действительная номинация:
- Агент должен удалить все пары Ожидание и Замороженные в Компоненте.
- Для пары в состоянии In Progress, если приоритет ниже, чем приоритет текущей назначенной пары, остановите повторную передачу (отмените).
Когда все Компонты определенного Стрима имеют хотя бы одну номинацию, а проверка еще продолжается:
- Агент должен отметить поток как завершенный.
- Агент может начать передачу медиапотока.
- Агент должен постоянно отвечать на полученные сообщения.
- Агент должен повторно передать пару, которая в настоящее время находится в состоянии «Выполняется» (приоритет выше, чем назначенный в настоящее время, в противном случае она была удалена или отменена).
Когда все пары в контрольном списке заполнены:
- ДВС в комплекте.
- Контролирующий агент обновляет предложение на основе приоритета (похоже, в WebRTC этого шага нет).
Если проверка контрольным списком не удалась:
- Когда все пары выйдут из строя, выключите ICE.
- Когда проверка определенного потока успешна, контролирующий агент удаляет неудачную пару и обновляет предложение.
- Если некоторые проверки не завершены, ICE продолжает работу.
Планирование проверок

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

Здесь обсуждается только Full, а упрощенный режим не описывается в первую очередь.

Проверки ICE делятся на два типа: обычные проверки и проверки с запуском.

Обычные проверки - это обычные проверки пар, что означает, что эти проверки пар являются проверками состояния, переключенными из обычного процесса.
Triggered Check - это пассивно инициируемая проверка. Хотя эти пары все еще находятся в состоянии, в котором они не могут быть проверены, они получают проверку подключения с противоположного конца. В это время пара будет ускорена и помещена непосредственно в список планирования.

Когда ICE составляет контрольный список (по одному для каждого потока), таймер будет добавлен в каждый контрольный список. Когда таймер прибудет, будет выполнено следующее планирование:

Примечание: здесь немного непонятно, весь процесс кажется последовательным, а скорость активации немного медленная.

Первое расписание Triggered Check и выполнение.
Если нет, отправьте пару состояний ожидания с наивысшим приоритетом, отправьте запрос и установите состояние In Progress.
Если нет, найдите в Контрольном списке пару замороженных состояний с наивысшим приоритетом, разблокируйте ее и отправьте запрос с состоянием «Выполняется».
Если нет, прекратите планирование.

Дело проанализировано

После краткого понимания процесса ICE мы вернемся к исходному кейсу.

Сначала посмотрите на Добавить кандидата. Три удаленных кандидата добавляются в другом порядке, за ними идут 50219, 50218 и 50220. Обратите внимание, что в это время 50219 получил запрос привязки с противоположной стороны, агрессивно назначен и передал USE_CANDIDATE, поэтому разрешение на создание будет выполнено и завершено в ближайшее время. Вы можете начать отправку запроса привязки, который относится к планированию приоритета инициируемых проверок, отправить запрос привязки и перейти в состояние «Выполняется».

Примечание. В дополнение к паре локальных реле существует также кандидат типа локального хоста, который взаимодействует с Turn.
Статус WebRTC ICE и обработка номинаций
Затем в 50219, когда два других разрешения на создание не были завершены, проверка была завершена быстро.Согласно описанию в rfc 8.1.2, все пары, которые не находятся в состоянии In Progress, удаляются, и их приоритет не упоминается. Таким образом, была окончательно выбрана пара с самым низким приоритетом 50219.
Статус WebRTC ICE и обработка номинаций

"Video Cloud Technology" Ваш самый заметный официальный аккаунт в области аудио- и видеотехники, еженедельно публикует практические технические статьи с переднего края Alibaba Cloud и обменивается идеями с первоклассными инженерами в области аудио и видео.