Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebRTC connection takes 5~10 seconds and multiple ICE TURN servers fail #61

Open
tyzh-dev opened this issue Dec 19, 2023 · 8 comments
Open

Comments

@tyzh-dev
Copy link

tyzh-dev commented Dec 19, 2023

Last week my code did work but currently multiple WebRTC signalling server seems to be broken. Which means I can messages send to other peers arrive with a 10 second delay. I assume it may be related to the simple-peer-light WebRTC dependency.

Code:

const createRoom = (roomConfig: BaseRoomConfig, roomId: string) => {
  return joinRoom(roomConfig, roomId);
};
const roomConfig = {
  appId: '<Your APP ID here>',
};
const roomId = <Your ROOM ID here>;
const room = createRoom(roomConfig, roomId);
room.onPeerJoin(peerId => console.log(`${peerId} joined`));

Reproducible example:

  1. Create a room.
  2. Let 1 user join the room.
  3. Let another user join the same room.

Expected behaviour:
Users in the same room get an update of the joined users.

Current behaviour:
ICE Turn Server failed. Multiple ICE TURN servers seem to fail until it finally succeeds with a backup server.
image
image

Extra details

I've tried different internet networks (Netherlands - EU):

  • home network
  • work network
  • 4G network

Room providers:

  • IPFS
  • BitTorrent
  • FireBase

trystero version

  • 0.16.0

OS:

  • MacOS 14.0

Browsers:

  • Edge
  • Safari
  • LibreWolf (hardened FireFox)
  • Chrome
@tyzh-dev tyzh-dev changed the title WebRTC ICE TURN servers failed WebRTC connection takes a long time and multiple ICE TURN servers fail Dec 19, 2023
@tyzh-dev tyzh-dev changed the title WebRTC connection takes a long time and multiple ICE TURN servers fail WebRTC connection takes ~10 seconds and multiple ICE TURN servers fail Dec 19, 2023
@dmotz
Copy link
Owner

dmotz commented Dec 20, 2023

I'm not seeing any issues with the ICE servers right now... are you still having issues? It looks like most of the errors in your console screenshots are problems connecting to IPFS/libp2p bootstrap nodes which is expected. The IPFS strategy is also usually the slowest to connect. I have seen an issue once where one of the ICE servers goes down and it breaks connection entirely, so that's something I'd like to make more robust. You can specify your own ICE server config in Trystero, passing a list of both STUN and TURN servers (the latter are used for peers that can't connect directly).

const room = joinRoom({
  appId: 'yourAppId',
  rtcConfig: {
    iceServers: [
      {
        urls: 'stun:relay.metered.ca:80'
      },
      {
        urls: 'turn:relay.metered.ca:80',
        username: 'your-turn-server-username',
        credential: 'your-turn-server-password'
      },
      {
        urls: 'turn:relay.metered.ca:443',
        username: 'your-turn-server-username',
        credential: 'your-turn-server-password'
      },
      {
        urls: 'turn:relay.metered.ca:443?transport=tcp',
        username: 'your-turn-server-username',
        credential: 'your-turn-server-password'
      }
    ]
  }
})

@tyzh-dev
Copy link
Author

tyzh-dev commented Dec 21, 2023

I'm not seeing any issues with the ICE servers right now... are you still having issues? It looks like most of the errors in your console screenshots are problems connecting to IPFS/libp2p bootstrap nodes which is expected. The IPFS strategy is also usually the slowest to connect. I have seen an issue once where one of the ICE servers goes down and it breaks connection entirely, so that's something I'd like to make more robust.

Thanks for your quick reply. I don't think it is related to IPFS, I was able to reproduce this with FireBase and BitTorrent as joinRoom providers. Last week the response time used to be 1 second but this week, there seem to be server outages with the WebRTC relay servers which cause the connection time to go up to 10 seconds.

The response time is 1 second if I use two tabs in the same browser, however when I use two different browsers to connect or an incognito tab I can reproduce the 10 second problem.

May I ask which ICE Turn server Trystero uses? Does Trystero use the same default as simple-peer-light?

Maybe it is just a coincidence and a temporary issue?
I'll continue monitoring my application and keep this issue up to date if I find more information.

@tyzh-dev tyzh-dev changed the title WebRTC connection takes ~10 seconds and multiple ICE TURN servers fail WebRTC connection takes 5~10 seconds and multiple ICE TURN servers fail Dec 22, 2023
@dmotz
Copy link
Owner

dmotz commented Dec 23, 2023

Yes, same defaults as simple-peer-light:

iceServers: [
  {
    urls: [
      'stun:stun.l.google.com:19302',
      'stun:global.stun.twilio.com:3478'
    ]
  }
]

I'd like to:
a. Make Trystero's default ICE list more robust
b. Swap out the simple-peer-light dependency for a more recent, better maintained WebRTC abstraction library (or possibly roll one from scratch in Trystero itself)

Let me know if you have ideas/input for either.

@tyzh-dev
Copy link
Author

tyzh-dev commented Jan 2, 2024

a. I found the following options:

  1. Open Relay is an interesting option: https://www.metered.ca/tools/openrelay/.
  2. peerjs uses this default config:
const DEFAULT_CONFIG = {
  iceServers: [
  { urls: "stun:stun.l.google.com:19302" },
  {
    urls: [
      "turn:eu-0.turn.peerjs.com:3478",
      "turn:us-0.turn.peerjs.com:3478",
    ],
    username: "peerjs",
    credential: "peerjsp",
    },
  ],
  sdpSemantics: "unified-plan",
};
  1. Selfhosted server as an option. e.g: https://github.com/peers/peerjs-server. I am not sure if this is compatible with trystero. If it "just works", this can be offered as an alternative to the default config.
  2. More options: https://gist.github.com/zziuni/3741933

I recommend looking at option 1 and 3.

b. Swapping out simple-peer-light doesn't seem like an easy option for the following reasons:

  1. Alternatives that are maintained like peerjs have 10x the bundle size of simple-peer-light.
  2. Alternative libraries may not have the same feature parity as simple-peer-light
  3. Alternative libraries may have a different syntax which may require a considerable refactor.
  4. Maintaining your own WebRTC library may increase the maintenance burden.

Another thing to consider in the future might be to choose a server closest to the clients location to reduce latency but that will introduce the complexity of this library. I suggest opening a separate issue for that if we want to consider this in the future.

@rogersanick
Copy link

One thing to note - I'm having bundle issues with simple-peer-light related to esm support. I actually had to fork Trystero and switch the dep to the latest simple-peer.

To further complicate things, it looks like simple-peer hasn't been updated in two years.

@tyzh-dev
Copy link
Author

@rogersanick which bundler are you using?

@rogersanick
Copy link

@tony1658 - I'm using nextjs + webpack

@molvqingtai
Copy link

Yes, same defaults as simple-peer-light:

iceServers: [
  {
    urls: [
      'stun:stun.l.google.com:19302',
      'stun:global.stun.twilio.com:3478'
    ]
  }
]

I'd like to: a. Make Trystero's default ICE list more robust b. Swap out the simple-peer-light dependency for a more recent, better maintained WebRTC abstraction library (or possibly roll one from scratch in Trystero itself)

Let me know if you have ideas/input for either.

Maybe use https://github.com/matallui/artico instead of simple-peer

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants