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

Detect if connection uses TURN or P2P #44

Open
abhayastudios opened this issue Jul 3, 2020 · 8 comments
Open

Detect if connection uses TURN or P2P #44

abhayastudios opened this issue Jul 3, 2020 · 8 comments

Comments

@abhayastudios
Copy link
Contributor

abhayastudios commented Jul 3, 2020

Hey @triniwiz,

I am using the alpha22 branch and am having trouble setting up connections between peers that are both behind a NAT. When I forward all UDP traffic on the router of one of sides to the specific device then it works fine.

I guess this is expected behaviour when using only STUN, so I am now using Twilio's NAT Traversal Services which also includes various TURN servers options, but that also does not work. So to try and debug the issue, I was wondering whether we have a way of knowing whether the connection chose a TURN server as I would expect in this case?

Also I am trying to register to the state change events on Android and data channel events which do not fire at all. Registering to these events causes the app to hang on Android. Any idea why?

    this.connection = new TNSRTCPeerConnection(this.config);
    this.connection.onIceCandidate((candidate) => {
      // works fine!
    });

    this.connection.onTrack((track) => {
      // works fine!
    });

    this.connection.onConnectionStateChange(() => {
      // doesn't fire on Android (iOS is fine)
      console.log('onConnectionStateChange: '+this.connection.connectionState);
    });

    this.connection.onDataChannel((channel:any) => {
      // doesn't fire on either Android or iOS
      console.log('onDataChannel');
      console.dir(channel);
    });

@abhayastudios
Copy link
Contributor Author

@triniwiz Hey man! I asked my friend to have a look at this issue where the plugin works fine for asymmetric NAT or local network but not for symmetric NAT. He found that in all demo projects (incl your non-angular), that the ice candidates from peer are coming in before the remote description is set, which is not a problem for local connections as they do not need them. The demo of your native library Fancy-WebRTC for Android sets them in the correct order.

We can of course update the demos and the docs, but don't you think this order should somewhat be guarded in the native libraries?

Please advice how you think this should be fixed.
Thanks!

@triniwiz
Copy link
Owner

triniwiz commented Jun 8, 2021

It should fixed in native I feel

@abhayastudios
Copy link
Contributor Author

@triniwiz do you think this is something that you could fix sometime soon? We can fix the NS plugin demos in the meantime but the native part is out of my league.

@triniwiz
Copy link
Owner

triniwiz commented Jun 8, 2021

I have some local updates laying around for this plugin to update the android package so I'll add those in also

@abhayastudios
Copy link
Contributor Author

ok thanks, please let us know when you do it. Note that this same issue exists also on the iOS version.

@MattCCC
Copy link

MattCCC commented Aug 1, 2021

Hi, thank you for great plugin. We're trying to use data channels and I think we've the same issue with my friend. Basically seems data channels don't work at all. onDataChannel isn't triggered at all. Any updates on this one? How could we possibly fix it? Are there any workarounds?

@abhayastudios
Copy link
Contributor Author

@MattCCC are you also experiencing the issue with symmetric NAT not working? If so, please see this PR #61 and also this comment above. I am interested to know whether this solves the issue for you as well. Cheers!

@MattCCC
Copy link

MattCCC commented Aug 1, 2021

Thank you for your comment and PR. So in our case it seems to be something else because it doesn't work on android either way. We also applied your PR. It seems like in onDataChannel we don't receive anything. This is how we invoke it all in fact:

const name = 'message';
const dataChannelInit = {};

this.connection = new TNSRTCPeerConnection(this.config);

const channel = this.connection.createDataChannel(name, dataChannelInit);

setTimeout(() => {
	this.webrtc.dataChannelSend('message', 'Test', WebRTCDataChannelMessageType.TEXT);
}, 2500);

this.connection.onDataChannel((channel) => {
	notificationService.make('Pet Store onDataChannel', JSON.stringify(channel));
});

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

3 participants