How to build group video call with React Native & WebRTC

1. Overview

1.1 React Native

React Native is a framework that brings React’s declarative UI framework into mobile platforms. It allows developers to create cross-platform apps that render natively on iOS and Android platforms, sharing a single codebase. This enables faster development and easier maintenance compared to traditional native app development.

1.2 WebRTC

WebRTC stands for Real time communication for the web. It supports video, voice, and generic data to be sent between peers and available on all modern browsers as well as on native clients for all major platforms. 

WebRTC go through common application flow:

• Access media devices (microphone, camera)
• Create peer-to-peer connections
• Discover peer connections
• Start streaming

2. How does WebRTC work

To have more understanding about how WebRTC works, we will go through some technical terms.

2.1 Peer-to peer (P2P) connection

A Peer-to-peer connection is an infrastructure that allows two or more end devices to share resources and communicate with each other directly without sending data to a separate server.

In the P2P connection, each end device is considered a “peer”. Each peer acts as client and server itself, it shares and receives resources with other peers.

2.2 Signaling server

With the help of a Signaling server, two peers can connect by providing SDP and ICE server configuration, which is generated by two servers: STUN or a TURN server. Their mission is to create ICE Candidates for each peer and exchange it with other peers. The process to exchange the information is signaling.

A Signaling server is basically a real-time server such as Firebase Firestore, WebSocket, OneSignal.

2.3 SDP

SDP stands for Session Description Protocol, which contains details of real-time communication sessions between two peers. Simple example is if a device’s camera is turned off, SDP will include this data to send to another device

SDP is part of creating a P2P connection process. The SDP negotiation involves two steps: offer and answer.

2.4 ICE candidates

To put it simply, ICE Candidates act as addresses of each peer which is used to connect with other peers through the internet. One client can have multiple ICE Candidates containing information about transport protocol, port number and IP addresses.

2.5 Visualize making one P2P connection

How exactly can webRTC establish peer-to-peer connection with these technical terms above? A simple graph will visualize steps on how webRTC can establish the connection.

In this example, Peer-1 is the device which wants to communicate with Peer-2

First, Peer-1 creates an Offer containing SDP and ICE Candidates generated by WebRTC API and sends it to the Signaling Server.

Meanwhile, Peer-2 listens to the Signaling server to receive the incoming Offer. After receiving the Peer-1’s Offer, Peer-2 creates an Answer which also contains the same structure data and sends it back to the Signaling Server.

Now, both devices have each other’s configuration. The peer connection is established.

2.6 Visualize making multiple P2P connections

How about another scenario where a device named Peer-3 wants to join the communication with Peer-1 and Peer-2 ?

Let’s assume Peer-1 and Peer-2 already establish a connection following steps in Section 2.5, An simple example demonstrates how Peer-3 can establish connection with Peer-1 and Peer-2.

When Peer-3 joins the communication, it will need to create a number of Offers depending on current total participants. In this case, there are already two participants in the group so that Peer-3 creates two Offers and sends these to the Signaling Server.

Although Peer-1 and Peer-2 already had P2P connection, they also needed to listen to new Offers coming from the Signaling Server. When both devices receive an Offer, each peer creates an Answer and sends it back to the Signaling Server.

As a result, Peer-3 receives both Answers from other peers so the P2P connections between three peers are established successfully.

2.7 Simplify steps create P2P connections in terms of implementation

What does the Offeror do?

• Init peer connection
• Add local media stream to created peer connection
• Create offer and store offer as local description
• Send offer SDP and ICE Candidates to Signaling server
• Add event listen to coming answer
• Add event listen to track coming answer’s media stream
• Add event listen to coming answerer’s ICE Candidates
• When receiving answer, store answer as remote description and add answerer’s ICE Candidates into Peer connection

What does the Answerer do?

• Init peer connection
• Add local media stream to created peer connection
• Receive offer from Signaling server and store as remote description
• Create answer and store answer as local description
• Send answer SDP & ICE Candidates back to Signaling server
• Add event listen to track coming offeror’s media stream
• Add event listen to coming offer’s ICE Candidates
• Add offeror’s ICE Candidates into Peer connection

