[jitsi-dev] Trying to use XEP-0215


#1

Hi guys,

Disclaimer: I am aware that a TURN server is typically not used in
combination with JVB. Given the extraordinary network setup that I'm
working with, Emil advised me to try using one anyway.

I'm trying to use XEP-0215 to allow Meet to figure out where my TURN
(coturn) server is. So far, I'm seeing that the XEP-0215 query (over XMPP)
indeed occurs. When I had an error in that implementation, there were
corresponding warnings in the javascript console - so Meet does appear to
"do something".

At this stage, I was expecting to see 'relay' type ice candidate when
setting up a conversation. I don't. I'm not seeing any interaction with the
TURN server at all, really.

What am I missing?

Regards,

  Guus


#2

Is the TURN server listed in 'iceServers' in webrtc-internals?

Boris

···

On 22/01/2018 14:50, Guus der Kinderen wrote:

Hi guys,

Disclaimer: I am aware that a TURN server is typically not used in combination with JVB. Given the extraordinary network setup that I'm working with, Emil advised me to try using one anyway.

I'm trying to use XEP-0215 to allow Meet to figure out where my TURN (coturn) server is. So far, I'm seeing that the XEP-0215 query (over XMPP) indeed occurs. When I had an error in that implementation, there were corresponding warnings in the javascript console - so Meet does appear to "do something".

At this stage, I was expecting to see 'relay' type ice candidate when setting up a conversation. I don't. I'm not seeing any interaction with the TURN server at all, really.


#3

On top of the tab that pops up when a meet is established, this is listed:

