[jitsi-dev] jitsi-hammer ICE / port management problem


#1

Hi,
I think that I have found a bug in jitsi-hammer - however I am not truly sure.
I succeeded to run jitsi-hammer to JVB session when JVB is NOT behind firewall/NAT.
If JVB is behind firewall/NAT (blocking every port except UDP 10000) then jitsi-hammer is unable to connect to jvb. However the videoconference established from jitsi-meet/browser starts without problems.
Inspecting the log file of JVB it seems that jitsi-hammer does not speak ICE very well - it cannot determine that the only working address candidate is the one with port 10000. On the other hand the jitsi-meet/browser app does not have any problems determining the right address candidate in this setup.
Can somebody confirm my assumptions?
Does somebody know how to force jitsi-hammer to use UDP/10000 port only for media streams?

Cheers,
Jernej

···

------------------------------------------------
Jernej Trnkoczy
Researcher
Faculty of Civil and Geodetic Engineering
University of Ljubljana
Phone: +386 1 4768 588
e-mail: jernej.trnkoczy@fgg.uni-lj.si<mailto:jernej.trnkoczy@fgg.uni-lj.si>
------------------------------------------------


#2

Jitsi-hammer does not support rtcp-mux (using the same port for RTP and RTCP) and bundle (using the same port for audio and video). Because of this, the single-port mode on the bridge can not be used.

Unless there is a regression in signalling somewhere, the lack of rtcp-mux and bundle support should be known by the bridge, and it should allocate and advertise separate ports (something like 10001 through 10005 for the first hammer).

Regards,
Boris

···

On 08/03/2017 11:37, Trnkoczy, Jernej wrote:

Hi,

I think that I have found a bug in jitsi-hammer – however I am not truly
sure.

I succeeded to run jitsi-hammer to JVB session when JVB is NOT behind
firewall/NAT.

If JVB is behind firewall/NAT (blocking every port except UDP 10000)
then jitsi-hammer is unable to connect to jvb. However the
videoconference established from jitsi-meet/browser starts without problems.

Inspecting the log file of JVB it seems that jitsi-hammer does not speak
ICE very well – it cannot determine that the only working address
candidate is the one with port 10000. On the other hand the
jitsi-meet/browser app does not have any problems determining the right
address candidate in this setup.

Can somebody confirm my assumptions?

Does somebody know how to force jitsi-hammer to use UDP/10000 port only
for media streams?


#3

Hi Boris,
Thanks for confirmation.
Indeed the bridge does allocate and advertise some other ports (e.g. 11309, 11310, 11311, 11312) - however the ports seem to be selected randomly. Also I assume that if I create 10 "hammer participants" - then 40 UDP ports will be used.
This means that more or less I need to have the entire range 10000 - 20000 opened.
Unfortunately this is not possible in my case - because I am running the JVB as a Kubernetes pod (and exposing pods outside the cluster is somehow tricky...). So it seems that the only solution for me would be to run hammer as a pod inside the cluster as well (which implies making a Docker image of hammer)....
Cheers,
Jernej

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Boris Grozev
Sent: 8. marec 2017 18:50
To: Jitsi Developers
Subject: Re: [jitsi-dev] jitsi-hammer ICE / port management problem

On 08/03/2017 11:37, Trnkoczy, Jernej wrote:

Hi,

I think that I have found a bug in jitsi-hammer – however I am not
truly sure.

I succeeded to run jitsi-hammer to JVB session when JVB is NOT behind
firewall/NAT.

If JVB is behind firewall/NAT (blocking every port except UDP 10000)
then jitsi-hammer is unable to connect to jvb. However the
videoconference established from jitsi-meet/browser starts without problems.

Inspecting the log file of JVB it seems that jitsi-hammer does not
speak ICE very well – it cannot determine that the only working
address candidate is the one with port 10000. On the other hand the
jitsi-meet/browser app does not have any problems determining the
right address candidate in this setup.

Can somebody confirm my assumptions?

Does somebody know how to force jitsi-hammer to use UDP/10000 port
only for media streams?

Jitsi-hammer does not support rtcp-mux (using the same port for RTP and
RTCP) and bundle (using the same port for audio and video). Because of this, the single-port mode on the bridge can not be used.

Unless there is a regression in signalling somewhere, the lack of rtcp-mux and bundle support should be known by the bridge, and it should allocate and advertise separate ports (something like 10001 through
10005 for the first hammer).

Regards,
Boris

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


#4

Hi Jernej,

Hi Boris,
Thanks for confirmation.
Indeed the bridge does allocate and advertise some other ports (e.g. 11309, 11310, 11311, 11312) - however the ports seem to be selected randomly. Also I assume that if I create 10 "hammer participants" - then 40 UDP ports will be used.
This means that more or less I need to have the entire range 10000 - 20000 opened.
Unfortunately this is not possible in my case - because I am running the JVB as a Kubernetes pod (and exposing pods outside the cluster is somehow tricky...). So it seems that the only solution for me would be to run hammer as a pod inside the cluster as well (which implies making a Docker image of hammer)....
Cheers,
Jernej

The ports are allocated from a configurable port range, you can add something like this to /etc/jitsi/videobridge/config to set a specific range:
JVB_OPTS="--apis=rest,xmpp --min-port=10001 --max-port=10101"

(The --apis part is unrelated, I've left it for illustration only)

Make sure that you leave a few unused ports (maybe 10-20) for health checks.

If this still doesn't work for you, think about adding rtcp-mux and bundle support to the hammer. We would welcome such a contribution, and can provide advice on how to implement it.

Regards,
Boris

···

On 08/03/2017 12:03, Trnkoczy, Jernej wrote:


#5

Hi Boris,
Thank you for the information. Adding rtcp-mux + bundle support to hammer --> I doubt I am capable of doing this (at least in a reasonable timeframe). But who knows - maybe some day... :slight_smile:
Cheers,
Jernej

···

-----Original Message-----
From: dev [mailto:dev-bounces@jitsi.org] On Behalf Of Boris Grozev
Sent: 8. marec 2017 19:37
To: Jitsi Developers
Subject: Re: [jitsi-dev] jitsi-hammer ICE / port management problem

Hi Jernej,

On 08/03/2017 12:03, Trnkoczy, Jernej wrote:

Hi Boris,
Thanks for confirmation.
Indeed the bridge does allocate and advertise some other ports (e.g. 11309, 11310, 11311, 11312) - however the ports seem to be selected randomly. Also I assume that if I create 10 "hammer participants" - then 40 UDP ports will be used.
This means that more or less I need to have the entire range 10000 - 20000 opened.
Unfortunately this is not possible in my case - because I am running the JVB as a Kubernetes pod (and exposing pods outside the cluster is somehow tricky...). So it seems that the only solution for me would be to run hammer as a pod inside the cluster as well (which implies making a Docker image of hammer)....
Cheers,
Jernej

The ports are allocated from a configurable port range, you can add something like this to /etc/jitsi/videobridge/config to set a specific
range:
JVB_OPTS="--apis=rest,xmpp --min-port=10001 --max-port=10101"

(The --apis part is unrelated, I've left it for illustration only)

Make sure that you leave a few unused ports (maybe 10-20) for health checks.

If this still doesn't work for you, think about adding rtcp-mux and bundle support to the hammer. We would welcome such a contribution, and can provide advice on how to implement it.

Regards,
Boris

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