0
votes

Context:

We are using Twilio programmable video for our app on iOS, Android, WebBrowser. There is a Java web server that uses a webhook to listen to all the events.

We started implementing Android app recently. For android clients, we noticed "participant-connected" event is sometimes received after "track-added" for a participant in our server.

That is causing some issue on our server logic. As our server anticipates "participant-connected" will come before "track-added", otherwise it fails to add the track to participant (as our server managed participant is not available till "participant-connected" event).

What we tried:

  1. We provided localVideo and localAudio track in the connection option, for connecting rooms from android, which causes this issue randomly.
  2. We published the tracks from android only after room is connected (removed the localVideo and localAudio track from connection option, and in onConnected callback, published them on localParticipant), which seems to work, but not sure if it is the right way.

Questions:

  • Is it normal to receive "track-added" event before "participant-connected" for a participant sometimes?
  • If yes, what's your suggestion on gracefully handling this?
  • If not, what kind of situation might cause this?
  • Why is it the case only for Android client (iOS, web client working fine.)?
  • Is it one of the right ways to solve it, the way we did it (from client)?

P.S. This is more of a conceptual question, so no code is provided.

Regards.

UPDATE: I edited my question to emphasis just two (bold ones). These two we really need to know. Getting answer to others will help us gain more clarity on this matter.

1

1 Answers

1
votes

Twilio developer evangelist here.

I am not sure about the order of the webhooks, but since you are experiencing this it would be better to handle the webhooks in whatever order they come in.

In the documentation for the request parameters for the webhooks all the track-added events also include the participantSid, participantIdentity and participantStatus. So, to handle this, I would check for the existence of the participantSid in your database first, and if it is not there, create it, regardless of whether this is a track-added or participant-connected event. Then, if the participant-connected webhook arrives after track-added, you can just drop it (unless the participantStatus is different).