Audio/Video media combination handling is buggy between peers

[atsakiridis]

It can be tricky which audio/video combinations to allow when a P2P call is made. Originally we wanted to be able each peer to have it's own independent preference, so for example:

• Audio call from Alice can be answered with video from Bob so that Alice only shares audio, but Bob shares audio + video
• Video call from Alice can be answered with audio from Bob so that Alice shares both, but Bob only shares audio

This logic has a couple of issues:

• By default when an audio call is made from alice there is no video m-line in the SDP offer, which means that it cannot directly be answered with audio & video since SDP offer & answer must have the same number of m-lines. So for this to work we need to follow a different approach like for example always sending both audio + video m-lines but keep video muted in an audio call. But this is an issue API-wise because an App that wants to do an audio call shouldn't be forced to provide a video view to the API call
• Conceptually it's a bit confusing for most people to make an audio call that is answered as video and vice versa
• Still it would be nice for a video call to be possible to be answered as audio if the peer doesn't have support for video

Had a look at Facebook Messenger and they do the following:

• The caller decides on the type of the call by chosing either audio or audio & video
• The callee doesn't chose how to answer a call; they just answer it and which ever type of media the caller chose will be used in the callee as well
• There's an exception though, if caller chose audio & video call and the callee cannot support video, the call is changed to audio
• If the call started off as audio it can be upgraded by means of re-invite
• If the call started off as audio & video then it cannot be 'downgraded' obviously, but any of the peers are free to mute video

From App perspective this is pretty usable, but I need to analyze more SDK requirements and come up with a plan to maximize usability and flexibility. I think for 1.0 GA though we can simplify SDK to work similarly to messenger and fix current issues. Later we can maximize flexibility as well, so that our SDK works well across more 'weird' environments than typical enterprise communications (like industrial comms, gaming, etc)

@deruelle @marca56 I think we should bite the bullet and fix this for 1.0 GA as currently the implementation is buggy. Do you agree?

Also refer to #375 for this

[marca56]

@atsakiridis and @deruelle ... we implemented this in a similar fashion for Primo. Due to some limitations of the server (initially did not support reinvite during a WebRTC session), we decided to send audio and video for all P2P calls and depending on what button the sender chose (audio or video), we set the receiver's ability to select audio or video. We grayed out the video button on the receiver side if the sender chose audio only. We never got back to implementing it but the reinvite bug was fixed. It would have allowed the best scenario you described at the top.

I would love to bite the bullet and fix this issue because it will make for a cleaner user experience for sure.

[atsakiridis]

Thanks @marca56 we 're in agreement then. I will do some more digging on that when time permits to that we can push forward