[jitsi-dev] ICE4J: Continuous gathering of ICE candidates.


#1

Hi all,

I want to make ice4j compatible with the continuous gathering of ICE candidates: https://tools.ietf.org/html/draft-uberti-mmusic-nombis-00.

The use case is the follow: a client implements this draft and is connected to the bridge exchanging media with other participants, then at some point changes its connectivity (e.g. passing from wifi to 4g) and starts sending STUN binding requests from the new IP; Jitsi Videobridge doesn't answer to these new STUN requests so obviously no media is exchanged with this client after the network change.

I tried to modify SinglePortUdpHarvester to restart the agent and the connectivity establishment when the STUN requests from the new IP come, but with no luck so far.

Perhaps someone more expert on ice4j can give me some advice.

Just a note: if JVB is forced to use multiple UDP ports (org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=-1), with a small change in the bridge to accept packets also from the new remote address this use case works like a charm without issues on ICE side.

Thanks in advance,

Matteo


#2

Hello Matteo,

Apologies for the delayed reply.

Hi all,

I want to make ice4j compatible with the continuous gathering of ICE
candidates: https://tools.ietf.org/html/draft-uberti-mmusic-nombis-00.

The use case is the follow: a client implements this draft and is
connected to the bridge exchanging media with other participants, then
at some point changes its connectivity (e.g. passing from wifi to 4g)
and starts sending STUN binding requests from the new IP; Jitsi
Videobridge doesn't answer to these new STUN requests so obviously no
media is exchanged with this client after the network change.

I tried to modify SinglePortUdpHarvester to restart the agent and the
connectivity establishment when the STUN requests from the new IP come,
but with no luck so far.

Perhaps someone more expert on ice4j can give me some advice.

We recently started work on something similar. Our plan is to modify ice4j so that it provides the application with a single socket (or a socket per Component), which reads from all available sockets, and writes to the appropriate target. We can then keep the sockets for all pairs open, and switch the target in ice4j without an ICE restart.

Does that make sense? Do you think it is applicable to your use case?

Just a note: if JVB is forced to use multiple UDP ports
(org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=-1), with a small
change in the bridge to accept packets also from the new remote address
this use case works like a charm without issues on ICE side.

This is interesting! However, with the current ice4j code it will only work if the same candidate is used on the bridge, so e.g. switching to TCP won't be possible.

What I described above should work for both TCP and the single-port mode.

Regards,
Boris

···

On 20/09/16 17:39, Matteo Campana wrote:


#3

Hi Boris,

thank you for the answer.

Your plan sounds good for my use case, as soon as this feature will be available I'll test it.
By the way, I think that the switch of the audio should occur as soon as RTP packets come in from the new interface and so we are sure that is the right one, in fact the client could send multiple STUN binding requests in parallel from all the interfaces.

I'm not using TCP so far, this is why the multiple ports case works.

Cheers,
Matteo

···

________________________________
From: dev <dev-bounces@jitsi.org> on behalf of Boris Grozev <boris@jitsi.org>
Sent: Thursday, October 13, 2016 10:23 AM
To: Jitsi Developers
Subject: Re: [jitsi-dev] ICE4J: Continuous gathering of ICE candidates.

Hello Matteo,

Apologies for the delayed reply.

On 20/09/16 17:39, Matteo Campana wrote:

Hi all,

I want to make ice4j compatible with the continuous gathering of ICE
candidates: https://tools.ietf.org/html/draft-uberti-mmusic-nombis-00.

The use case is the follow: a client implements this draft and is
connected to the bridge exchanging media with other participants, then
at some point changes its connectivity (e.g. passing from wifi to 4g)
and starts sending STUN binding requests from the new IP; Jitsi
Videobridge doesn't answer to these new STUN requests so obviously no
media is exchanged with this client after the network change.

I tried to modify SinglePortUdpHarvester to restart the agent and the
connectivity establishment when the STUN requests from the new IP come,
but with no luck so far.

Perhaps someone more expert on ice4j can give me some advice.

We recently started work on something similar. Our plan is to modify
ice4j so that it provides the application with a single socket (or a
socket per Component), which reads from all available sockets, and
writes to the appropriate target. We can then keep the sockets for all
pairs open, and switch the target in ice4j without an ICE restart.

Does that make sense? Do you think it is applicable to your use case?

Just a note: if JVB is forced to use multiple UDP ports
(org.jitsi.videobridge.SINGLE_PORT_HARVESTER_PORT=-1), with a small
change in the bridge to accept packets also from the new remote address
this use case works like a charm without issues on ICE side.

This is interesting! However, with the current ice4j code it will only
work if the same candidate is used on the bridge, so e.g. switching to
TCP won't be possible.

What I described above should work for both TCP and the single-port mode.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev
dev -- Jitsi Developers - Mailing Lists<http://lists.jitsi.org/mailman/listinfo/dev>
lists.jitsi.org
For discussion of technical implementation details, and is where developers meet and discuss issues, code changes, etc. To see the collection of prior postings to the ...