[jitsi-dev] Inventory of server-sided TCP/IP ports used by the stack


#1

Hi all,

To support firewall configuration, I'm compiling a list of TCP/IP ports
that, under default conditions, are used by the Jitsi stack as we deploy it
(Jitsi Meet webapp, Jicofo & Videobridge).

Could you skim over this, see if I'm making mistakes or missing something?

For *media*:

*UDP 10000*
Single UDP port for multiplexed media streams. (typically most preferred
candidate)

*UDP 5000-6000*
Dynamically allocated UDP ports for media streams (used when multiplexing
is unavailable).

*TCP 443*
Single TCP port for media streams (typically least preferred candidate)

*TCP 4443*
(used when 443 cannot be bound to)

For *signalling*:

*TCP 80 / 443*
Web server that hosts Meet.

*TCP 7443 *(Openfire) *or TCP 5280 *(Prosody)
XMPP BOSH connectivity from both Meet as well as Jicofo (typically
preferred over TCP 5222/5223)

*TCP 5222 or TCP 5223*
XMPP connectivity from both Meet as well as Jicofo (as an alternative to
the BOSH port).

Regards,

  Guus


#2

For media the non-single port mode UDP ports are 10000-20000 afaik. This is really nice, maybe we should include it in manual-install.md?

···

On May 7, 2018, at 2:02 PM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Hi all,

To support firewall configuration, I'm compiling a list of TCP/IP ports that, under default conditions, are used by the Jitsi stack as we deploy it (Jitsi Meet webapp, Jicofo & Videobridge).

Could you skim over this, see if I'm making mistakes or missing something?

For media:

UDP 10000
Single UDP port for multiplexed media streams. (typically most preferred candidate)

UDP 5000-6000
Dynamically allocated UDP ports for media streams (used when multiplexing is unavailable).

TCP 443
Single TCP port for media streams (typically least preferred candidate)

TCP 4443
(used when 443 cannot be bound to)

For signalling:

TCP 80 / 443
Web server that hosts Meet.

TCP 7443 (Openfire) or TCP 5280 (Prosody)
XMPP BOSH connectivity from both Meet as well as Jicofo (typically preferred over TCP 5222/5223)

TCP 5222 or TCP 5223
XMPP connectivity from both Meet as well as Jicofo (as an alternative to the BOSH port).

Regards,

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


#3

Hey Guus and George,

For media the non-single port mode UDP ports are 10000-20000 afaik. This is
really nice, maybe we should include it in manual-install.md?

I think we recently pushed a change in the bridge where if the bridge
was unable to bind to the single port 10000 we report it as unhealthy.
Not sure when the clients can skip the single port option and use the
rest of the ports. Maybe Boris can give more details on this one.

Hi all,

To support firewall configuration, I'm compiling a list of TCP/IP ports
that, under default conditions, are used by the Jitsi stack as we deploy it
(Jitsi Meet webapp, Jicofo & Videobridge).

Could you skim over this, see if I'm making mistakes or missing something?

For media:

UDP 10000
Single UDP port for multiplexed media streams. (typically most preferred
candidate)

UDP 5000-6000
Dynamically allocated UDP ports for media streams (used when multiplexing is
unavailable).

TCP 443
Single TCP port for media streams (typically least preferred candidate)

TCP 4443
(used when 443 cannot be bound to)

For signalling:

TCP 80 / 443
Web server that hosts Meet.

TCP 7443 (Openfire) or TCP 5280 (Prosody)
XMPP BOSH connectivity from both Meet as well as Jicofo (typically preferred
over TCP 5222/5223)

Not sure about openfire, but currently jitsi-meet uses bosh over the
https link already established to the server and from there the
connection is proxied to prosody over the localhost link using port
5280. So nothing to be opened for the world on the firewall.

TCP 5222 or TCP 5223
XMPP connectivity from both Meet as well as Jicofo (as an alternative to the
BOSH port).

