[jitsi-dev] jingle Raw UDP vs ICE-UDP transport?


#1

In my quest to make all things configurable (insert meme here), I was
running into issues with the configuration of the port range used when not
doing single-port UDP media streaming (what's by default on 10001-20000).

I've initially tried to change the values of the
net.java.sip.communicator.service.media.MIN_PORT_NUMBER
and net.java.sip.communicator.service.media.MAX_PORT_NUMBER properties, but
to my surprise, that did not have the desired effect.

Turns out that these value are not only used in DefaultStreamConnector
(where the properties are defined), but also in the main method
implementation of org.jitsi.videobridge.Main. There it is used to apply
configuration in two different transports:

// Jingle Raw UDP transport
// TODO: Use the common TransportManager.portTracker for Raw UDP too
System.setProperty(
        DefaultStreamConnector.MAX_PORT_NUMBER_PROPERTY_NAME,
        maxPort_);
System.setProperty(
        DefaultStreamConnector.MIN_PORT_NUMBER_PROPERTY_NAME,
        minPort_);

// Jingle ICE-UDP transport
TransportManager.portTracker.tryRange(minPort_, maxPort_);

I'm not launching the bridge as a stand-alone application, but from code.
As a result, I'm not invoking Main at all - which is why I missed the
second transport.

By adding this code to mine, I was quickly able to resolve my issue. This
lives me with one question:
what's the difference between Jingle Raw UDP and ICE-UDP transport? When is
either used?

Kind regards,

  Guus


#2

Raw UDP is just an exchange of a single pair of UDP addresses (no
connectivity or concent checks). It does not work with WebRTC, and
AFAIK it is never used with the bridge anymore (at least not with
jicofo).

Boris

···

On Wed, May 16, 2018 at 10:25 AM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

In my quest to make all things configurable (insert meme here), I was
running into issues with the configuration of the port range used when not
doing single-port UDP media streaming (what's by default on 10001-20000).

I've initially tried to change the values of the
net.java.sip.communicator.service.media.MIN_PORT_NUMBER and
net.java.sip.communicator.service.media.MAX_PORT_NUMBER properties, but to
my surprise, that did not have the desired effect.

Turns out that these value are not only used in DefaultStreamConnector
(where the properties are defined), but also in the main method
implementation of org.jitsi.videobridge.Main. There it is used to apply
configuration in two different transports:

// Jingle Raw UDP transport
// TODO: Use the common TransportManager.portTracker for Raw UDP too
System.setProperty(
        DefaultStreamConnector.MAX_PORT_NUMBER_PROPERTY_NAME,
        maxPort_);
System.setProperty(
        DefaultStreamConnector.MIN_PORT_NUMBER_PROPERTY_NAME,
        minPort_);

// Jingle ICE-UDP transport
TransportManager.portTracker.tryRange(minPort_, maxPort_);

I'm not launching the bridge as a stand-alone application, but from code. As
a result, I'm not invoking Main at all - which is why I missed the second
transport.

By adding this code to mine, I was quickly able to resolve my issue. This
lives me with one question:
what's the difference between Jingle Raw UDP and ICE-UDP transport? When is
either used?

Kind regards,

  Guus

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


#3

Hello Guus,

Long time no sea.
Raw-UDP will work on a fixed and pre-negotiated IP:Port based transport.
Wheather it succeeds or fails is a leap of faith.

While ICE-UDP will try various IP:Port combination from initiator and
responder, exchanged in transport-info updates besides the multiple ones
already offered in session-initiate and session-accept. Including a relayed
path potentially (TURN).

Regards,

···

On Wed, May 16, 2018 at 12:25 PM, Guus der Kinderen < guus.der.kinderen@gmail.com> wrote:

In my quest to make all things configurable (insert meme here), I was
running into issues with the configuration of the port range used when not
doing single-port UDP media streaming (what's by default on 10001-20000).

I've initially tried to change the values of the net.java.sip.communicator.service.media.MIN_PORT_NUMBER
and net.java.sip.communicator.service.media.MAX_PORT_NUMBER properties,
but to my surprise, that did not have the desired effect.

Turns out that these value are not only used in DefaultStreamConnector
(where the properties are defined), but also in the main method
implementation of org.jitsi.videobridge.Main. There it is used to apply
configuration in two different transports:

// Jingle Raw UDP transport
// TODO: Use the common TransportManager.portTracker for Raw UDP too
System.setProperty(
        DefaultStreamConnector.MAX_PORT_NUMBER_PROPERTY_NAME,
        maxPort_);
System.setProperty(
        DefaultStreamConnector.MIN_PORT_NUMBER_PROPERTY_NAME,
        minPort_);

// Jingle ICE-UDP transport
TransportManager.portTracker.tryRange(minPort_, maxPort_);

I'm not launching the bridge as a stand-alone application, but from code.
As a result, I'm not invoking Main at all - which is why I missed the
second transport.

By adding this code to mine, I was quickly able to resolve my issue. This
lives me with one question:
what's the difference between Jingle Raw UDP and ICE-UDP transport? When
is either used?

Kind regards,

  Guus

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


#4

Hey Thiago!

How have you been? On which side of what ocean are you, these days? :slight_smile:

Thanks for the clarification!

Regards,

  Guus

···

On 17 May 2018 at 01:02, thiagoc <barata7@gmail.com> wrote:

Hello Guus,

Long time no sea.
Raw-UDP will work on a fixed and pre-negotiated IP:Port based transport.
Wheather it succeeds or fails is a leap of faith.

While ICE-UDP will try various IP:Port combination from initiator and
responder, exchanged in transport-info updates besides the multiple ones
already offered in session-initiate and session-accept. Including a relayed
path potentially (TURN).

Regards,

On Wed, May 16, 2018 at 12:25 PM, Guus der Kinderen < > guus.der.kinderen@gmail.com> wrote:

In my quest to make all things configurable (insert meme here), I was
running into issues with the configuration of the port range used when not
doing single-port UDP media streaming (what's by default on 10001-20000).

I've initially tried to change the values of the
net.java.sip.communicator.service.media.MIN_PORT_NUMBER
and net.java.sip.communicator.service.media.MAX_PORT_NUMBER properties,
but to my surprise, that did not have the desired effect.

Turns out that these value are not only used in DefaultStreamConnector
(where the properties are defined), but also in the main method
implementation of org.jitsi.videobridge.Main. There it is used to apply
configuration in two different transports:

// Jingle Raw UDP transport
// TODO: Use the common TransportManager.portTracker for Raw UDP too
System.setProperty(
        DefaultStreamConnector.MAX_PORT_NUMBER_PROPERTY_NAME,
        maxPort_);
System.setProperty(
        DefaultStreamConnector.MIN_PORT_NUMBER_PROPERTY_NAME,
        minPort_);

// Jingle ICE-UDP transport
TransportManager.portTracker.tryRange(minPort_, maxPort_);

I'm not launching the bridge as a stand-alone application, but from code.
As a result, I'm not invoking Main at all - which is why I missed the
second transport.

By adding this code to mine, I was quickly able to resolve my issue. This
lives me with one question:
what's the difference between Jingle Raw UDP and ICE-UDP transport? When
is either used?

Kind 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