triniwiz / nativescript-webrtc

Apache License 2.0
42 stars 25 forks source link

Detect if connection uses TURN or P2P #44

Open abhayastudios opened 4 years ago

abhayastudios commented 4 years ago

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 commented 3 years ago

@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 commented 3 years ago

It should fixed in native I feel

abhayastudios commented 3 years ago

@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 commented 3 years ago

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

abhayastudios commented 3 years ago

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

MattCCC commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

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));
});