Jicofo needs connectivity to port 5222 of the xmpp server, but noone
outside need that port, so if jicofo is on the same machine as the
xmpp server there is no public need for that.

Regards
damencho

···

On Mon, May 7, 2018 at 2:16 PM, George Politis <gp@jitsi.org> wrote:

On May 7, 2018, at 2:02 PM, Guus der Kinderen <guus.der.kinderen@gmail.com> > wrote:

Regards,

  Guus
_______________________________________________
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


#4

*UDP 5000-6000*
Dynamically allocated UDP ports for media streams (used when multiplexing
is unavailable).

Where is this range defined in code?

Thanks,

/Kaiduan

···

On Mon, May 7, 2018 at 3:02 PM, Guus der Kinderen < guus.der.kinderen@gmail.com> wrote:

Hi all,

To support firewall configuration, I'm compiling a list of TCP/IP ports
that, under default conditions, are used by the Jitsi stack as we deploy it
(Jitsi Meet webapp, Jicofo & Videobridge).

Could you skim over this, see if I'm making mistakes or missing something?

For *media*:

*UDP 10000*
Single UDP port for multiplexed media streams. (typically most preferred
candidate)

*UDP 5000-6000*
Dynamically allocated UDP ports for media streams (used when multiplexing
is unavailable).

*TCP 443*
Single TCP port for media streams (typically least preferred candidate)

*TCP 4443*
(used when 443 cannot be bound to)

For *signalling*:

*TCP 80 / 443*
Web server that hosts Meet.

*TCP 7443 *(Openfire) *or TCP 5280 *(Prosody)
XMPP BOSH connectivity from both Meet as well as Jicofo (typically
preferred over TCP 5222/5223)

*TCP 5222 or TCP 5223*
XMPP connectivity from both Meet as well as Jicofo (as an alternative to
the BOSH port).

Regards,

  Guus

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

--
Founder of Goodstartsoft
https://www.goodstartsoft.com


#5

Thanks for all of the feedback!

It'll be interesting to find out if the Dynamically allocated UDP ports for
media streams can be used without the single port that uses multiplexing.
Boris, if you have additional feedback on that, that would be welcome. The
range that I mentioned (5000-6000) comes from an old version of our OFMeet
wrapper, where I assumed that it took the default port range from Jitsi.
This might very well be a misconception on my part. By looking at the
startup script, it appears that the default range in fact is 10001-20000:
https://github.com/jitsi/jitsi-videobridge/blob/master/resources/install/linux/jvb.sh#L8-L9
just like Georg suggested.

As for the BOSH port, Damian is right when he says that meet.jit.si uses
the standard HTTPS port. The network description at
https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md
defines a reverse proxy that allows for this. In our setup, we don't
necessarily deploy a reverse proxy (but we sometimes do use SSLH, for the
same effect). Is there a specific argument for using the reverse proxy?
Although it's nice to tunnel XMPP over the HTTP connection, a network would
still have to open up other ports for the media streams anyway. Given that,
one might argue that the complexity of adding a reverse proxy is at best on
par with the benefit of removing one public port. I'm not sure if it hurts
either way?

Regards,

  Guus

···

On 7 May 2018 at 21:39, Kaiduan Xie <kaiduanx@gmail.com> wrote:

*UDP 5000-6000*
Dynamically allocated UDP ports for media streams (used when multiplexing
is unavailable).

Where is this range defined in code?

Thanks,

/Kaiduan

On Mon, May 7, 2018 at 3:02 PM, Guus der Kinderen < > guus.der.kinderen@gmail.com> wrote:

Hi all,

To support firewall configuration, I'm compiling a list of TCP/IP ports
that, under default conditions, are used by the Jitsi stack as we deploy it
(Jitsi Meet webapp, Jicofo & Videobridge).

Could you skim over this, see if I'm making mistakes or missing something?

For *media*:

