[jitsi-dev] ice4j support for TURN over TLS?


#1

(was originally posted on users@jitsi.org but not answered there)

I notice it is possible to add a TurnCandidateHarvester with the TLS
Transport, e.g.

  iceAgent.addCandidateHarvester(
     new TurnCandidateHarvester(
        new TransportAddress(server, port, Transport.TLS)
     )
  );

However, is Transport.TLS support implemented in ice4j? (From a quick
look at the source, it doesn't appear to be)

If not, is Transport.TCP support implemented and could it be used as a
base for TLS support?

If TLS is supported, how does it resolve the server argument in
TransportAddress? Should the resolution of NAPTR and SRV records occur
within IceAgent, ignoring the port argument supplied by the user?

Or should the user of the IceAgent class be doing the NAPTR and SRV
resolution and then calling addCandidateHarvester multiple times, once
for each TransportAddress it discovered?

In the latter scenario, the API would need to be changed so that the
user of the IceAgent can specify the manually configured "host" value
that it used in NAPTR and SRV resolution, as that is the value that
needs to be matched in the certificate received from the server, as
specified here:

https://tools.ietf.org/html/rfc5928#section-5


#2

I've raised two queries about this through the issue tracker as well:

https://github.com/jitsi/ice4j/issues/46
   (TURN over TLS)

https://github.com/jitsi/ice4j/issues/36
   (NAPTR, SRV implementation)

···

On 24/11/15 11:11, Daniel Pocock wrote:

(was originally posted on users@jitsi.org but not answered there)

I notice it is possible to add a TurnCandidateHarvester with the TLS
Transport, e.g.

  iceAgent.addCandidateHarvester(
     new TurnCandidateHarvester(
        new TransportAddress(server, port, Transport.TLS)
     )
  );

However, is Transport.TLS support implemented in ice4j? (From a quick
look at the source, it doesn't appear to be)

If not, is Transport.TCP support implemented and could it be used as a
base for TLS support?

If TLS is supported, how does it resolve the server argument in
TransportAddress? Should the resolution of NAPTR and SRV records occur
within IceAgent, ignoring the port argument supplied by the user?

Or should the user of the IceAgent class be doing the NAPTR and SRV
resolution and then calling addCandidateHarvester multiple times, once
for each TransportAddress it discovered?

In the latter scenario, the API would need to be changed so that the
user of the IceAgent can specify the manually configured "host" value
that it used in NAPTR and SRV resolution, as that is the value that
needs to be matched in the certificate received from the server, as
specified here:

https://tools.ietf.org/html/rfc5928#section-5