[stable17] Send offer again when own peer is not initially connected #2488
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In some cases, for example during the initial connection, the loading icon was not shown on the user avatar. The reason was that the "avatar()" function adds a loading icon to the element while the image is being fetched and removes it once done. Due to this, if the element had a loading icon before it will be removed after the image is fetched, and thus needs to be restored. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
The property will be used too when the MCU is used, but in this case to request an offer from a peer instead of the send the offer to that peer (but in both cases the goal is to connect with the peer). Signed-off-by: Daniel Calviño Sánchez <[email protected]>
When the MCU is not used the peer with the larger ID sends an offer to the peer with the smaller ID. However, sometimes the peer with the larger ID may fail to notice a disconnection and not send an offer again, so if the peer with the smaller ID does not get an offer in a reasonable time it also sends an offer. Before the offer was sent just once, so if the offer sent by the peer with the smaller ID was not handled for some reason by the other peer no reconnection happened. Now the offer is periodically resent until the connection is established again. Note that, besides improving reconnections, this also helps with the initial connection, as if the initial offers are not handled now the peer with the smaller ID will try to connect again and again (although there are still "glare" issues if offers are crossed between peers). Signed-off-by: Daniel Calviño Sánchez <[email protected]>
When the MCU is used and the connection fails in the peer that sent the offer, that is, the own peer object that sends the local media to the MCU, a forced reconnection is triggered. However, if the peer that failed was one used to receive the media from the other participants there was no reconnection, and therefore the other participant could be no longer heard or seen. Now, if the connection with one of those peers fail an offer is requested again to the MCU periodically until the connection is established again. The same approach is used too in the initial connection to those peers, as in some cases the initial offer request may fail, which left the peers disconnected. The periodic retry is stopped as soon as an offer is received, but even if that offer fails to connect eventually an ICE fail will be triggered, which will start a new reconnection routine. Finally, note that a forced reconnection when the connection to other participants fail is not only unneeded, but also it would be problematic, as a network issue in one participant could trigger a forced reconnection for all the other participants. Signed-off-by: Daniel Calviño Sánchez <[email protected]>
Signed-off-by: Daniel Calviño Sánchez <[email protected]>
danxuliu
added
2. developing
feature: WebRTC 🚡
danxuliu
deleted the
send-offer-again-when-own-peer-is-not-initially-connected
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Follow up to #2475