*UDP 10000*
Single UDP port for multiplexed media streams. (typically most preferred
candidate)

*UDP 5000-6000*
Dynamically allocated UDP ports for media streams (used when multiplexing
is unavailable).

*TCP 443*
Single TCP port for media streams (typically least preferred candidate)

*TCP 4443*
(used when 443 cannot be bound to)

For *signalling*:

*TCP 80 / 443*
Web server that hosts Meet.

*TCP 7443 *(Openfire) *or TCP 5280 *(Prosody)
XMPP BOSH connectivity from both Meet as well as Jicofo (typically
preferred over TCP 5222/5223)

*TCP 5222 or TCP 5223*
XMPP connectivity from both Meet as well as Jicofo (as an alternative to
the BOSH port).

Regards,

  Guus

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

--
Founder of Goodstartsoft
https://www.goodstartsoft.com

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


#6

I think I've found the origin of the 5000-6000 port range. It is used in
the Openfire plugin, as introduced here:
https://github.com/jitsi/jitsi-videobridge-openfire-plugin/blob/2f12768e6195239685fbf39474c1258f70f0a316/src/java/org/jitsi/videobridge/openfire/PluginImpl.java#L54-L62

This itself seems to be based on code in libjitsi, here:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/service/neomedia/DefaultStreamConnector.java#L104-L121
This, to this day, appears to use 5000-6000 as a default.

In the current implementation of the JVB, it appears that instances of
DefaultStreamConnector are always configured with a different default value
(the 10001-20000 range) here:
https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/Main.java#L140-L143

I'm unsure if it makes sense to update date defaults used in libjitsi to
match those to JVB. Although it makes things a bit more predictable, it
might also introduce issues for other usages of that implementation. In any
case, I've prepared a PR for this in
https://github.com/jitsi/libjitsi/pull/422

···

On 8 May 2018 at 10:13, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Thanks for all of the feedback!

It'll be interesting to find out if the Dynamically allocated UDP ports
for media streams can be used without the single port that uses
multiplexing. Boris, if you have additional feedback on that, that would be
welcome. The range that I mentioned (5000-6000) comes from an old version
of our OFMeet wrapper, where I assumed that it took the default port range
from Jitsi. This might very well be a misconception on my part. By looking
at the startup script, it appears that the default range in fact is
10001-20000: https://github.com/jitsi/jitsi-videobridge/
blob/master/resources/install/linux/jvb.sh#L8-L9 just like Georg
suggested.

As for the BOSH port, Damian is right when he says that meet.jit.si uses
the standard HTTPS port. The network description at
https://github.com/jitsi/jitsi-meet/blob/master/doc/manual-install.md
defines a reverse proxy that allows for this. In our setup, we don't
necessarily deploy a reverse proxy (but we sometimes do use SSLH, for the
same effect). Is there a specific argument for using the reverse proxy?
Although it's nice to tunnel XMPP over the HTTP connection, a network would
still have to open up other ports for the media streams anyway. Given that,
one might argue that the complexity of adding a reverse proxy is at best on
par with the benefit of removing one public port. I'm not sure if it hurts
either way?

Regards,

  Guus

On 7 May 2018 at 21:39, Kaiduan Xie <kaiduanx@gmail.com> wrote:

*UDP 5000-6000*
Dynamically allocated UDP ports for media streams (used when multiplexing
is unavailable).

Where is this range defined in code?

Thanks,

/Kaiduan

On Mon, May 7, 2018 at 3:02 PM, Guus der Kinderen < >> guus.der.kinderen@gmail.com> wrote:

Hi all,

To support firewall configuration, I'm compiling a list of TCP/IP ports
that, under default conditions, are used by the Jitsi stack as we deploy it
(Jitsi Meet webapp, Jicofo & Videobridge).

Could you skim over this, see if I'm making mistakes or missing
something?

For *media*:

