[jitsi-dev] ICE connections - problems with second and subsequent question


#1

I have been having this problem whereby the second and subsequent connections to the bridge go wrong at the ICE level. It is quite irritating and affecting my testing, although it does not always happen and so although I was going to leave it I thought I would look at it.

I put a trace into singleportharvester mycandidate addsocket at the point at which it tests:
             IceProcessingState state
                 = component.getParentStream().getParentAgent().getState();

To find out the IceProcessing state. The logs were
for the first time (which worked):
SinglePortUdpHarvester giving Ice state RUNNING parent agent is ICE Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5 ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):
SinglePortUdpHarvester giving Ice state COMPLETED parent agent is ICE Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5 ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):

for the second time(which didn't work).
SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5 ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):
SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5 ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):

From this it appears to be referencing the same object (the parent agent) which although it has been used has not been reset back to its initialisation value.

Obviously I can bodge this in some way and probably get around it, but it strikes me that there is an elegant solution to this issue. I wonder if this problem is somehow related to the way REST sets things up.


#2

Note that ICE agents are never reset. They go from RUNNING to COMPLETED to TERMINATED (which means success...) and that's it. For the second time a new Agent should have been created.

Boris

···

On 25/01/2017 05:18, John Hemming wrote:

I have been having this problem whereby the second and subsequent
connections to the bridge go wrong at the ICE level. It is quite
irritating and affecting my testing, although it does not always happen
and so although I was going to leave it I thought I would look at it.

I put a trace into singleportharvester mycandidate addsocket at the
point at which it tests:
             IceProcessingState state
                 = component.getParentStream().getParentAgent().getState();

To find out the IceProcessing state. The logs were
for the first time (which worked):
SinglePortUdpHarvester giving Ice state RUNNING parent agent is ICE
Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5
ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):
SinglePortUdpHarvester giving Ice state COMPLETED parent agent is ICE
Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5
ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):

for the second time(which didn't work).
SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE
Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5
ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):
SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE
Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5
ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):

From this it appears to be referencing the same object (the parent
agent) which although it has been used has not been reset back to its
initialisation value.


#3

I have run the logger on the creation of the ice agent and when it fails I get:

Agent() creating agent for ufragPrefix null this=ICE Agent (stream-count=0 ice-pwd:3vvbbd1742skrpqkh42akslibh ice-ufrag:784h71b7b5hpp1 tie-breaker:1277938462166512220):

SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE Agent (stream-count=1 ice-pwd:33dneiekc1ltkpgr31din793kr ice-ufrag:fl0tt1b7b5gk8p tie-breaker:5972060773346292813):

When I used the debugger to look at this if found the right ICE agent, but when I just log it it finds the wrong one.

Obviously this is the issue and it is looks like a timing issue. There are no remote candidates, but the server and client are on the same local network (actually the same machine).

Any hints?

···

On 25/01/2017 14:53, Boris Grozev wrote:

On 25/01/2017 05:18, John Hemming wrote:

I have been having this problem whereby the second and subsequent
connections to the bridge go wrong at the ICE level. It is quite
irritating and affecting my testing, although it does not always happen
and so although I was going to leave it I thought I would look at it.

I put a trace into singleportharvester mycandidate addsocket at the
point at which it tests:
             IceProcessingState state
                 = component.getParentStream().getParentAgent().getState();

To find out the IceProcessing state. The logs were
for the first time (which worked):
SinglePortUdpHarvester giving Ice state RUNNING parent agent is ICE
Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5
ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):
SinglePortUdpHarvester giving Ice state COMPLETED parent agent is ICE
Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5
ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):

for the second time(which didn't work).
SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE
Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5
ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):
SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE
Agent (stream-count=1 ice-pwd:4lo8kalo3e3ltu1f08562ul4d5
ice-ufrag:g0qk1b7akv064 tie-breaker:5652842332311952626):

From this it appears to be referencing the same object (the parent
agent) which although it has been used has not been reset back to its
initialisation value.

Note that ICE agents are never reset. They go from RUNNING to COMPLETED to TERMINATED (which means success...) and that's it. For the second time a new Agent should have been created.

Boris

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


#4

Could it be that the same remote ufrag was given to two browser instances? This would make them both send STUN packets which will end up in the same Agent on the bridge.

Boris

···

On 25/01/2017 10:00, John Hemming wrote:

I have run the logger on the creation of the ice agent and when it fails
I get:

Agent() creating agent for ufragPrefix null this=ICE Agent
(stream-count=0 ice-pwd:3vvbbd1742skrpqkh42akslibh
ice-ufrag:784h71b7b5hpp1 tie-breaker:1277938462166512220):

SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE
Agent (stream-count=1 ice-pwd:33dneiekc1ltkpgr31din793kr
ice-ufrag:fl0tt1b7b5gk8p tie-breaker:5972060773346292813):


#5

Thank you for this. Your suggestion is entirely right. There are lots of fingerprints sent out by the REST interface when there are more than one conference participant and I was not picking the right one.

Obviously it worked for the first participant because then there was only one fingerprint sent out.

Entirely my fault. I apologise for doubting the code.

···

On 25/01/2017 16:13, Boris Grozev wrote:

On 25/01/2017 10:00, John Hemming wrote:

I have run the logger on the creation of the ice agent and when it fails
I get:

Agent() creating agent for ufragPrefix null this=ICE Agent
(stream-count=0 ice-pwd:3vvbbd1742skrpqkh42akslibh
ice-ufrag:784h71b7b5hpp1 tie-breaker:1277938462166512220):

SinglePortUdpHarvester giving Ice state TERMINATED parent agent is ICE
Agent (stream-count=1 ice-pwd:33dneiekc1ltkpgr31din793kr
ice-ufrag:fl0tt1b7b5gk8p tie-breaker:5972060773346292813):

Could it be that the same remote ufrag was given to two browser instances? This would make them both send STUN packets which will end up in the same Agent on the bridge.

Boris

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


#6

Glad we figured it out. We have no sacred code here, so doubting it is entirely appropriate (although obviously my own commits are completely bugfree).

Boris

···

On 25/01/2017 10:43, John Hemming wrote:

Thank you for this. Your suggestion is entirely right. There are lots
of fingerprints sent out by the REST interface when there are more than
one conference participant and I was not picking the right one.

Obviously it worked for the first participant because then there was
only one fingerprint sent out.

Entirely my fault. I apologise for doubting the code.