Section 3 will demonstrate detail implementation for these steps above

3. Building demo: Group video call

3.1 Overview features

The source code of this demo is here. Basic feature for group video call including:

• Create new room or join room with existed room ID
• Control microphone and camera
• One of the users in the call hangs up. App allows the call still processing unless everyone leaves the room
• No limit participants

Next, we will go through step by step how we implement all these features.

3.2 Initialize React Native app

First, init React Native project with command line:

npx react-native@latest init YourProjectName

Install the react-native-webrtc module:

npm i react-native-webrtc

If you take a look at source code and wonder why there are plenty of packages beside react-native-webrtc. It’s because we used the rn-base-project-typescript to generate the source template for quick initialization. It only takes 1 command to install all needed packages to start the RN project and generate the best practice structure ready to implement immediately without spending too much time on initialization. More information is here.

Let’s go back to our demo, you also need to do extra steps depending on your target platform.

For iOS,  add permissions for camera and microphone in Info.plist:

NSCameraUsageDescription

Camera Permission description

NSMicrophoneUsageDescription

Microphone Permission description

For Android, add permissions in AndroidManifest.xml:

android:name=”android.permission.INTERNET” />

android:name=”android.permission.CAMERA” />

android:name=”android.permission.RECORD_AUDIO” />

android:name=”android.permission.ACCESS_NETWORK_STATE” />

android:name=”android.permission.CHANGE_NETWORK_STATE” />

android:name=”android.permission.MODIFY_AUDIO_SETTINGS” />

To run the project, simply run command based on your target platform:

npx react-native run-android 

npx react-native run-ios

3.3 Setup Signaling server structure with Firebase Firestore

In this demo, we used Firebase Firestore as our Signaling Server.

For installation and configuration with Firestore, I recommend checking the original document from React Native Firebase because it’s already clear and informative to configure. The document is here.

Next, we will jump to the Firestore structure part. First, we create a collection named Rooms to manage all room calls. 

Room keys use the name of who created the room. Please note that, we used the name as room id for joining the room faster without copying and pasting the key in several devices, but in real situations, we recommend to work with UUID instead.

Each Room has 2 collections: Participants and Connections.

Participants is a collection listing all active participants in the room.

Each participant has information about their name and microphone, camera status. If the participant turns off their microphone which results in the microphone value being false. This logic applies the same for the camera value.

Connections collection containing all peer-to-peer connections. For example, if there are 3 participants in the room, there should be 3 peer-to-peer connections in the list.

The number of connections is calculated by this formula, n is total participants:

n (n – 1) / 2

Each connection has 2 collections answerCandidates and offerCandidates and contains 4 key-value pairs:

• answer:  SDP of the responder
• offer: SDP of the requester
• requester: name of the requester
• responder: name of the responder

answerCandidates holds a list of ICE Candidates of an answerer and will be tracked and added by offeror to their PeerConnection. It’s the same with the offerCandidates which records data for an offeror.

So now we’re all set for the implementation part.

3.4 Construct states and refs

Location: src/screens/HomeComponent/HomeScreen.tsx

const [roomId, setRoomId] = useState(”)

const [localStream, setLocalStream] = useState | undefined>()

const [userName, setUserName] = useState(”)

const [screen, setScreen] = useState(Screen.CreateRoom)

const [remoteMedias, setRemoteMedias, remoteMediasRef] = useStateRef

  <{ [key: string]: MediaControl }>({})

const [remoteStreams, setRemoteStreams, remoteStreamsRef] = useStateRef

  <{ [key: string]: MediaStream }>({})

const [peerConnections, setPeerConnections] = useStateRef

  <{ [key: string]: RTCPeerConnection}>({})

const [totalParticipants, setTotalParticipants] = useState(0)

const [localMediaControl, setLocalMediaControl] = useState({

  mic: microphonePermissionGranted,

  camera: cameraPermissionGranted,

 })

Explanation:

• roomId: stored room id that current user create room or input to join 
• localStream: media stream of user’s local device
• screen: current display screen type, default value is CreateRoom

scr/screens/HomeComponent/types.ts

