[libnice] How can I know that components on both peers are in the NICE_COMPONENT_STATE_READY

[Fabrice Bellet]

Hi Michal,

On 10/16/20 at 01:26pm, Michal Sledz wrote:
> how can I know that components on both peers are in the
> NICE_COMPONENT_STATE_READY. I mean is it possible that the local component
> changed its state to NICE_COMPONENT_STATE_REDY (i.e. it's ready to send and
> receive messages) and the remote one is still e.g. in
> `NICE_COMPONENT_STATE_CONNECTED` or `NICE_COMPONENT_STATE_CONNECTING`
> state?
> 
> I am reading RFC 8445 and I really don't know. Example section shows that
> this isn't possible but from earlier chapters I think we can deduce that it
> is.
> 
> What is more I am almost sure that if we use aggressive nomination it is
> possible that local component can be in READY state while the remote one
> not.
> 
> I just want to perform DTLS handshake after establishing connection with
> ICE and I am not sure when to start sending packets to the remote peer so
> that it can respond to them. If I send them too early when the remote peer
> is not in the READY state yet it will not be able to send any response.

You cannot really know when the remote agent has reached state READY,
because it depends on internal timers and retransmission counters that
are not known by the local agent. But what is interesting from the
application developper point-of-view is the CONNECTED state, because it
indicates that a selected local-remote address pair can be immediately
used to send and receive data. 

The delay between CONNECTED and READY state is an interval where libnice
still searches for better pairs that could *eventually* replace the
initially selected pair.

This delay could be quite long (several seconds), because it involves
testing pairs that are not reachable, where we cannot declare these
pairs as 'failed', before having tried all retransmissions. 

Best regards,
-- 
fabrice