https://example.org:7443/ofmeet/WiseWeaselsRejoiceOften, { iceServers:
[turn:stun.example.org:5349], iceTransportPolicy: all, bundlePolicy:
balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced:
[{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}

(I've replaced the true domain name with example.org)

···

On 22 January 2018 at 22:57, Boris Grozev <boris@jitsi.org> wrote:

On 22/01/2018 14:50, Guus der Kinderen wrote:

Hi guys,

Disclaimer: I am aware that a TURN server is typically not used in
combination with JVB. Given the extraordinary network setup that I'm
working with, Emil advised me to try using one anyway.

I'm trying to use XEP-0215 to allow Meet to figure out where my TURN
(coturn) server is. So far, I'm seeing that the XEP-0215 query (over XMPP)
indeed occurs. When I had an error in that implementation, there were
corresponding warnings in the javascript console - so Meet does appear to
"do something".

At this stage, I was expecting to see 'relay' type ice candidate when
setting up a conversation. I don't. I'm not seeing any interaction with the
TURN server at all, really.

Is the TURN server listed in 'iceServers' in webrtc-internals?

Boris


#4

On top of the tab that pops up when a meet is established, this is listed:

https://example.org:7443/ofmeet/WiseWeaselsRejoiceOften, { iceServers:
[turn:stun.example.org:5349], iceTransportPolicy: all, bundlePolicy:
balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced: [{
googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}

(I've replaced the true domain name with example.org)

···

On 22 January 2018 at 22:57, Boris Grozev <boris@jitsi.org> wrote:

On 22/01/2018 14:50, Guus der Kinderen wrote:

Hi guys,

Disclaimer: I am aware that a TURN server is typically not used in
combination with JVB. Given the extraordinary network setup that I'm
working with, Emil advised me to try using one anyway.

I'm trying to use XEP-0215 to allow Meet to figure out where my TURN
(coturn) server is. So far, I'm seeing that the XEP-0215 query (over XMPP)
indeed occurs. When I had an error in that implementation, there were
corresponding warnings in the javascript console - so Meet does appear to
"do something".

At this stage, I was expecting to see 'relay' type ice candidate when
setting up a conversation. I don't. I'm not seeing any interaction with the
TURN server at all, really.

Is the TURN server listed in 'iceServers' in webrtc-internals?

Boris


#5

My earlier problem was of my own doing (I used an invalid host name,
embarrassingly).

I appear now to be successfully relaying media via coturn. My next
challenge is to force that media to be encrypted, over TCP. I have modified
the XEP-0215 entry to explicitly mention the type "TURNS" and include the
transport "TCP". When establishing a video conference, the following is
displayed in chrome://webrtc-internals/ :

https://example.org:7443/ofmeet/ScornfulClownsMoveBriskly, { iceServers:
[turns:turn.example.org:5349?transport=tcp], iceTransportPolicy: all,
bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 },
{advanced: [{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}

All looks well, until I explicitly configure coturn to not accept any
traffic except for TLS (using its --no-udp-relay --no-tcp --no-udp
--no-dtls flags). Now, when I try to establish a meet, things fail, with
coturn logging things like this:

794: session 001000000000000009: realm <testrealm> user <>: incoming packet
message processed, error 401: Unauthorized
794: session 001000000000000009: realm <testrealm> user <a8nglf1p95%
40example.org:1516899496>: incoming packet ALLOCATE processed, error 442:
UDP Transport is not allowed by the TURN Server configuration
794: session 001000000000000009: realm <testrealm> user <a8nglf1p95%
40example.org:1516899496>: incoming packet message processed, error 442:
UDP Transport is not allowed by the TURN Server configuration

For some reason, UDP is still used. How can I force the meet client to use
TCP?

Regards,

  Guus

···

On 22 January 2018 at 23:10, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

On top of the tab that pops up when a meet is established, this is listed:

https://example.org:7443/ofmeet/WiseWeaselsRejoiceOften, { iceServers:
[turn:stun.example.org:5349], iceTransportPolicy: all, bundlePolicy:
balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced:
[{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}

(I've replaced the true domain name with example.org)

On 22 January 2018 at 22:57, Boris Grozev <boris@jitsi.org> wrote:

On 22/01/2018 14:50, Guus der Kinderen wrote:

Hi guys,

Disclaimer: I am aware that a TURN server is typically not used in
combination with JVB. Given the extraordinary network setup that I'm
working with, Emil advised me to try using one anyway.

I'm trying to use XEP-0215 to allow Meet to figure out where my TURN
(coturn) server is. So far, I'm seeing that the XEP-0215 query (over XMPP)
indeed occurs. When I had an error in that implementation, there were
corresponding warnings in the javascript console - so Meet does appear to
"do something".

At this stage, I was expecting to see 'relay' type ice candidate when
setting up a conversation. I don't. I'm not seeing any interaction with the
TURN server at all, really.

Is the TURN server listed in 'iceServers' in webrtc-internals?

Boris


#6

You can use passing #config.webrtcIceUdpDisable=true.

···

On Wed, Jan 24, 2018 at 11:01 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

My earlier problem was of my own doing (I used an invalid host name,
embarrassingly).

I appear now to be successfully relaying media via coturn. My next challenge
is to force that media to be encrypted, over TCP. I have modified the
XEP-0215 entry to explicitly mention the type "TURNS" and include the
transport "TCP". When establishing a video conference, the following is
displayed in chrome://webrtc-internals/ :

https://example.org:7443/ofmeet/ScornfulClownsMoveBriskly, { iceServers:
[turns:turn.example.org:5349?transport=tcp], iceTransportPolicy: all,
bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 },
{advanced: [{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}

All looks well, until I explicitly configure coturn to not accept any
traffic except for TLS (using its --no-udp-relay --no-tcp --no-udp --no-dtls
flags). Now, when I try to establish a meet, things fail, with coturn
logging things like this:

794: session 001000000000000009: realm <testrealm> user <>: incoming packet
message processed, error 401: Unauthorized
794: session 001000000000000009: realm <testrealm> user
<a8nglf1p95%40example.org:1516899496>: incoming packet ALLOCATE processed,
error 442: UDP Transport is not allowed by the TURN Server configuration
794: session 001000000000000009: realm <testrealm> user
<a8nglf1p95%40example.org:1516899496>: incoming packet message processed,
error 442: UDP Transport is not allowed by the TURN Server configuration

For some reason, UDP is still used. How can I force the meet client to use
TCP?

Regards,

  Guus

On 22 January 2018 at 23:10, Guus der Kinderen <guus.der.kinderen@gmail.com> > wrote:

On top of the tab that pops up when a meet is established, this is listed:

https://example.org:7443/ofmeet/WiseWeaselsRejoiceOften, { iceServers:
[turn:stun.example.org:5349], iceTransportPolicy: all, bundlePolicy:
balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced:
[{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}

(I've replaced the true domain name with example.org)

On 22 January 2018 at 22:57, Boris Grozev <boris@jitsi.org> wrote:

On 22/01/2018 14:50, Guus der Kinderen wrote:

Hi guys,

Disclaimer: I am aware that a TURN server is typically not used in
combination with JVB. Given the extraordinary network setup that I'm working
with, Emil advised me to try using one anyway.

I'm trying to use XEP-0215 to allow Meet to figure out where my TURN
(coturn) server is. So far, I'm seeing that the XEP-0215 query (over XMPP)
indeed occurs. When I had an error in that implementation, there were
corresponding warnings in the javascript console - so Meet does appear to
"do something".

At this stage, I was expecting to see 'relay' type ice candidate when
setting up a conversation. I don't. I'm not seeing any interaction with the
TURN server at all, really.

Is the TURN server listed in 'iceServers' in webrtc-internals?

Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#7

I would look into this some more to figure out exactly what is going on.

Perhaps the client connects to the TURN server via TLS (as it should, given the url it is given) but tries to create a UDP allocation (which is prohibited by "--no-udp-relay"). I don't know whether webrtc will ever try to create a TCP allocation.

You can experiment by removing the "--no-udp-relay" option for coturn, or blocking UDP traffic before it reaches coturn.

Regards,
Boris

···

On 24/01/2018 11:01, Guus der Kinderen wrote:
> My earlier problem was of my own doing (I used an invalid host name,
> embarrassingly).
>
> I appear now to be successfully relaying media via coturn. My next
> challenge is to force that media to be encrypted, over TCP. I have
> modified the XEP-0215 entry to explicitly mention the type "TURNS" and
> include the transport "TCP". When establishing a video conference, the
> following is displayed in chrome://webrtc-internals/ :
>
> https://example.org:7443/ofmeet/ScornfulClownsMoveBriskly, { iceServers:
> [turns:turn.example.org:5349?transport=tcp
> <http://turn.example.org:5349?transport=tcp>], iceTransportPolicy: all,
> bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0
> }, {advanced: [{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}
>
> All looks well, until I explicitly configure coturn to not accept any
> traffic except for TLS (using its --no-udp-relay --no-tcp --no-udp
> --no-dtls flags). Now, when I try to establish a meet, things fail, with
> coturn logging things like this:
>
> 794: session 001000000000000009: realm <testrealm> user <>: incoming
> packet message processed, error 401: Unauthorized
> 794: session 001000000000000009: realm <testrealm> user
> <a8nglf1p95%40example.org:1516899496 <http://40example.org:1516899496>>:
> incoming packet ALLOCATE processed, error 442: UDP Transport is not
> allowed by the TURN Server configuration
> 794: session 001000000000000009: realm <testrealm> user
> <a8nglf1p95%40example.org:1516899496 <http://40example.org:1516899496>>:
> incoming packet message processed, error 442: UDP Transport is not
> allowed by the TURN Server configuration
>
> For some reason, UDP is still used. How can I force the meet client to
> use TCP?


#8

Exactly how do I apply that? I have tried the following:

Opening the room with an URL like this:
https://example.org:7443/ofmeet/testroom#config.webrtcIceUdpDisable=true

I've also tried modifying the content of
https://example.org:7443/ofmeet/config.js to contain this:

var config = {
  ...
  "webrtcIceTcpDisable": false,
  "webrtcIceUdpDisable": true,
...
};

These made no difference. The logs from coturn still indicate that the
client tried to send UDP.

···

On 24 January 2018 at 18:32, Damian Minkov <damencho@jitsi.org> wrote:

You can use passing #config.webrtcIceUdpDisable=true.

On Wed, Jan 24, 2018 at 11:01 AM, Guus der Kinderen > <guus.der.kinderen@gmail.com> wrote:
> My earlier problem was of my own doing (I used an invalid host name,
> embarrassingly).
>
> I appear now to be successfully relaying media via coturn. My next
challenge
> is to force that media to be encrypted, over TCP. I have modified the
> XEP-0215 entry to explicitly mention the type "TURNS" and include the
> transport "TCP". When establishing a video conference, the following is
> displayed in chrome://webrtc-internals/ :
>
> https://example.org:7443/ofmeet/ScornfulClownsMoveBriskly, { iceServers:
> [turns:turn.example.org:5349?transport=tcp], iceTransportPolicy: all,
> bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0
},
> {advanced: [{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}
>
> All looks well, until I explicitly configure coturn to not accept any
> traffic except for TLS (using its --no-udp-relay --no-tcp --no-udp
--no-dtls
> flags). Now, when I try to establish a meet, things fail, with coturn
> logging things like this:
>
> 794: session 001000000000000009: realm <testrealm> user <>: incoming
packet
> message processed, error 401: Unauthorized
> 794: session 001000000000000009: realm <testrealm> user
> <a8nglf1p95%40example.org:1516899496>: incoming packet ALLOCATE
processed,
> error 442: UDP Transport is not allowed by the TURN Server configuration
> 794: session 001000000000000009: realm <testrealm> user
> <a8nglf1p95%40example.org:1516899496>: incoming packet message
processed,
> error 442: UDP Transport is not allowed by the TURN Server configuration
>
> For some reason, UDP is still used. How can I force the meet client to
use
> TCP?
>
> Regards,
>
> Guus
>
> On 22 January 2018 at 23:10, Guus der Kinderen < > guus.der.kinderen@gmail.com> > > wrote:
>>
>> On top of the tab that pops up when a meet is established, this is
listed:
>>
>> https://example.org:7443/ofmeet/WiseWeaselsRejoiceOften, { iceServers:
>> [turn:stun.example.org:5349], iceTransportPolicy: all, bundlePolicy:
>> balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced:
>> [{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}
>>
>> (I've replaced the true domain name with example.org)
>>
>> On 22 January 2018 at 22:57, Boris Grozev <boris@jitsi.org> wrote:
>>>
>>> On 22/01/2018 14:50, Guus der Kinderen wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> Disclaimer: I am aware that a TURN server is typically not used in
>>>> combination with JVB. Given the extraordinary network setup that I'm
working
>>>> with, Emil advised me to try using one anyway.
>>>>
>>>> I'm trying to use XEP-0215 to allow Meet to figure out where my TURN
>>>> (coturn) server is. So far, I'm seeing that the XEP-0215 query (over
XMPP)
>>>> indeed occurs. When I had an error in that implementation, there were
>>>> corresponding warnings in the javascript console - so Meet does
appear to
>>>> "do something".
>>>>
>>>> At this stage, I was expecting to see 'relay' type ice candidate when
>>>> setting up a conversation. I don't. I'm not seeing any interaction
with the
>>>> TURN server at all, really.
>>>
>>>
>>> Is the TURN server listed in 'iceServers' in webrtc-internals?
>>>
>>> Boris
>>
>>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#9

Boris, you were right.

The remainder of this text is an elaborate attempt to explain to myself
(and posterity) _why_ you were right. TL;DR: Always listen to Boris.

I failed to recognize that with TURN, not one, but two types of 'transport'
are associated to an allocation:

   - the transport type between the TURN client and the TURN server,
   - but also the 'request transport' that refers to the transport type
   between the TURN server and the peers.

RFC5766 describes that the former can be any of UDP, TCP, or TLS-over-TCP,
while the latter can only be UDP (although RFC6062 specifies TCP). Coturns
'--no-udp-relay' option refers to the latter.

All of the Meet / webrtc clients receive the same configuration. It appears
that each creates a TURN-client connection to the TURN server. Presumably,
the TURN server 'relays' both connections into each-other. As this occurs
within the TURN server itself, and I'm primarily interested in the type of
data that flows through the firewall, it is of little importance to me what
protocol is used to relay data. I have no need to set either
'--no-udp-relay' or '--no-tcp-relay'.

From what I can find online, webrtc doesn't allow for TCP between the TURN

server and the peers (but does allow for it between the client and the TURN
server). This is likely why adding the '--no-udp-relay' option to coturn
prevented the setup from working.

In any case, when tcpdump the connections without the '--no-udp-relay'
option, I'm only seeing TLS-over-TCP styled communication between the
clients and the server, which is exactly what I was after!

Thanks!

···

On 24 January 2018 at 21:18, Boris Grozev <boris@jitsi.org> wrote:

On 24/01/2018 11:01, Guus der Kinderen wrote:
> My earlier problem was of my own doing (I used an invalid host name,
> embarrassingly).
>
> I appear now to be successfully relaying media via coturn. My next
> challenge is to force that media to be encrypted, over TCP. I have
> modified the XEP-0215 entry to explicitly mention the type "TURNS" and
> include the transport "TCP". When establishing a video conference, the
> following is displayed in chrome://webrtc-internals/ :
>
> https://example.org:7443/ofmeet/ScornfulClownsMoveBriskly, { iceServers:
> [turns:turn.example.org:5349?transport=tcp
> <http://turn.example.org:5349?transport=tcp>], iceTransportPolicy: all,
> bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0
> }, {advanced: [{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}
>
> All looks well, until I explicitly configure coturn to not accept any
> traffic except for TLS (using its --no-udp-relay --no-tcp --no-udp
> --no-dtls flags). Now, when I try to establish a meet, things fail, with
> coturn logging things like this:
>
> 794: session 001000000000000009: realm <testrealm> user <>: incoming
> packet message processed, error 401: Unauthorized
> 794: session 001000000000000009: realm <testrealm> user
> <a8nglf1p95%40example.org:1516899496 <http://40example.org:1516899496>>:
> incoming packet ALLOCATE processed, error 442: UDP Transport is not
> allowed by the TURN Server configuration
> 794: session 001000000000000009: realm <testrealm> user
> <a8nglf1p95%40example.org:1516899496 <http://40example.org:1516899496>>:
> incoming packet message processed, error 442: UDP Transport is not
> allowed by the TURN Server configuration
>
> For some reason, UDP is still used. How can I force the meet client to
> use TCP?
I would look into this some more to figure out exactly what is going on.

Perhaps the client connects to the TURN server via TLS (as it should,
given the url it is given) but tries to create a UDP allocation (which is
prohibited by "--no-udp-relay"). I don't know whether webrtc will ever try
to create a TCP allocation.

You can experiment by removing the "--no-udp-relay" option for coturn, or
blocking UDP traffic before it reaches coturn.

Regards,
Boris


#10

Those options will barely strip any UDP candidates for you, but will
not prevent the WebRTC stack from trying to obtain UDP candidates.
You need to figure out what ICE config options have to be used in
order to make WebRTC stack use only TLS. Then next step would be to
see if lib-jitsi-meet
currently provides a way for overriding those. If you see that in the
webrtc-internals iceServer is specified with turns and tcp then you
know it was passed to the WebRTC like that.

···

On Wed, Jan 24, 2018 at 12:42 PM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Exactly how do I apply that? I have tried the following:

Opening the room with an URL like this:
https://example.org:7443/ofmeet/testroom#config.webrtcIceUdpDisable=true

I've also tried modifying the content of
https://example.org:7443/ofmeet/config.js to contain this:

var config = {
  ...
  "webrtcIceTcpDisable": false,
  "webrtcIceUdpDisable": true,
...
};

These made no difference. The logs from coturn still indicate that the
client tried to send UDP.

On 24 January 2018 at 18:32, Damian Minkov <damencho@jitsi.org> wrote:

You can use passing #config.webrtcIceUdpDisable=true.

On Wed, Jan 24, 2018 at 11:01 AM, Guus der Kinderen >> <guus.der.kinderen@gmail.com> wrote:
> My earlier problem was of my own doing (I used an invalid host name,
> embarrassingly).
>
> I appear now to be successfully relaying media via coturn. My next
> challenge
> is to force that media to be encrypted, over TCP. I have modified the
> XEP-0215 entry to explicitly mention the type "TURNS" and include the
> transport "TCP". When establishing a video conference, the following is
> displayed in chrome://webrtc-internals/ :
>
> https://example.org:7443/ofmeet/ScornfulClownsMoveBriskly, { iceServers:
> [turns:turn.example.org:5349?transport=tcp], iceTransportPolicy: all,
> bundlePolicy: balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0
> },
> {advanced: [{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}
>
> All looks well, until I explicitly configure coturn to not accept any
> traffic except for TLS (using its --no-udp-relay --no-tcp --no-udp
> --no-dtls
> flags). Now, when I try to establish a meet, things fail, with coturn
> logging things like this:
>
> 794: session 001000000000000009: realm <testrealm> user <>: incoming
> packet
> message processed, error 401: Unauthorized
> 794: session 001000000000000009: realm <testrealm> user
> <a8nglf1p95%40example.org:1516899496>: incoming packet ALLOCATE
> processed,
> error 442: UDP Transport is not allowed by the TURN Server configuration
> 794: session 001000000000000009: realm <testrealm> user
> <a8nglf1p95%40example.org:1516899496>: incoming packet message
> processed,
> error 442: UDP Transport is not allowed by the TURN Server configuration
>
> For some reason, UDP is still used. How can I force the meet client to
> use
> TCP?
>
> Regards,
>
> Guus
>
> On 22 January 2018 at 23:10, Guus der Kinderen >> > <guus.der.kinderen@gmail.com> >> > wrote:
>>
>> On top of the tab that pops up when a meet is established, this is
>> listed:
>>
>> https://example.org:7443/ofmeet/WiseWeaselsRejoiceOften, { iceServers:
>> [turn:stun.example.org:5349], iceTransportPolicy: all, bundlePolicy:
>> balanced, rtcpMuxPolicy: require, iceCandidatePoolSize: 0 }, {advanced:
>> [{googEnableVideoSuspendBelowMinBitrate: {exact: true}}]}
>>
>> (I've replaced the true domain name with example.org)
>>
>> On 22 January 2018 at 22:57, Boris Grozev <boris@jitsi.org> wrote:
>>>
>>> On 22/01/2018 14:50, Guus der Kinderen wrote:
>>>>
>>>> Hi guys,
>>>>
>>>> Disclaimer: I am aware that a TURN server is typically not used in
>>>> combination with JVB. Given the extraordinary network setup that I'm
>>>> working
>>>> with, Emil advised me to try using one anyway.
>>>>
>>>> I'm trying to use XEP-0215 to allow Meet to figure out where my TURN
>>>> (coturn) server is. So far, I'm seeing that the XEP-0215 query (over
>>>> XMPP)
>>>> indeed occurs. When I had an error in that implementation, there were
>>>> corresponding warnings in the javascript console - so Meet does
>>>> appear to
>>>> "do something".
>>>>
>>>> At this stage, I was expecting to see 'relay' type ice candidate when
>>>> setting up a conversation. I don't. I'm not seeing any interaction
>>>> with the
>>>> TURN server at all, really.
>>>
>>>
>>> Is the TURN server listed in 'iceServers' in webrtc-internals?
>>>
>>> Boris
>>
>>
>
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#11

Hey Guus,

···

On 26/01/2018 07:33, Guus der Kinderen wrote:

Boris, you were right.

The remainder of this text is an elaborate attempt to explain to myself (and posterity) _why_ you were right. TL;DR: Always listen to Boris.

I failed to recognize that with TURN, not one, but two types of 'transport' are associated to an allocation:

  * the transport type between the TURN client and the TURN server,
  * but also the 'request transport' that refers to the transport type
    between the TURN server and the peers.

RFC5766 describes that the former can be any of UDP, TCP, or TLS-over-TCP, while the latter can only be UDP (although RFC6062 specifies TCP). Coturns '--no-udp-relay' option refers to the latter.

All of the Meet / webrtc clients receive the same configuration. It appears that each creates a TURN-client connection to the TURN server. Presumably, the TURN server 'relays' both connections into each-other. As this occurs within the TURN server itself, and I'm primarily interested in the type of data that flows through the firewall, it is of little importance to me what protocol is used to relay data. I have no need to set either '--no-udp-relay' or '--no-tcp-relay'.

From what I can find online, webrtc doesn't allow for TCP between the TURN server and the peers (but does allow for it between the client and the TURN server). This is likely why adding the '--no-udp-relay' option to coturn prevented the setup from working.

In any case, when tcpdump the connections without the '--no-udp-relay' option, I'm only seeing TLS-over-TCP styled communication between the clients and the server, which is exactly what I was after!

Glad to hear that you found a solution! This means that you have the client-TURN-bridge scenario working without any modifications apart from configuring the TURN server in the client, right? That's good to know!

Regards,
Boris


#12

Yes, it does.

···

On 26 Jan 2018 19:50, "Boris Grozev" <boris@jitsi.org> wrote:

Hey Guus,

On 26/01/2018 07:33, Guus der Kinderen wrote:

Boris, you were right.

The remainder of this text is an elaborate attempt to explain to myself
(and posterity) _why_ you were right. TL;DR: Always listen to Boris.

I failed to recognize that with TURN, not one, but two types of
'transport' are associated to an allocation:

  * the transport type between the TURN client and the TURN server,
  * but also the 'request transport' that refers to the transport type
    between the TURN server and the peers.

RFC5766 describes that the former can be any of UDP, TCP, or
TLS-over-TCP, while the latter can only be UDP (although RFC6062 specifies
TCP). Coturns '--no-udp-relay' option refers to the latter.

All of the Meet / webrtc clients receive the same configuration. It
appears that each creates a TURN-client connection to the TURN server.
Presumably, the TURN server 'relays' both connections into each-other. As
this occurs within the TURN server itself, and I'm primarily interested in
the type of data that flows through the firewall, it is of little
importance to me what protocol is used to relay data. I have no need to set
either '--no-udp-relay' or '--no-tcp-relay'.

From what I can find online, webrtc doesn't allow for TCP between the
TURN server and the peers (but does allow for it between the client and the
TURN server). This is likely why adding the '--no-udp-relay' option to
coturn prevented the setup from working.

In any case, when tcpdump the connections without the '--no-udp-relay'
option, I'm only seeing TLS-over-TCP styled communication between the
clients and the server, which is exactly what I was after!

Glad to hear that you found a solution! This means that you have the
client-TURN-bridge scenario working without any modifications apart from
configuring the TURN server in the client, right? That's good to know!

Regards,
Boris