We want to show to the user the local video Stream even if the call is not answered, trying to avoid user to be frustrated with no feedback in the UI.
Created attachment 8469215 [details] [review] Pull Request
Comment on attachment 8469215 [details] [review] Pull Request Thanks for the patch Borja. I was wondering if we could try a different approach. I believe we decided not to start any media stream until the callee party accepted the call to avoid unnecessary battery drain and network usage. But I agree that given that we are taking too long to connect both peers it might be worth to start the media stream as soon as possible. Instead of using a fake local video, could we just start publishing the video of the caller as soon as the call is triggered? That way the caller will be able to see his own video stream very soon and we will save a few seconds on the call set up. On the callee side we shouldn't publish the stream until the user accepts the call for obvious reasons. But alos I can't see how showing the local video in the callee side could improve the UX. In fact, IMHO it might even be scary for the user to see her own stream before accepting the call. She doesn't really know that we are not publishing it yet. Also I believe that given the current absence of a proper echo cancellation feature we shouldn't publish the audio stream until both parties are connected.
Comment on attachment 8469215 [details] [review] Pull Request Updated with Fernando's suggestions. Now we are publishing our stream asap, trying to reduce the time to connect with the other peer.