*UDP 10000*
Single UDP port for multiplexed media streams. (typically most preferred
candidate)

*UDP 5000-6000*
Dynamically allocated UDP ports for media streams (used when
multiplexing is unavailable).

*TCP 443*
Single TCP port for media streams (typically least preferred candidate)

*TCP 4443*
(used when 443 cannot be bound to)

For *signalling*:

*TCP 80 / 443*
Web server that hosts Meet.

*TCP 7443 *(Openfire) *or TCP 5280 *(Prosody)
XMPP BOSH connectivity from both Meet as well as Jicofo (typically
preferred over TCP 5222/5223)

*TCP 5222 or TCP 5223*
XMPP connectivity from both Meet as well as Jicofo (as an alternative to
the BOSH port).

Regards,

  Guus

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

--
Founder of Goodstartsoft
https://www.goodstartsoft.com

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


#7

Hi Guus,

Thanks for all of the feedback!

It'll be interesting to find out if the Dynamically allocated UDP ports for
media streams can be used without the single port that uses multiplexing.
Boris, if you have additional feedback on that, that would be welcome.

These are independent: you can use either one, or both. You can
disable the dynamic ports with:
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false

There is a caveat: health checks. Jitsi-videobridge's current health
check implementation requires the dynamic ports being enabled.

Regards,
Boris

···

On Tue, May 8, 2018 at 3:13 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:


#8

Thanks for your feedback, Boris!

Disabling the dynamic port range does not seem to be working. I've disabled
the single-port option, and set the property to disable the dynamically
allocated ports. When starting up, this is logged:

INFO [org.jitsi.impl.osgi.framework.AsyncExecutor]:
org.jitsi.impl.configuration.ConfigurationServiceImpl -
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false

Still, when I join a conference, I'm seeing in Meet that the dynamically
allocated UDP ports are being used.

I'm unsure what's causing that. Any thoughts?

- Guus

···

On 16 May 2018 at 17:35, Boris Grozev <boris@sip-communicator.org> wrote:

Hi Guus,

On Tue, May 8, 2018 at 3:13 AM, Guus der Kinderen > <guus.der.kinderen@gmail.com> wrote:
> Thanks for all of the feedback!
>
> It'll be interesting to find out if the Dynamically allocated UDP ports
for
> media streams can be used without the single port that uses multiplexing.
> Boris, if you have additional feedback on that, that would be welcome.

These are independent: you can use either one, or both. You can
disable the dynamic ports with:
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false

There is a caveat: health checks. Jitsi-videobridge's current health
check implementation requires the dynamic ports being enabled.

Regards,
Boris

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


#9

Hi Guus,

···

On Thu, May 17, 2018 at 6:05 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Thanks for your feedback, Boris!

Disabling the dynamic port range does not seem to be working. I've disabled
the single-port option, and set the property to disable the dynamically
allocated ports. When starting up, this is logged:

INFO [org.jitsi.impl.osgi.framework.AsyncExecutor]:
org.jitsi.impl.configuration.ConfigurationServiceImpl -
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false

Still, when I join a conference, I'm seeing in Meet that the dynamically
allocated UDP ports are being used.

I'm unsure what's causing that. Any thoughts?

What exactly do you see in meet? You should expect cleints to use
ephemeral ports, and they might show as "remote port" when p2p is
used.

Boris


#10

I've disabled the channel-bundle/rtcp-mux port (10000 UDP) by seting
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT
to -1.

When I disable the dynamic port range (10001-20000 UDP) by setting
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER to 'false', I expect the
TCP harvester (443/4443 to be used). Instead, it appears that ephemeral
ports continue to be used (org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER
does not appear to have any effect).

In Meet, I join rooms using this URL fragment, to disable p2p and force
traffic through the videobridge: #config.p2p.enabled=false