export enum Screen {

 CreateRoom, // create or join room

 InRoomCall, // participate in room call

}

• remoteMedias: arrays have microphone and camera status of other user ‘s remote devices 

export type MediaControl = {

 mic: boolean

 camera: boolean

}

• remoteStreams: same with localStreams but for other user’s MediaStream
• peerConnections: all P2P connections of current user with other users
• totalParticipants: number of users in one room call
• localMediaControl: same with remoteMedias but locally, it presented the status of the user’s local media device.

3.5 Request camera & microphone permission

Check and request permission with custom hook from hooks/useRequestPermissions.ts 

const {

   // Boolean value if permission is granted

   cameraPermissionGranted, 

   microphonePermissionGranted,

   // request permission methods

   requestMicrophonePermission,

   requestCameraPermission,

 } = usePermission()

The layout when requesting permission:

After permission granted, we will call method openMediaDevices to show our MediaStream locally:

const openMediaDevices = useCallback(async (audio: boolean,video: boolean) => {

  // get media devices stream from webRTC API

  const mediaStream = await mediaDevices.getUserMedia({

    audio,

    video,

  })

  // init peer connection to show user’s track locally

  const peerConnection = new RTCPeerConnection(peerConstraints)

  // add track from created mediaStream to peer connection 

  mediaStream.getTracks().forEach(track => 

    peerConnection.addTrack(track, mediaStream)

  )

  // set mediaStream in localStream

  setLocalStream(mediaStream)

 }, [])

As a result, we can see our camera display in the screen:

3.6 Create room

Default screen is CreateRoom screen, when the user has already entered the name, the button “Create room” will be enabled and the user can click on. This action triggers the function called createRoom:

