[jitsi-dev] Using JVB behind a firewall that only accepts encrypted data


#1

Hi,

In yesterdays call, we've discussed a setup where the JVB is behind a
restrictive firewall, that only accepts SSL traffic.

As Chrome won't do encryption-over-ICE, Emil suggested trying to use an old
(no longer used, but likely still supported) environment configuration, in
which a second server (next to the JVB) is used, that supplies TURN (which,
unlike ICE, _does_ support encryption).

How exactly is this configured? Someone yesterday hinted that no
configuration changes would be required for the JVB.

Are the config changes limited to jitsi-meet? I've found these config.js
options that seem relevant:

To look-up STUN and/or TURN servers via XEP-0215:

    useStunTurn: true,

To hardcode a set of servers (does this also allow TURN servers, as the
name of the property implies STUN-only?):

    stunServers: [
        { urls: 'stun:stun.l.google.com:19302' },
        { urls: 'stun:stun1.l.google.com:19302' },
        { urls: 'stun:stun2.l.google.com:19302' }
    ],

These options appear on the root level, as well as in a p2p attribute. The
latter is likely related to p2p, so I think I should define these on the
root level.

Is this all configuration that's needed? Is the JVB privvy to this
configuration (does it know where to get the media, as it's informed by
focus)?

Am I on the right track here? Any pointers?

Thanks!

  Guus


#2

Hi Guus,

You probably don’t want to use the hardcoded `stunServers` set because then you would have to include the TURN credentials and then anybody would be able to connect to your TURN servers and use the bandwidth you’re paying.

You need to use the `useStunTurn` root level config option. This will fetch the TURN servers from prosody. You can configure prosody and coturn to use a shared key to generate short-lived TURN credentials.

There’s some documentation available here as to how TURN support works https://github.com/jitsi/jitsi-meet/blob/master/doc/turn.md. The document is around p2p TURN support but some things can be used generally.

Best,
George

···

On Dec 5, 2017, at 3:13 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Hi,

In yesterdays call, we've discussed a setup where the JVB is behind a restrictive firewall, that only accepts SSL traffic.

As Chrome won't do encryption-over-ICE, Emil suggested trying to use an old (no longer used, but likely still supported) environment configuration, in which a second server (next to the JVB) is used, that supplies TURN (which, unlike ICE, _does_ support encryption).

How exactly is this configured? Someone yesterday hinted that no configuration changes would be required for the JVB.

Are the config changes limited to jitsi-meet? I've found these config.js options that seem relevant:

To look-up STUN and/or TURN servers via XEP-0215:

    useStunTurn: true,

To hardcode a set of servers (does this also allow TURN servers, as the name of the property implies STUN-only?):

    stunServers: [
        { urls: 'stun:stun.l.google.com:19302 <http://stun.l.google.com:19302/>' },
        { urls: 'stun:stun1.l.google.com:19302 <http://stun1.l.google.com:19302/>' },
        { urls: 'stun:stun2.l.google.com:19302 <http://stun2.l.google.com:19302/>' }
    ],

These options appear on the root level, as well as in a p2p attribute. The latter is likely related to p2p, so I think I should define these on the root level.

Is this all configuration that's needed? Is the JVB privvy to this configuration (does it know where to get the media, as it's informed by focus)?

Am I on the right track here? Any pointers?

Thanks!

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


#3

Hi Guus, George,

···

On 05/12/2017 10:45, George Politis wrote:
> Hi Guus,
>
> You probably don’t want to use the hardcoded `stunServers` set because
> then you would have to include the TURN credentials and then anybody
> would be able to connect to your TURN servers and use the bandwidth
> you’re paying.
Testing with long term credentials is probably going to be easier. Would it just work by adding an entry to config.stunServers?

Regards,
Boris