When I look at the tooltip information for the connection stability icon,
I'm observing that the "remote port" that I'm using is a number that is in
the 10001-20000 range, transport UDP. The port number also increases every
time I join a new conference. I had expected that I'd see either 443 or
4443 here, transport TCP.

···

On 21 May 2018 at 22:55, Boris Grozev <boris@sip-communicator.org> wrote:

Hi Guus,

On Thu, May 17, 2018 at 6:05 AM, Guus der Kinderen > <guus.der.kinderen@gmail.com> wrote:
> Thanks for your feedback, Boris!
>
> Disabling the dynamic port range does not seem to be working. I've
disabled
> the single-port option, and set the property to disable the dynamically
> allocated ports. When starting up, this is logged:
>
> INFO [org.jitsi.impl.osgi.framework.AsyncExecutor]:
> org.jitsi.impl.configuration.ConfigurationServiceImpl -
> org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false
>
> Still, when I join a conference, I'm seeing in Meet that the dynamically
> allocated UDP ports are being used.
>
> I'm unsure what's causing that. Any thoughts?

What exactly do you see in meet? You should expect cleints to use
ephemeral ports, and they might show as "remote port" when p2p is
used.

Boris

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


#11

This is surprising. And reproducible. I'll look into it.

Boris

···

On Tue, May 22, 2018 at 5:58 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

I've disabled the channel-bundle/rtcp-mux port (10000 UDP) by seting
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT to -1.

When I disable the dynamic port range (10001-20000 UDP) by setting
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER to 'false', I expect the
TCP harvester (443/4443 to be used). Instead, it appears that ephemeral
ports continue to be used (org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER
does not appear to have any effect).

In Meet, I join rooms using this URL fragment, to disable p2p and force
traffic through the videobridge: #config.p2p.enabled=false

When I look at the tooltip information for the connection stability icon,
I'm observing that the "remote port" that I'm using is a number that is in
the 10001-20000 range, transport UDP. The port number also increases every
time I join a new conference. I had expected that I'd see either 443 or 4443
here, transport TCP.

On 21 May 2018 at 22:55, Boris Grozev <boris@sip-communicator.org> wrote:

Hi Guus,

On Thu, May 17, 2018 at 6:05 AM, Guus der Kinderen >> <guus.der.kinderen@gmail.com> wrote:
> Thanks for your feedback, Boris!
>
> Disabling the dynamic port range does not seem to be working. I've
> disabled
> the single-port option, and set the property to disable the dynamically
> allocated ports. When starting up, this is logged:
>
> INFO [org.jitsi.impl.osgi.framework.AsyncExecutor]:
> org.jitsi.impl.configuration.ConfigurationServiceImpl -
> org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false
>
> Still, when I join a conference, I'm seeing in Meet that the dynamically
> allocated UDP ports are being used.
>
> I'm unsure what's causing that. Any thoughts?

What exactly do you see in meet? You should expect cleints to use
ephemeral ports, and they might show as "remote port" when p2p is
used.

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


#12

This is surprising. And reproducible. I'll look into it.

What is actually surprising is how short my memory is[0].

The idea behind this is to avoid using dynamic ports if the single port harvester is enabled. But it goes a step further and enables the dynamic ports the single port harvester is disabled. This guarantees that one of the UDP host harvesters is enabled.

This effectively disables the option of having only TcpHarvester. Do you have a use-case for this?

Regards,
Boris

[0] https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L752

···

On 23/05/2018 15:52, Boris Grozev wrote:

Boris

On Tue, May 22, 2018 at 5:58 AM, Guus der Kinderen > <guus.der.kinderen@gmail.com> wrote:

I've disabled the channel-bundle/rtcp-mux port (10000 UDP) by seting
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT to -1.

When I disable the dynamic port range (10001-20000 UDP) by setting
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER to 'false', I expect the
TCP harvester (443/4443 to be used). Instead, it appears that ephemeral
ports continue to be used (org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER
does not appear to have any effect).

