Есть ли какой-либо порядок событий обратного вызова состояния видеомонтажных мероприятий Twilio при прослушивании через веб-перехватчики?

Контекст:

Мы используем программируемое видео Twilio для нашего приложения на iOS, Android, WebBrowser. Существует веб-сервер Java, который использует веб-перехватчик для прослушивания всех событий.

Недавно мы начали внедрять приложение для Android. Для клиентов Android мы заметили, что событие, связанное с участником, иногда получается после добавления трека для участника на нашем сервере.

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

Что мы пробовали:

  1. Мы предоставили дорожку localVideo и localAudio в параметре подключения для подключения комнат с Android, что случайным образом вызывает эту проблему.
  2. Мы опубликовали треки с Android только после подключения комнаты (удалили трек localVideo и localAudio из параметра подключения, а в обратном вызове onConnected опубликовали их в localParticipant), что, похоже, работает, но не уверен, что это правильный путь.

Вопросы:

  • Является ли иногда нормальным получение события с добавлением трека до того, как участник подключился к участнику?
  • Если да, что вы посоветуете изящно справиться с этим?
  • Если нет, то какая ситуация может вызвать это?
  • Почему это касается только клиента Android (iOS, веб-клиент работает нормально)?
  • Это один из правильных способов решить эту проблему, как это сделали мы (от клиента)?

P.S. Это скорее концептуальный вопрос, поэтому код не предоставляется.

С Уважением.

ОБНОВЛЕНИЕ: я отредактировал свой вопрос, выделив только два (жирные). Эти двое нам действительно нужно знать. Получение ответов другим поможет нам прояснить этот вопрос.


twilio twilio-video
person Mesbah    schedule 12.12.2020    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Проповедник разработчиков Twilio здесь.

Я не уверен в порядке расположения перехватчиков, но, поскольку вы столкнулись с этим, было бы лучше обрабатывать перехватчики в любом порядке, в котором они появляются.

В документации по параметрам запроса для веб-перехватчиков все события, добавленные к дорожкам, также включают participantSid, participantIdentity и participantStatus. Итак, чтобы справиться с этим, я бы сначала проверил наличие participantSid в вашей базе данных, и, если его нет, создайте его, независимо от того, является ли это событие добавлением дорожки или событием, связанным с участниками. Затем, если подключенный к участнику веб-перехватчик прибывает после добавления дорожки, вы можете просто отбросить его (если participantStatus не другой).

person philnash    schedule 12.12.2020
comment
Учитывая асинхронную природу веб-перехватчиков, я изначально предполагал, что для этих обратных вызовов не должно быть определенного порядка. Определенно предложенный вами путь - один из возможных. Но наша путаница в том, почему это происходит только в случае клиента Android? - person Mesbah; 12.12.2020
comment
Я согласен, но я предполагаю, что присоединение участника и добавление трека - это довольно одновременное событие, которое может привести к условиям гонки, особенно при выполнении сетевых вызовов. Я надеюсь, что этот подход сработает для вас. - person philnash; 12.12.2020