const createRoom = useCallback(async () => {

  // create room with current userName and set createdDate as current datetime

  const roomRef = database.collection(FirestoreCollections.rooms).doc(userName)

  await roomRef.set({createdDate: new Date()})

  // create participants collection to room “userName”

  roomRef.collection(FirestoreCollections.participants).doc(createdUserName)

   .set({

     // control mic and camera status of current user’s device

     mic: localMediaControl?.mic, 

     camera: localMediaControl?.camera,

     name: userName,

   })

  setRoomId(roomRef.id) // store new created roomId

  setScreen(Screen.InRoomCall) // navigate to InRoomCall screen

  // add listener to new peer connection in Firestore

  await listenPeerConnections(roomRef, userName)

  …

The function triggers navigating to InRoomCall screen immediately

For more understanding, users who join will be the one sending an offer to existing participants. So that’s why inside createRoom, we only have a method to listen to new coming connections. It’s redundant to create an offer and initiate the peer connection first with no one in the room.

In listenPeerConnections does:

• Listen to new changes in Connections and loop to find if there are Offers sent to the current user. Current users can have multiple connections so the data will be created one by one when it loops. Each connection will be distinguished with the requester name to store in defined states and refs above.

const listenPeerConnections = useCallback(async (roomRef, userName) => {

  roomRef.collection(FirestoreCollections.connections).onSnapshot(

   connectionSnapshot => {

     // looping changes from collection Connections

     connectionSnapshot.docChanges().forEach(async change => {

       if (change.type === ‘added’) {

         const data = change.doc.data()

         // find connections that request answer from current user

         if (data.responder === userName) {

…

• Get control and MediaStream data from requester to store in remoteMedias and remoteStreams

if (data.responder === createdUserName) {

  // get requester’s location from collection Participants

  const requestParticipantRef = roomRef.collection(

    FirestoreCollections.participants).doc(data.requester)

  // get requester’s data from requester’s location

  const requestParticipantData = (await requestParticipantRef.get()).data()

  // store requester’s control status in remoteMedias

  setRemoteMedias(prev => ({

    …prev,

    [data.requester]: {

      mic: requestParticipantData?.mic,

      camera: requestParticipantData?.camera

    },

  }))

  // init requester’s remoteStream to add track data from Peer Connection later

  setRemoteStreams(prev => ({

    …prev,

    [data.requester]: new MediaStream([]),

  }))

• Init PeerConnection and control MediaStream for both requester and responder 

…

// init PeerConnection

const peerConnection = new RTCPeerConnection(peerConstraints)

// add current user’s stream to created PC (Peer Connection)

localStream?.getTracks().forEach(track => {

  peerConnection.addTrack(track, localStream)

})

// get requester’s MediaStream from PC

peerConnection.addEventListener(‘track’, event => {

  event.streams[0].getTracks().forEach(track => {

  const remoteStream = remoteStreams[data.requester] ?? new MediaStream([])

  remoteStream.addTrack(track)

  // and store in remoteStreams as it’s initialized before

  setRemoteStreams(prev => ({

    …prev,

    [data.requester]: remoteStream,

   }))

  })

})

• Processing SDP data inside Offer and Answer

// get location of connection between requester and current user

const connectionsCollection = roomRef.collection(

  FirestoreCollections.connections)

const connectionRef = connectionsCollection

.doc(`${data.requester}-${userName}`)

// get data from requester-user’s connection

const connectionData = (await connectionRef.get()).data()

// receive offer SDP and set as remoteDescription

const offer = connectionData?.offer

await peerConnection.setRemoteDescription(offer)

// create answer SDP and set as localDescription

const answerDescription = await peerConnection.createAnswer()

await peerConnection.setLocalDescription(answerDescription)

// send answer to Firestore

const answer = {

  type: answerDescription.type,

  sdp: answerDescription.sdp,

}

await connectionRef.update({ answer })

• Collect and add ICE Candidates for both users

…

// create answerCandidates collection

const answerCandidatesCollection = connectionRef.collection(

  FirestoreCollections.answerCandidates)

// add current user’s ICE Candidates to answerCandidates collection

peerConnection.addEventListener(‘icecandidate’, event => {

  if (event.candidate) {

    answerCandidatesCollection.add(event.candidate.toJSON())

  }

})

// collect Offer’s ICE candidates from offerCandidates collection and add in PC

connectionRef.collection(FirestoreCollections.offerCandidates)

  .onSnapshot(iceCandidateSnapshot => {

    iceCandidateSnapshot.docChanges().forEach(async iceCandidateChange => {

      if (iceCandidateChange.type === ‘added’) {

        await peerConnection.addIceCandidate(

          new RTCIceCandidate(iceCandidateChange.doc.data()))

}

     })

})

• Store Peer Connection 

…

setPeerConnections(prev => ({

   …prev,

  [data.requester]: peerConnection,

}))

…

So we’re done with listening to new connections. Let’s move on to the later part of how the Offeror creates an offer to Answerers.

3.7 Join room

The scenario will be different because the current user will now be the one who joins the room, they will enter the existing room id and click on the “Join” button.

When the user clicks on “Join”, there’s a checkRoomExist to check if the entered id exists:

const checkRoomExist = useCallback(() => {

 // get room data based on the entered room id

   const roomRef = database.collection(FirestoreCollections.rooms).doc(roomId)

   roomRef.get().then(docSnapshot => {

     if (!docSnapshot.exists) {

       Alert.alert(‘Room not found’)

       setRoomId(”)

       return

     } else {

       joinRoom(roomRef) // process to join room if room is existed

     }

   })

…

In joinRoom:

const joinRoom = useCallback(async (roomRef) => {

  // register new PeerConnection to FireStore

  await registerPeerConnection(roomRef, userName)

  // add user data to participants collection

  await roomRef.collection(FirestoreCollections.participants)

    .doc(userName).set({

      mic: localMediaControl?.mic,

      camera: localMediaControl?.camera,

      name: userName,

    })

  // also listen to new coming PeerConnections

  await listenPeerConnections(roomRef, userName)

  setScreen(Screen.InRoomCall) // navigate to InRoomCall screen

…

Not only does a joined user need to create offers sending to remain participants but also requisite to listen to later connections because we don’t know exactly if this user is the last one joining the call.

However if we’re in the scenario with the need to limit participants, we can base on the  number of people to detect when there is no need to add listenPeerConnections for the one who is the last participant.

Let’s get back to continuous application flow, after processing in the joinRoom method, users will be navigated to the InRoomCall screen as well but the difference is there were  participants in the call.

In registerPeerConnection does:

• Get all participants data from Participants collection to loop and create Offer for each participant

const registerPeerConnection = useCallback(async (roomRef, userName) => {

// loop all participants data 

const participants = await roomRef.collection(

  FirestoreCollections.participants).get()

participants.forEach(async participantSnapshot => {

       const participant = participantSnapshot.data()

…

• Store all participants’s control status and init participants MediaStream

…

const participant = participantSnapshot.data()

// store participant’s control status in remoteMedias

setRemoteMedias(prev => ({

 …prev,

  [participant.name]: {

     mic: participant?.mic,

    camera: participant?.camera,

    },

  }))

// init participant’s remoteStream to add track data from Peer Connection later

setRemoteStreams(prev => ({

  …prev,

  [participant.name]: new MediaStream([]),

}))

…

• Init PeerConnection and control MediaStream

…

// init peer connection

const peerConnection = new RTCPeerConnection(peerConstraints)

// add current user’s stream to created PC (Peer Connection)

localStream?.getTracks().forEach(track => {

  peerConnection.addTrack(track, localStream)

})

// get participant’s MediaStream from PC 

peerConnection.addEventListener(‘track’, event => {

  event.streams[0].getTracks().forEach(track => {

    const remoteStream = remoteStreams[participant.name] ?? new MediaStream([])

    remoteStream.addTrack(track)

    // and store in remoteStreams as it’s initialized before

    setRemoteStreams(prev => ({

      …prev,

      [participant.name]: remoteStream,

    }))

  })

})

…

• Processing SDP data inside Offer and Answer

…

// create connection between current user and participant

const connectionsCollection = roomRef.collection(

  FirestoreCollections.connections)

const connectionRef = connectionsCollection

  .doc(`${createdUserName}-${participant.name}`)

// create offer SDP and set localDescription

const offerDescription = await peerConnection.createOffer(sessionConstraints)

peerConnection.setLocalDescription(offerDescription)

// send offer to Firestore

const offer = {

  type: offerDescription.type,

  sdp: offerDescription.sdp,

}

await connectionRef.set({

  offer,

  requester: createdUserName,

  responder: participant.name,

})

// add listener to coming answers

connectionRef.onSnapshot(async connectionSnapshot => {

  const data = connectionSnapshot.data()

  // if PC does not have any remoteDescription and answer existed

  if (!peerConnection.remoteDescription && data?.answer) {

    // get answer and set as remoteDescription

    const answerDescription = new RTCSessionDescription(data.answer)

    await peerConnection.setRemoteDescription(answerDescription)

  }

})

…

• Collect and add ICE Candidates for both users

// create offerCandidates collection 

const offerCandidatesCollection = connectionRef.collection(

  FirestoreCollections.offerCandidates)

// add current user’s ICE Candidates to offerCandidates collection

peerConnection.addEventListener(‘icecandidate’, event => {

  if (event.candidate) offerCandidatesCollection.add(event.candidate.toJSON())

})

// add listener to answerCandidates collection to participant’s ICE Candidates 

connectionRef.collection(FirestoreCollections.answerCandidates).onSnapshot(iceCandidatesSnapshot => { iceCandidatesSnapshot

  .docChanges().forEach(async change => {

    if (change.type === ‘added’) {

      // get Answer’s ICE candidates and add in PC

      await peerConnection.addIceCandidate(

        new RTCIceCandidate(change.doc.data()))

    }

  })

})

• Store Peer Connection

…

setPeerConnections(prev => ({

  …prev,

  [participant.name]: peerConnection,

}))

…

It’s the end for core implementation of creating room calls. Users can communicate with each other now via creating rooms or adjoining rooms with id

3.5 Control media devices

Beside the core feature above, users can control their camera and microphone and  know other user’s control status via Signaling server. There are states that we used as beginning to store control data. 

const [remoteMedias, setRemoteMedias, remoteMediasRef] = useStateRef

  <{ [key: string]: MediaControl }>({})

const [localMediaControl, setLocalMediaControl] = useState({

  mic: microphonePermissionGranted,

  camera: cameraPermissionGranted,

})

When a user turns on/off their microphone, it will trigger toggleMicrophone:

// toggle local microphone

const toggleMicrophone = useCallback(() => {

  // check if permission is granted, if not call request permission

  if (microphonePermissionGranted) {

    // update state in local mediaControl

    setLocalMediaControl(prev => ({

      …prev,

      mic: !prev.mic,

    }))

    // update mic value of localStream

    localStream?.getAudioTracks().forEach(track => {

      localMediaControl?.mic ? 

        track.enabled = false : 

        track.enabled = true

    })

    if (roomId) {

      // get location of current room that user’s in

      const roomRef = database.collection(FirestoreCollections.rooms)

        .doc(roomId)

      // get location of user’s participant data 

      const participantRef = roomRef.collection(

        FirestoreCollections.participants).doc(userName)

      // update mic value in Firestore

      participantRef.update({

        mic: !localMediaControl?.mic,

      })

    } else { requestMicrophonePermission() }

 }

…

The same with camera, toggleCamera will be triggered when user clicks on Camera button:

const toggleCamera = useCallback(() => {

  // check if permission is granted, if not call request permission

  if (cameraPermissionGranted) {

    // update state in local mediaControl

    setLocalMediaControl(prev => ({

      …prev,

      camera: !prev.camera,

    }))

    // update camera value of localStream

    localStream?.getAudioTracks().forEach(track => {

      localMediaControl?.camera ? 

        track.enabled = false : 

        track.enabled = true

    })

    if (roomId) {

      // get location of current room that user’s in

      const roomRef = database.collection(FirestoreCollections.rooms)

        .doc(roomId)

      // get location of user’s participant data 

      const participantRef = roomRef.collection(

        FirestoreCollections.participants).doc(userName)

      // update camera value in Firestore

      participantRef.update({

        camera: !localMediaControl?.camera,

      })

    } else { requestCameraPermission() }

 }

…

There is useEffect has a listener to new changes from collection Participants so that whenever other participants change their control status, we can update remoteMedias data immediately to display layout in the app.

• Listen to new changes from Participants list

useEffect(() => {

  if (roomId) {

    const roomRef = database.collection(FirestoreCollections.rooms)

      .doc(roomId)

    const participantRef = roomRef.collection(

      FirestoreCollections.participants)

     if (participantRef) {

       // listener to new changes from Participants collection

       participantRef.onSnapshot(snapshot => {

  // get current total participants in Firestore

         if (totalParticipants !== snapshot.size) {

           setTotalParticipants(snapshot.size)

         }

  // loop through new data changes

         snapshot.docChanges().forEach(async change => {

…

• Inside the loop function, different logic will be applied depending on data change type. In this case, we will only consider the “modified” case which is new updates of control status’s other user

…

const data = change.doc.data()

if (change.type === ‘modified’) {

  // ignore changes from current user 

  if (data?.name !== userName) {

    // update new change in remoteMedias

    setRemoteMedias(prev => ({

      …prev,

      [data.name]: {

        camera: data?.camera,

        mic: data?.mic,

      },

    }))

   }

…

With this approach, whenever a remote user turns on/off their camera or microphone, we can display a reference layout to showcase their control status. It can be a small muted microphone in the user’s frame or display default avatar when turned off the camera.

3.6 Hang up

When one of the users leaves the room, in this demo we still let the call continue to process if this user is not the last one in the room. 

User leaves the room by clicking the bottom red button, it will trigger hangUp function:

• Stop all track MediaStream for local and remote

const hangUp = useCallback(async () => {

  // stop local stream

  localStream?.getTracks()?.forEach(track => {

    track.stop()

  })

  // stop remote streams

  if (remoteStreams) {

    Object.keys(remoteStreams).forEach(remoteStreamKey => {

      remoteStreams[remoteStreamKey].getTracks()

        .forEach(track => track.stop())

      })

   }

…

• Close Peer Connection

if (peerConnections) {

     Object.keys(peerConnections).forEach(peerConnectionKey => {

         peerConnections[peerConnectionKey].close()

     })

}

• There are 2 cases when hang up, the first case is the last user who leaves the room. We will delete all room data so as not to store any redundant data in Firestore.

// get location of current room 

const roomRef = database.collection(FirestoreCollections.rooms).doc(roomId)

if (totalParticipants === 1) {

  const batch = database.batch()

// delete all data Participants 

const participants = await roomRef.collection(

  FirestoreCollections.participants).get()

participants?.forEach(doc => {

      batch.delete(doc.ref)

 })

// delete all data Connections 

const connections = await roomRef.collection(

  FirestoreCollections.connections).get()

connections?.forEach(doc => {

     batch.delete(doc.ref)

 })

// delete current room detail data and this room in Rooms 

await batch.commit()

await roomRef.delete()

 …

• Second case is when there are still participants in the room. We just need to delete this user from Participants and all related Connections that has this user as responder or requester

… 

// delete user data in Participants collection

await roomRef.collection(FirestoreCollections.participants)

 .doc(userName).delete()

// filter data has userName is requester or responder

const Filter = firebase.firestore.Filter

const connectionSnapshot = await roomRef

       .collection(FirestoreCollections.connections)

       .where(

     Filter.or(

       Filter(‘requester’, ‘==’, userName), 

       Filter(‘responder’, ‘==’, userName)

   ))

   .get()

// delete all filtered connections one by one 

connectionSnapshot?.docs?.forEach?.(async doc => {

       const batch = database.batch()

   // delete all data answerCandidates 

      const answerCandidates = await doc.ref.collection(

     FirestoreCollections.answerCandidates).get()

      answerCandidates.forEach(answerDoc => {

            batch.delete(answerDoc.ref)

       })

   // delete all data offerCandidates 

      const offerCandidates = await doc.ref.collection(

     FirestoreCollections.offerCandidates).get()

      offerCandidates.forEach(offerDoc => {

           batch.delete(offerDoc.ref)

       })

   // delete connection detail and remove it from Connections

       await batch.commit()

       doc.ref.delete()

• On the participants side, when someone hangs up, we also handle logic to update participants’ remote data which is in the same useEffect listening to Participants collection changes. It’s different from handle for control status, in this case we focus on change type “removed” instead

…

else if (change.type === ‘removed’) {

// update remote streams to remove leaver’s streams 

setRemoteStreams(prev => {

  const newRemoteStreams = {…prev}

  delete newRemoteStreams[data?.name]

  return newRemoteStreams

})

// update remote medias to remove leaver’s control status

setRemoteMedias(prev => {

  const newRemoteMedias = {…prev}

  delete newRemoteMedias[data?.name]

  return newRemoteMedias

})

…

Lastly, we will reset all data and navigate back to CreateRoom screen

…

// reset data 

setRoomId(”)

setScreen(Screen.CreateRoom)

setRemoteMedias({})

setRemoteStreams({})

setPeerConnections({})

setTotalParticipants(0)

// if user still enable camera or microphone, call openMediaDevices to show it locally

if (localMediaControl?.camera || localMediaControl?.mic) {

  openMediaDevices(localMediaControl?.mic, localMediaControl?.camera)

}

4. Conclusion

WebRTC is a powerful technology to help you build the app which has the smooth and low-latency communication facilitated, ensuring an immersive group video calling experience. There are so many advantages about WebRTC features and development process

4.1 Pros

• Free open-source and quick project development
• Full structured documentation with plenty of demos for each webRTC API
• Security with always-on voice and camera encryption
• Powerful multimedia capabilities on the web rather than video call: file exchange, chat channel, screen sharing, v.v

Like any technology, it may come with some of Cons we need to consider when using:

4.2 Cons

• No way to track the active status of remote media devices which results in increasing database usage for controlling extra flow
• Decrease call quality with low internet speed
• Not suitable for streaming events have large volume load

Resources

• Demo source code (included video demo)

https://github.com/saigontechnology/React-Native/tree/main/demo/WebRTC

References

• React Native Firestore: https://rnfirebase.io/firestore/usage
• React Native WebRTC: https://github.com/react-native-webrtc/react-native-webrtc