In Meet, I join rooms using this URL fragment, to disable p2p and force
traffic through the videobridge: #config.p2p.enabled=false

When I look at the tooltip information for the connection stability icon,
I'm observing that the "remote port" that I'm using is a number that is in
the 10001-20000 range, transport UDP. The port number also increases every
time I join a new conference. I had expected that I'd see either 443 or 4443
here, transport TCP.

On 21 May 2018 at 22:55, Boris Grozev <boris@sip-communicator.org> wrote:

Hi Guus,

On Thu, May 17, 2018 at 6:05 AM, Guus der Kinderen >>> <guus.der.kinderen@gmail.com> wrote:

Thanks for your feedback, Boris!

Disabling the dynamic port range does not seem to be working. I've
disabled
the single-port option, and set the property to disable the dynamically
allocated ports. When starting up, this is logged:

INFO [org.jitsi.impl.osgi.framework.AsyncExecutor]:
org.jitsi.impl.configuration.ConfigurationServiceImpl -
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false

Still, when I join a conference, I'm seeing in Meet that the dynamically
allocated UDP ports are being used.

I'm unsure what's causing that. Any thoughts?

What exactly do you see in meet? You should expect cleints to use
ephemeral ports, and they might show as "remote port" when p2p is
used.

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


#13

Hi Boris,

No hill for me to die on, but I'm not a fan of unexpected, implicit
behavior like this. This mail thread indicates that for some (including its
author :wink:) the behavior is a bit confusing.

