[stable17] Request offer again when receiving peer fails

[danxuliu]

Replaces #1881

When the MCU is used and the connection with another participant failed until now there was no reconnection. Now a new offer is periodically requested until the connection is established again.

Note that even if the previous offer arrives after a new one is requested everything still works as expected. The MCU closes the previous connection whenever it sends a new offer, so if a previous offer arrives and a connection is made it will be closed as soon as the new offer is sent and reconnected again when the new offer is handled. Although receiving the previous offer would have stopped the periodic request of offers even if the new one failed the peer will eventually change to the ICE failed state, which will start a new reconnection routine.

In a related change, when the MCU is not used if no offer is received from the other participant the participant with the smaller ID now also sends an offer periodically instead of just once.

However, in this case, there are still glare issues (crossed offers between peers, it can be seen by replacing the break with a sleep(12) in scenario 1 below), they are not fixed by this change (without MCU this change only addresses missing offers).

Finally, a missing spinner on user avatars during the initial connection was also fixed.

How to test

Scenario 1

• Randomly drop most offers by adding

if ($decodedMessage['type'] === 'offer' && rand(0, 100) < 90) {
    break;
}

before adding messages in the SignalingController

• Start a call with a user
• Join the call with another user or guest

Result with this pull request

The participants are eventually connected despite several offers having failed.

Result without this pull request

The participants are kept trying to connect with each other (unless either the first or the second offer succeeded; in that case leave the call and join again until the wrong behaviour is shown). Also, the avatar of the user does not show a spinner during the initial connection.

Scenario 2

• Modify the code of the external signaling server to simulate a lot of failures (sorry for the formatting, I did not find a way to use lists and blocks of code)
  • In mcu_janus.go
    • After log.Printf("Already connected as subscriber for %s, leaving and re-joining", p.streamType) add time.Sleep(5 * time.Second) to cause an answer to be ignored when a new offer is closing the previous one.
  • In hub.go
    • Add "math/rand" to the imports at the top
    • Replace mc, err = session.GetOrCreateSubscriber(ctx, h.mcu, message.Recipient.SessionId, data.RoomType) in processMcuMessage with
      if rand.Intn(100) < 70 { err = nil } else { mc, err = session.GetOrCreateSubscriber(ctx, h.mcu, message.Recipient.SessionId, data.RoomType) }
      to drop a lot of offers instead of sending them.
    • Before those lines, add
      if rand.Intn(100) < 90 { time.Sleep(10 * time.Second) }
      to delay most of the offers longer than the timeout used in the WebUI to request new ones (unlike the other issues I do not recall seeing this in the real world, but worth checking it just in case).
    • Replace ctx, cancel := context.WithTimeout(context.Background(), h.mcuTimeout) with ctx, cancel := context.WithTimeout(context.Background(), time.Duration(18) * time.Second) to ensure that the delayed offer will be eventually sent (otherwise it would be cancelled due to the timeout); another option would have been to change the default timeout in the configuration.
• Setup the MCU
• Start a call with a user
• Join the call with another user or guest

Result with this pull request

The participants are eventually connected despite several offers having failed or arrived out of order due to a delay, and even if a connection failed during the negotiation.

Result without this pull request

The participants are kept trying to connect with each other (unless the first and the second offer succeeded without delay; in that case leave the call and join again until the wrong behaviour is shown). Also, the avatar of the user does not show a spinner during the initial connection.

[danxuliu]

I have fixed the issue with the loading icon sometimes appearing on the user avatars even if they are connected.

The problem was that the icon was restored based on the connection status at the time that the avatar was initially set, but the icon should be restored based on the connection status at the time that the image is finally loaded. Otherwise it could happen that the avatar was set when the connection was still new, the connection changed to connected, and then the image was loaded, which restored the loading icon based on the original new status.

[nickvergessen]

🐘 Calling works on our company instance
Remaining loading circle was fixed

[nickvergessen]

Rebased for the fixup