[jitsi-dev] Ice4j candidate relay type


#1

Hi all,

I am looking at determining if a media connection done via ice4j uses a relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by ice4j. Thus, this may be determined by the candidate type or the harvester used. The following assumptions derive from code analysis, thereby help and corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the correlated patches are joined to this email.

Cheers,
Chenzo

jitsiCandidateRelayType.patch (913 Bytes)

ice4jCandidateRelayType.patch (8.95 KB)

···

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#2

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host, ...), I
would rather rename the class (CandidateRelayType sound too _relay_ based),
maybe something like DetailedCandidateType or CandidateExtendedType. A nd
rename "NULL" type to "HOST".

For information, you have the method getType() from Candidate class which
returns a CandidateType ("host", "relay", "stun", ...) but it does not
distinguish relay type (TURN or JingleNodes).

Otherwise the code seems OK to me.

Best regards,

···

--
Seb

2012/2/28 Vincent Lucas <chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by
ice4j. Thus, this may be determined by the candidate type or the harvester
used. The following assumptions derive from code analysis, thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created
by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#3

Hey folks,

Adding to what Seb said:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host, ...), I would
rather rename the class (CandidateRelayType sound too _relay_ based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate class which
returns a CandidateType ("host", "relay", "stun", ...) but it does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

···

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent <seb@jitsi.org> wrote:

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas <chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by
ice4j. Thus, this may be determined by the candidate type or the harvester
used. The following assumptions derive from code analysis, thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created
by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#4

Hi Seb, Emil,

Thank you for the help. Following your comments, here is the update concerning the candidate extended type (cf. patches joined).

5 categories:
- HOST
- UPNP
- STUN
- TURN
- JINGLE_NODE

Correspondance between Candidate type and extended type categorires:

- HostCandidate corresponds to an HOST extended type.

- UPNPCandidate corresponds to an UPNP extended type.

- PeerReflexiveCandidate corresponds to an STUN extended type.
- ServerReflexiveCandidate corresponds to an STUN extended type.

- RelayedCandidate corresponds to an TURN extended type.
- GoogleRelayedCandidate corresponds to an TURN extended type.

- JingleNodesCandidate corresponds to an JINGLE_NODE extended type.

Do not hesitate to tell me if you have any additional comments or if you approve these changes.

Cheers,
Vincent

ice4jCandidateExtendedType.patch (9.2 KB)

jitsiCandidateExtendedType.patch (916 Bytes)

···

On 02/28/2012 09:13 PM, Emil Ivov wrote:

Hey folks,

Adding to what Seb said:

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent<seb@jitsi.org> wrote:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host, ...), I would
rather rename the class (CandidateRelayType sound too _relay_ based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate class which
returns a CandidateType ("host", "relay", "stun", ...) but it does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas<chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by
ice4j. Thus, this may be determined by the candidate type or the harvester
used. The following assumptions derive from code analysis, thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created
by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#5

Hi Vincent,

It is OK for me.

Best regards,

···

--
Seb

Le 29/02/12 10:30, Vincent Lucas a �crit :

Hi Seb, Emil,

Thank you for the help. Following your comments, here is the update concerning the candidate extended type (cf. patches joined).

5 categories:
- HOST
- UPNP
- STUN
- TURN
- JINGLE_NODE

Correspondance between Candidate type and extended type categorires:

- HostCandidate corresponds to an HOST extended type.

- UPNPCandidate corresponds to an UPNP extended type.

- PeerReflexiveCandidate corresponds to an STUN extended type.
- ServerReflexiveCandidate corresponds to an STUN extended type.

- RelayedCandidate corresponds to an TURN extended type.
- GoogleRelayedCandidate corresponds to an TURN extended type.

- JingleNodesCandidate corresponds to an JINGLE_NODE extended type.

Do not hesitate to tell me if you have any additional comments or if you approve these changes.

Cheers,
Vincent

On 02/28/2012 09:13 PM, Emil Ivov wrote:

Hey folks,

Adding to what Seb said:

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent<seb@jitsi.org> >> wrote:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host, ...), I would
rather rename the class (CandidateRelayType sound too _relay_ based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate class which
returns a CandidateType ("host", "relay", "stun", ...) but it does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas<chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by
ice4j. Thus, this may be determined by the candidate type or the harvester
used. The following assumptions derive from code analysis, thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created
by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#6

Hey Vincent,

I think I'd prefer we used the same casing convension here as with
CandidateType (i.e. all lower case).

more inline

Hi Seb, Emil,

Thank you for the help. Following your comments, here is the update
concerning the candidate extended type (cf. patches joined).

5 categories:
- HOST
- UPNP
- STUN
- TURN
- JINGLE_NODE

Correspondance between Candidate type and extended type categorires:

- HostCandidate corresponds to an HOST extended type.

- UPNPCandidate corresponds to an UPNP extended type.

- PeerReflexiveCandidate corresponds to an STUN extended type.
- ServerReflexiveCandidate corresponds to an STUN extended type.

Given that this is an extended type, there's no reason why we would lose
information, so let's just add a couple of extended types for the above
and keep the information as PeerReflexive and server reflexive.

- RelayedCandidate corresponds to an TURN extended type.
- GoogleRelayedCandidate corresponds to an TURN extended type.

Same comment here. Let's keep a TURN candidate and a Google TURN
candidate. We may also need to add one for TCP by the way.

Cheers,
Emil

···

On 29.02.12 11:30, Vincent Lucas wrote:

- JingleNodesCandidate corresponds to an JINGLE_NODE extended type.

Do not hesitate to tell me if you have any additional comments or if you
approve these changes.

Cheers,
Vincent

On 02/28/2012 09:13 PM, Emil Ivov wrote:

Hey folks,

Adding to what Seb said:

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent<seb@jitsi.org> wrote:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host, ...), I would
rather rename the class (CandidateRelayType sound too _relay_ based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate class which
returns a CandidateType ("host", "relay", "stun", ...) but it does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas<chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by
ice4j. Thus, this may be determined by the candidate type or the harvester
used. The following assumptions derive from code analysis, thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created
by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#7

Hi Emil,

(see comments inline).

Hey Vincent,

I think I'd prefer we used the same casing convension here as with
CandidateType (i.e. all lower case).

No problem for the lower case convention.

more inline

Hi Seb, Emil,

Thank you for the help. Following your comments, here is the update
concerning the candidate extended type (cf. patches joined).

5 categories:
- HOST
- UPNP
- STUN
- TURN
- JINGLE_NODE

Correspondance between Candidate type and extended type categorires:

- HostCandidate corresponds to an HOST extended type.

- UPNPCandidate corresponds to an UPNP extended type.

- PeerReflexiveCandidate corresponds to an STUN extended type.
- ServerReflexiveCandidate corresponds to an STUN extended type.

Given that this is an extended type, there's no reason why we would lose
information, so let's just add a couple of extended types for the above
and keep the information as PeerReflexive and server reflexive.

Ok, so let's create "stun peer reflexive" and "stun server reflexive" extended categories and drop the "stun" one.

- RelayedCandidate corresponds to an TURN extended type.
- GoogleRelayedCandidate corresponds to an TURN extended type.

Same comment here. Let's keep a TURN candidate and a Google TURN
candidate. We may also need to add one for TCP by the way.

Ok, so let's create "turn relayed" and "google turn relayed" extended categories and drop the "stun" one.

I am wondering about what do you mean by "TCP"? I can create a "tcp" extended categorie, but I do not understand how and for what purpose it may be used. Can you detail your explanation about this point?

Thank you,
Vincent

···

On 02/29/2012 10:47 AM, Emil Ivov wrote:

On 29.02.12 11:30, Vincent Lucas wrote:

Cheers,
Emil

- JingleNodesCandidate corresponds to an JINGLE_NODE extended type.

Do not hesitate to tell me if you have any additional comments or if you
approve these changes.

Cheers,
Vincent

On 02/28/2012 09:13 PM, Emil Ivov wrote:

Hey folks,

Adding to what Seb said:

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent<seb@jitsi.org> wrote:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host, ...), I would
rather rename the class (CandidateRelayType sound too _relay_ based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate class which
returns a CandidateType ("host", "relay", "stun", ...) but it does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas<chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by
ice4j. Thus, this may be determined by the candidate type or the harvester
used. The following assumptions derive from code analysis, thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created
by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#8

Hi Emil,

(see comments inline).

Hey Vincent,

I think I'd prefer we used the same casing convension here as with
CandidateType (i.e. all lower case).

No problem for the lower case convention.

more inline

Hi Seb, Emil,

Thank you for the help. Following your comments, here is the update
concerning the candidate extended type (cf. patches joined).

5 categories:
- HOST
- UPNP
- STUN
- TURN
- JINGLE_NODE

Correspondance between Candidate type and extended type categorires:

- HostCandidate corresponds to an HOST extended type.

- UPNPCandidate corresponds to an UPNP extended type.

- PeerReflexiveCandidate corresponds to an STUN extended type.
- ServerReflexiveCandidate corresponds to an STUN extended type.

Given that this is an extended type, there's no reason why we would lose
information, so let's just add a couple of extended types for the above
and keep the information as PeerReflexive and server reflexive.

Ok, so let's create "stun peer reflexive" and "stun server reflexive"
extended categories and drop the "stun" one.

- RelayedCandidate corresponds to an TURN extended type.
- GoogleRelayedCandidate corresponds to an TURN extended type.

Same comment here. Let's keep a TURN candidate and a Google TURN
candidate. We may also need to add one for TCP by the way.

Ok, so let's create "turn relayed" and "google turn relayed" extended
categories and drop the "stun" one.

I am wondering about what do you mean by "TCP"? I can create a "tcp"
extended categorie, but I do not understand how and for what purpose it
may be used. Can you detail your explanation about this point?

The Google TURN relays also support TCP relaying (with fake SSL). I am
not sure if we handle these with the same candidate classes as the UDP
relays though or not. Seb, would certainly be able to explain this better.

Emil

···

On 29.02.12 12:45, Vincent Lucas wrote:

On 02/29/2012 10:47 AM, Emil Ivov wrote:

On 29.02.12 11:30, Vincent Lucas wrote:

Thank you,
Vincent

Cheers,
Emil

- JingleNodesCandidate corresponds to an JINGLE_NODE extended type.

Do not hesitate to tell me if you have any additional comments or if you
approve these changes.

Cheers,
Vincent

On 02/28/2012 09:13 PM, Emil Ivov wrote:

Hey folks,

Adding to what Seb said:

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent<seb@jitsi.org> wrote:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host, ...), I would
rather rename the class (CandidateRelayType sound too _relay_ based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate class which
returns a CandidateType ("host", "relay", "stun", ...) but it does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas<chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by
ice4j. Thus, this may be determined by the candidate type or the harvester
used. The following assumptions derive from code analysis, thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created
by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#9

Hi all,

See inline.

Le 29/02/12 12:15, Emil Ivov a �crit :

Hi Emil,

(see comments inline).

Hey Vincent,

I think I'd prefer we used the same casing convension here as with
CandidateType (i.e. all lower case).

No problem for the lower case convention.

more inline

Hi Seb, Emil,

Thank you for the help. Following your comments, here is the update
concerning the candidate extended type (cf. patches joined).

5 categories:
- HOST
- UPNP
- STUN
- TURN
- JINGLE_NODE

Correspondance between Candidate type and extended type categorires:

- HostCandidate corresponds to an HOST extended type.

- UPNPCandidate corresponds to an UPNP extended type.

- PeerReflexiveCandidate corresponds to an STUN extended type.
- ServerReflexiveCandidate corresponds to an STUN extended type.

Given that this is an extended type, there's no reason why we would lose
information, so let's just add a couple of extended types for the above
and keep the information as PeerReflexive and server reflexive.

Ok, so let's create "stun peer reflexive" and "stun server reflexive"
extended categories and drop the "stun" one.

- RelayedCandidate corresponds to an TURN extended type.
- GoogleRelayedCandidate corresponds to an TURN extended type.

Same comment here. Let's keep a TURN candidate and a Google TURN
candidate. We may also need to add one for TCP by the way.

Ok, so let's create "turn relayed" and "google turn relayed" extended
categories and drop the "stun" one.

I am wondering about what do you mean by "TCP"? I can create a "tcp"
extended categorie, but I do not understand how and for what purpose it
may be used. Can you detail your explanation about this point?

The Google TURN relays also support TCP relaying (with fake SSL). I am
not sure if we handle these with the same candidate classes as the UDP
relays though or not. Seb, would certainly be able to explain this better.

For Google TURN-TCP, we use the same GoogleRelayedCandidate class. To determine if it uses TCP, we can do the following: in GoogleRelayedCandidate's contructor, use transportAddress.getTransport() to determine if it uses UDP or TCP and set the related ExtendedCandidateType enum.

Regards,

···

On 29.02.12 12:45, Vincent Lucas wrote:

On 02/29/2012 10:47 AM, Emil Ivov wrote:

On 29.02.12 11:30, Vincent Lucas wrote:

--
Seb

Emil

Thank you,
Vincent

Cheers,
Emil

- JingleNodesCandidate corresponds to an JINGLE_NODE extended type.

Do not hesitate to tell me if you have any additional comments or if you
approve these changes.

Cheers,
Vincent

On 02/28/2012 09:13 PM, Emil Ivov wrote:

Hey folks,

Adding to what Seb said:

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent<seb@jitsi.org> wrote:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host, ...), I would
rather rename the class (CandidateRelayType sound too _relay_ based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate class which
returns a CandidateType ("host", "relay", "stun", ...) but it does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas<chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates harvested by
ice4j. Thus, this may be determined by the candidate type or the harvester
used. The following assumptions derive from code analysis, thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is only created
by the StunCandidateHarvest or by its subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#10

Hi all,

Thank you for the explanation about the Google TCP. Thus, a "google tcp turn relayed" extended type is added to the list.

The provided patch corresponds to the correction requested, as when a GoogleRelayedCandidate is instantiated, we check and set this instance to "google tcp turn relayed" if the "transportAddress.getTransport()" corresponds to the enum "Transport.TCP".

However, the Transport enum classification is a bit odd as it enumerates at the same time protocol from the "OSI transport layer" (such as UDP, TCP and STCP) and "OSI presentation/application layer" (such as DTLS, SSLTCP and TLS).
Although, the DTLS is used over UDP, TLS over TCP and SSLTCP over TCP (I do not find any reference for this protocol, but I bet this is the fake SSL mode that Emil was talking about).
Thereby, we may switch to "google tcp turn relayed" extended type as well when the "transport/presentation/application" type is TLS or SSLTCP.

What do you think?

Regards,
Vincent

jitsiCandidateExtendedType.patch (926 Bytes)

ice4jCandidateExtendedType.patch (14.4 KB)

···

On 02/29/2012 12:57 PM, Sebastien Vincent wrote:

Hi all,

See inline.

Le 29/02/12 12:15, Emil Ivov a �crit :

On 29.02.12 12:45, Vincent Lucas wrote:

Hi Emil,

(see comments inline).

On 02/29/2012 10:47 AM, Emil Ivov wrote:

Hey Vincent,

I think I'd prefer we used the same casing convension here as with
CandidateType (i.e. all lower case).

No problem for the lower case convention.

more inline

On 29.02.12 11:30, Vincent Lucas wrote:

Hi Seb, Emil,

Thank you for the help. Following your comments, here is the update
concerning the candidate extended type (cf. patches joined).

5 categories:
- HOST
- UPNP
- STUN
- TURN
- JINGLE_NODE

Correspondance between Candidate type and extended type categorires:

- HostCandidate corresponds to an HOST extended type.

- UPNPCandidate corresponds to an UPNP extended type.

- PeerReflexiveCandidate corresponds to an STUN extended type.
- ServerReflexiveCandidate corresponds to an STUN extended type.

Given that this is an extended type, there's no reason why we would
lose
information, so let's just add a couple of extended types for the above
and keep the information as PeerReflexive and server reflexive.

Ok, so let's create "stun peer reflexive" and "stun server reflexive"
extended categories and drop the "stun" one.

- RelayedCandidate corresponds to an TURN extended type.
- GoogleRelayedCandidate corresponds to an TURN extended type.

Same comment here. Let's keep a TURN candidate and a Google TURN
candidate. We may also need to add one for TCP by the way.

Ok, so let's create "turn relayed" and "google turn relayed" extended
categories and drop the "stun" one.

I am wondering about what do you mean by "TCP"? I can create a "tcp"
extended categorie, but I do not understand how and for what purpose it
may be used. Can you detail your explanation about this point?

The Google TURN relays also support TCP relaying (with fake SSL). I am
not sure if we handle these with the same candidate classes as the UDP
relays though or not. Seb, would certainly be able to explain this
better.

For Google TURN-TCP, we use the same GoogleRelayedCandidate class. To
determine if it uses TCP, we can do the following: in
GoogleRelayedCandidate's contructor, use transportAddress.getTransport()
to determine if it uses UDP or TCP and set the related
ExtendedCandidateType enum.

Regards,
--
Seb

Emil

Thank you,
Vincent

Cheers,
Emil

- JingleNodesCandidate corresponds to an JINGLE_NODE extended type.

Do not hesitate to tell me if you have any additional comments or
if you
approve these changes.

Cheers,
Vincent

On 02/28/2012 09:13 PM, Emil Ivov wrote:

Hey folks,

Adding to what Seb said:

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent<seb@jitsi.org> >>>>>> wrote:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host,
...), I would
rather rename the class (CandidateRelayType sound too _relay_
based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate
class which
returns a CandidateType ("host", "relay", "stun", ...) but it
does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas<chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j
uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates
harvested by
ice4j. Thus, this may be determined by the candidate type or the
harvester
used. The following assumptions derive from code analysis,
thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is
only created
by the StunCandidateHarvest or by its
subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate
always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#11

Hi Vincent,

Le 29/02/12 14:53, Vincent Lucas a �crit :

Hi all,

Thank you for the explanation about the Google TCP. Thus, a "google tcp turn relayed" extended type is added to the list.

The provided patch corresponds to the correction requested, as when a GoogleRelayedCandidate is instantiated, we check and set this instance to "google tcp turn relayed" if the "transportAddress.getTransport()" corresponds to the enum "Transport.TCP".

However, the Transport enum classification is a bit odd as it enumerates at the same time protocol from the "OSI transport layer" (such as UDP, TCP and STCP) and "OSI presentation/application layer" (such as DTLS, SSLTCP and TLS).
Although, the DTLS is used over UDP, TLS over TCP and SSLTCP over TCP (I do not find any reference for this protocol, but I bet this is the fake SSL mode that Emil was talking about).
Thereby, we may switch to "google tcp turn relayed" extended type as well when the "transport/presentation/application" type is TLS or SSLTCP.

What do you think?

The enum DTLS, TLS, SSLTCP is not used in ice4j and in Jitsi. Back in the days when we implemented the Google SSLTCP we saw that it was more complicated to have a Candidate with an SSLTCP as Transport since we based our socket creation to the Transport value. So in other words we would have to replace in the codebase every "if(Transport.TCP...)" with "if(Transport.TCP || Transport.SSLTCP, ...)". After all SSLTCP is TCP.

Maybe we should remove the TLS/DTLS/SSLTCP from the Transport enumeration and just let the "OSI transport layer" ?

For information, to determine if we have an SSLTCP candidate just check the Transport is TCP and the remote port is 443.

Regards,

···

--
Seb

Regards,
Vincent

On 02/29/2012 12:57 PM, Sebastien Vincent wrote:

Hi all,

See inline.

Le 29/02/12 12:15, Emil Ivov a �crit :

On 29.02.12 12:45, Vincent Lucas wrote:

Hi Emil,

(see comments inline).

On 02/29/2012 10:47 AM, Emil Ivov wrote:

Hey Vincent,

I think I'd prefer we used the same casing convension here as with
CandidateType (i.e. all lower case).

No problem for the lower case convention.

more inline

On 29.02.12 11:30, Vincent Lucas wrote:

Hi Seb, Emil,

Thank you for the help. Following your comments, here is the update
concerning the candidate extended type (cf. patches joined).

5 categories:
- HOST
- UPNP
- STUN
- TURN
- JINGLE_NODE

Correspondance between Candidate type and extended type categorires:

- HostCandidate corresponds to an HOST extended type.

- UPNPCandidate corresponds to an UPNP extended type.

- PeerReflexiveCandidate corresponds to an STUN extended type.
- ServerReflexiveCandidate corresponds to an STUN extended type.

Given that this is an extended type, there's no reason why we would
lose
information, so let's just add a couple of extended types for the above
and keep the information as PeerReflexive and server reflexive.

Ok, so let's create "stun peer reflexive" and "stun server reflexive"
extended categories and drop the "stun" one.

- RelayedCandidate corresponds to an TURN extended type.
- GoogleRelayedCandidate corresponds to an TURN extended type.

Same comment here. Let's keep a TURN candidate and a Google TURN
candidate. We may also need to add one for TCP by the way.

Ok, so let's create "turn relayed" and "google turn relayed" extended
categories and drop the "stun" one.

I am wondering about what do you mean by "TCP"? I can create a "tcp"
extended categorie, but I do not understand how and for what purpose it
may be used. Can you detail your explanation about this point?

The Google TURN relays also support TCP relaying (with fake SSL). I am
not sure if we handle these with the same candidate classes as the UDP
relays though or not. Seb, would certainly be able to explain this
better.

For Google TURN-TCP, we use the same GoogleRelayedCandidate class. To
determine if it uses TCP, we can do the following: in
GoogleRelayedCandidate's contructor, use transportAddress.getTransport()
to determine if it uses UDP or TCP and set the related
ExtendedCandidateType enum.

Regards,
--
Seb

Emil

Thank you,
Vincent

Cheers,
Emil

- JingleNodesCandidate corresponds to an JINGLE_NODE extended type.

Do not hesitate to tell me if you have any additional comments or
if you
approve these changes.

Cheers,
Vincent

On 02/28/2012 09:13 PM, Emil Ivov wrote:

Hey folks,

Adding to what Seb said:

On Tue, Feb 28, 2012 at 10:06 PM, Sebastien Vincent<seb@jitsi.org> >>>>>>> wrote:

Hi Vincent,

I have some remarks:
- The STUN server is not a relay;
- If you want to keep all these information (stun, turn, host,
...), I would
rather rename the class (CandidateRelayType sound too _relay_
based), maybe
something like DetailedCandidateType or CandidateExtendedType.

I like that. Let's go for ExtendedCandidateType

And rename
"NULL" type to "HOST".

For information, you have the method getType() from Candidate
class which
returns a CandidateType ("host", "relay", "stun", ...) but it
does not
distinguish relay type (TURN or JingleNodes).

True and neither does it distinguish between STUN and UPnP as they
both appear as server-reflexive.

Emil

Otherwise the code seems OK to me.

Best regards,
--
Seb

2012/2/28 Vincent Lucas<chenzo@jitsi.org>

Hi all,

I am looking at determining if a media connection done via ice4j
uses a
relay and which type of relay is used.

For the moment, I see 4 categories of relay:
- NULL, no relay used.
- STUN_SERVER, the relay is a STUN server.
- TURN_SERVER, the relay is a TURN server.
- JINGLE_NODE, the relay is a Jingle node.

I want to store this information into the local candidates
harvested by
ice4j. Thus, this may be determined by the candidate type or the
harvester
used. The following assumptions derive from code analysis,
thereby help and
corrections from ICE "connoisseur" are welcome:

- HostCandidate never uses a relay.
- UPNPCandidate never uses a relay.

- RelayedCandidate always uses a TURN_SERVER.
- GoogleRelayedCandidate always uses a TURN_SERVER.

- PeerReflexiveCandidate always uses STUN_SERVER.
- ServerReflexiveCandidate always uses a STUN_SERVER as it is
only created
by the StunCandidateHarvest or by its
subclass(TurnCandidateHarvest and
GoogleCandidateHarvest), but always determined by a STUN response.

- Outside of ice4j (but part of Jitsi) JingleNodesCandidate
always uses
JINGLE_NODE.

If the above explanation seems too obfuscated or too sparse, the
correlated patches are joined to this email.

Cheers,
Chenzo

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org