As for a use-case: Remember the TURN challenge I had a few months back? I
do have a use case where the stack is running in a corporate environment
that applies severe network restrictions. I'm forced to run things over TCP
there. Although it probably does not hurt to have UDP harvesters active,
not having them enabled does make life (debug / trace /
explain-what's-going-on-to-the-bearded-guy-that-is-monitoring-the-firewall-logs)
a bit easier.

Regards,

  Guus

···

On 24 May 2018 at 01:56, Boris Grozev <boris@jitsi.org> wrote:

On 23/05/2018 15:52, Boris Grozev wrote:

This is surprising. And reproducible. I'll look into it.

What is actually surprising is how short my memory is[0].

The idea behind this is to avoid using dynamic ports if the single port
harvester is enabled. But it goes a step further and enables the dynamic
ports the single port harvester is disabled. This guarantees that one of
the UDP host harvesters is enabled.

This effectively disables the option of having only TcpHarvester. Do you
have a use-case for this?

Regards,
Boris

[0] https://github.com/jitsi/jitsi-videobridge/blob/master/src/
main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L752

Boris

On Tue, May 22, 2018 at 5:58 AM, Guus der Kinderen >> <guus.der.kinderen@gmail.com> wrote:

I've disabled the channel-bundle/rtcp-mux port (10000 UDP) by seting
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT to -1.

When I disable the dynamic port range (10001-20000 UDP) by setting
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER to 'false', I expect
the
TCP harvester (443/4443 to be used). Instead, it appears that ephemeral
ports continue to be used (org.ice4j.ice.harvest.USE_DYN
AMIC_HOST_HARVESTER
does not appear to have any effect).

In Meet, I join rooms using this URL fragment, to disable p2p and force
traffic through the videobridge: #config.p2p.enabled=false

When I look at the tooltip information for the connection stability icon,
I'm observing that the "remote port" that I'm using is a number that is
in
the 10001-20000 range, transport UDP. The port number also increases
every
time I join a new conference. I had expected that I'd see either 443 or
4443
here, transport TCP.

On 21 May 2018 at 22:55, Boris Grozev <boris@sip-communicator.org> >>> wrote:

Hi Guus,

On Thu, May 17, 2018 at 6:05 AM, Guus der Kinderen >>>> <guus.der.kinderen@gmail.com> wrote:

Thanks for your feedback, Boris!

Disabling the dynamic port range does not seem to be working. I've
disabled
the single-port option, and set the property to disable the dynamically
allocated ports. When starting up, this is logged:

INFO [org.jitsi.impl.osgi.framework.AsyncExecutor]:
org.jitsi.impl.configuration.ConfigurationServiceImpl -
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false

Still, when I join a conference, I'm seeing in Meet that the
dynamically
allocated UDP ports are being used.

I'm unsure what's causing that. Any thoughts?

What exactly do you see in meet? You should expect cleints to use
ephemeral ports, and they might show as "remote port" when p2p is
used.

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


#14

Hi Boris, others,

Any thought on my previous remarks on this? I'd slightly prefer to have
everything configurable (as I explained), but if not, I have some
configuration page modifications to attend to. :slight_smile:

Regards,

  Guus

···

On Sun, 27 May 2018 at 11:03, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Hi Boris,

No hill for me to die on, but I'm not a fan of unexpected, implicit
behavior like this. This mail thread indicates that for some (including its
author :wink:) the behavior is a bit confusing.

As for a use-case: Remember the TURN challenge I had a few months back? I
do have a use case where the stack is running in a corporate environment
that applies severe network restrictions. I'm forced to run things over TCP
there. Although it probably does not hurt to have UDP harvesters active,
not having them enabled does make life (debug / trace /
explain-what's-going-on-to-the-bearded-guy-that-is-monitoring-the-firewall-logs)
a bit easier.

Regards,

  Guus

On 24 May 2018 at 01:56, Boris Grozev <boris@jitsi.org> wrote:

On 23/05/2018 15:52, Boris Grozev wrote:

This is surprising. And reproducible. I'll look into it.

What is actually surprising is how short my memory is[0].

The idea behind this is to avoid using dynamic ports if the single port
harvester is enabled. But it goes a step further and enables the dynamic
ports the single port harvester is disabled. This guarantees that one of
the UDP host harvesters is enabled.

This effectively disables the option of having only TcpHarvester. Do you
have a use-case for this?

Regards,
Boris

[0]
https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L752

Boris

On Tue, May 22, 2018 at 5:58 AM, Guus der Kinderen >>> <guus.der.kinderen@gmail.com> wrote:

I've disabled the channel-bundle/rtcp-mux port (10000 UDP) by seting
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT to -1.

When I disable the dynamic port range (10001-20000 UDP) by setting
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER to 'false', I expect
the
TCP harvester (443/4443 to be used). Instead, it appears that ephemeral
ports continue to be used
(org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER
does not appear to have any effect).

In Meet, I join rooms using this URL fragment, to disable p2p and force
traffic through the videobridge: #config.p2p.enabled=false

When I look at the tooltip information for the connection stability
icon,
I'm observing that the "remote port" that I'm using is a number that is
in
the 10001-20000 range, transport UDP. The port number also increases
every
time I join a new conference. I had expected that I'd see either 443 or
4443
here, transport TCP.

On 21 May 2018 at 22:55, Boris Grozev <boris@sip-communicator.org> >>>> wrote:

Hi Guus,

On Thu, May 17, 2018 at 6:05 AM, Guus der Kinderen >>>>> <guus.der.kinderen@gmail.com> wrote:

Thanks for your feedback, Boris!

Disabling the dynamic port range does not seem to be working. I've
disabled
the single-port option, and set the property to disable the
dynamically
allocated ports. When starting up, this is logged:

INFO [org.jitsi.impl.osgi.framework.AsyncExecutor]:
org.jitsi.impl.configuration.ConfigurationServiceImpl -
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false

Still, when I join a conference, I'm seeing in Meet that the
dynamically
allocated UDP ports are being used.

I'm unsure what's causing that. Any thoughts?

What exactly do you see in meet? You should expect cleints to use
ephemeral ports, and they might show as "remote port" when p2p is
used.

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


#15

I've been pondering on this some more.

The idea behind this is to avoid using dynamic ports if the single port

harvester is enabled.

Why do we enforce this? Is this an optimization, by prevent to offer a
client two similar candidates (which will most likely either both work, or
both fail)?

With that in mind, I've created
https://github.com/jitsi/jitsi-videobridge/pull/683

···

On Mon, 11 Jun 2018 at 11:14, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Hi Boris, others,

Any thought on my previous remarks on this? I'd slightly prefer to have
everything configurable (as I explained), but if not, I have some
configuration page modifications to attend to. :slight_smile:

Regards,

  Guus

On Sun, 27 May 2018 at 11:03, Guus der Kinderen < > guus.der.kinderen@gmail.com> wrote:

Hi Boris,

No hill for me to die on, but I'm not a fan of unexpected, implicit
behavior like this. This mail thread indicates that for some (including its
author :wink:) the behavior is a bit confusing.

As for a use-case: Remember the TURN challenge I had a few months back? I
do have a use case where the stack is running in a corporate environment
that applies severe network restrictions. I'm forced to run things over TCP
there. Although it probably does not hurt to have UDP harvesters active,
not having them enabled does make life (debug / trace /
explain-what's-going-on-to-the-bearded-guy-that-is-monitoring-the-firewall-logs)
a bit easier.

Regards,

  Guus

On 24 May 2018 at 01:56, Boris Grozev <boris@jitsi.org> wrote:

On 23/05/2018 15:52, Boris Grozev wrote:

This is surprising. And reproducible. I'll look into it.

What is actually surprising is how short my memory is[0].

The idea behind this is to avoid using dynamic ports if the single port
harvester is enabled. But it goes a step further and enables the dynamic
ports the single port harvester is disabled. This guarantees that one of
the UDP host harvesters is enabled.

This effectively disables the option of having only TcpHarvester. Do you
have a use-case for this?

Regards,
Boris

[0]
https://github.com/jitsi/jitsi-videobridge/blob/master/src/main/java/org/jitsi/videobridge/IceUdpTransportManager.java#L752

Boris

On Tue, May 22, 2018 at 5:58 AM, Guus der Kinderen >>>> <guus.der.kinderen@gmail.com> wrote:

I've disabled the channel-bundle/rtcp-mux port (10000 UDP) by seting
org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT to -1.

When I disable the dynamic port range (10001-20000 UDP) by setting
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER to 'false', I expect
the
TCP harvester (443/4443 to be used). Instead, it appears that ephemeral
ports continue to be used
(org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER
does not appear to have any effect).

In Meet, I join rooms using this URL fragment, to disable p2p and force
traffic through the videobridge: #config.p2p.enabled=false

When I look at the tooltip information for the connection stability
icon,
I'm observing that the "remote port" that I'm using is a number that
is in
the 10001-20000 range, transport UDP. The port number also increases
every
time I join a new conference. I had expected that I'd see either 443
or 4443
here, transport TCP.

On 21 May 2018 at 22:55, Boris Grozev <boris@sip-communicator.org> >>>>> wrote:

Hi Guus,

On Thu, May 17, 2018 at 6:05 AM, Guus der Kinderen >>>>>> <guus.der.kinderen@gmail.com> wrote:

Thanks for your feedback, Boris!

Disabling the dynamic port range does not seem to be working. I've
disabled
the single-port option, and set the property to disable the
dynamically
allocated ports. When starting up, this is logged:

INFO [org.jitsi.impl.osgi.framework.AsyncExecutor]:
org.jitsi.impl.configuration.ConfigurationServiceImpl -
org.ice4j.ice.harvest.USE_DYNAMIC_HOST_HARVESTER=false

Still, when I join a conference, I'm seeing in Meet that the
dynamically
allocated UDP ports are being used.

I'm unsure what's causing that. Any thoughts?

What exactly do you see in meet? You should expect cleints to use
ephemeral ports, and they might show as "remote port" when p2p is
used.

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