When the HPB is not used the participant with the higher session ID sends an offer to the participant with the lower session ID to establish the connection. However, if a participant is not publishing any media it will not send an offer and just expect that the other participant sends it if needed (that is, if the other participant is publishing media). The Android app does not take that into account, and it assumes that if the other participant has a higher session ID the other participant will send an offer. Therefore, when the browser is not publishing media and has a higher session ID no connection is established between the browser and the Android app, as both are expecting the other participant to send an offer.
Unfortunately I did not find a clean way to fix this in the current Android code, as the logic to start a connection is split between CallActivity and PeerConnectionWrapper. It should be easier to do that after further refactoring of the call code, but I did not get there yet :-( However, as it is a somewhat uncommon scenario for now it is just an unfortunate but known bug 🤷
Steps to reproduce
- Do not setup the HPB
- Open a conversation in the Android app
- Open the same conversation in the browser
- Check if the session ID of the browser participant is higher than the session ID of the Android participant; if not, reload the page until it is
- You can check the sessions in the browser console with
store.getters.participantsList(THE_CONVERSATION_TOKEN).forEach(participant => console.log(participant.actorId + " " + participant.sessionIds))
- For the comparison purposes note that "0" < "9" < "A" < "Z" < "a" < "z"
- Start a call in the Android app
- Join the call in the browser without microphone nor camera
Expected behaviour
The connection with the Android participant is established in the browser
Actual behaviour
The connection with the Android participant is not established in the browser (a spinner is shown)
When the HPB is not used the participant with the higher session ID sends an offer to the participant with the lower session ID to establish the connection. However, if a participant is not publishing any media it will not send an offer and just expect that the other participant sends it if needed (that is, if the other participant is publishing media). The Android app does not take that into account, and it assumes that if the other participant has a higher session ID the other participant will send an offer. Therefore, when the browser is not publishing media and has a higher session ID no connection is established between the browser and the Android app, as both are expecting the other participant to send an offer.
Unfortunately I did not find a clean way to fix this in the current Android code, as the logic to start a connection is split between
CallActivityandPeerConnectionWrapper. It should be easier to do that after further refactoring of the call code, but I did not get there yet :-( However, as it is a somewhat uncommon scenario for now it is just an unfortunate but known bug 🤷Steps to reproduce
store.getters.participantsList(THE_CONVERSATION_TOKEN).forEach(participant => console.log(participant.actorId + " " + participant.sessionIds))Expected behaviour
The connection with the Android participant is established in the browser
Actual behaviour
The connection with the Android participant is not established in the browser (a spinner is shown)