Relay Server over TCP

[paullouisageneau]

Relay Server over TCP

[paullouisageneau]

Hi,

Setting a STUN server won't have any impact on TCP candidates, you should always get direct TCP candidates.
It's not normal that you can't get TURN-TCP candidates, libnice should support it, at least according to the documentation. What TURN server have you tried with? Does it have TCP support enabled?

[murat-dogan]

I am using coturn server & yes TCP enabled.

[paullouisageneau]

It might be a libnice issue then. I'll do some tests on my side.

[paullouisageneau]

@murat-dogan Do you get TCP relay candidates on this test page?
https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/

[murat-dogan]

No all of them is UDP.
It is strange.

[murat-dogan]

I opened an issue at libnice for that.

There is another ICE implementation library called pjsip,
It is clearly written that they support Turn TCP connection at here.
https://trac.pjsip.org/repos/wiki/get-around-nat-blocked-traffic-filtering

I don't know exact situation for libnice.

[paullouisageneau]

OK, for reference: https://gitlab.freedesktop.org/libnice/libnice/issues/97

PJNATH (the ICE tools part from PJSIP) looks good and feature-complete, however it's under GPL, which means integrating it would require changing the license from LGPL to GPL.

[murat-dogan]

Did you have any time to investigate for this subject?
What do you think , Is libnice support this feature?

For PJSIP;
I compiled their iceserver sample located in pjsip-apps/bin/samples/x86_64-unknown-linux-gnu.

Tried to get Turn Relay TCP Candidates, but could not.
I changed turn server & tried again, but got same result.

I am stuck.

I think I am missing something basic but could not figured out yet.

[paullouisageneau]

Yes, since it didn't work I dug up a bit.

It appears RFC 5766, the original TURN specification, only considers TCP and TLS/TCP as a way to contact a TURN server. Data relayed between peers is always over TCP (see https://tools.ietf.org/html/rfc5766#section-2.1), and the extension for TURN TCP relaying between peers seems to have stayed an abandoned draft which doesn't seem to be widely implemented: https://tools.ietf.org/html/draft-ietf-behave-turn-tcp-07

The only use case where WebRTC officially supports ICE TCP is browser-to-server with active TCP candidates on browser side, browser-to-browser (and therefore browser-to-browser via relay) are not supported.

Sadly for your use case, this means TURN TCP relay candidates might not be supported in a lot of situations. Anyway, you could get the same result with secure websockets with far less useless overhead, couldn't you?

[paullouisageneau]

TCP relay candidates seem to be implemented in coturn, so what's missing here is more precisely TCP relay support in libnice. However, for browser support I think it'd be another story entirely.

[murat-dogan]

Yes, since it didn't work I dug up a bit.

It appears RFC 5766, the original TURN specification, only considers TCP and TLS/TCP as a way to contact a TURN server. Data relayed between peers is always over TCP (see https://tools.ietf.org/html/rfc5766#section-2.1), and the extension for TURN TCP relaying between peers seems to have stayed an abandoned draft which doesn't seem to be widely implemented: https://tools.ietf.org/html/draft-ietf-behave-turn-tcp-07

The only use case where WebRTC officially supports ICE TCP is browser-to-server with active TCP candidates on browser side, browser-to-browser (and therefore browser-to-browser via relay) are not supported.

Sadly for your use case, this means TURN TCP relay candidates might not be supported in a lot of situations. Anyway, you could get the same result with secure websockets with far less useless overhead, couldn't you?

Thanks for comments. I will investigate another way. Maybe websocket.

[murat-dogan]

You can close the issue

[paullouisageneau]

OK ! I think websockets are especially interesting if you combine signaling and relaying over the same connection.