RE: Issue 170: Response to connectivity checks prior to calling iceTransport.start()?

Yes, if iceTransport.start() is not called at all (or even perhaps if it is called too late after the IceGatherer originally responded), bad things can happen. 

The alternative is to say that the iceGatherer shouldn't respond to connectivity checks, that is the job of the IceTransport, after IceTransport.start() is called. 

If connectivity checks don't receive a response, they will be retransmitted, so assuming iceTransport.start() does get called in a timely way, it need not be a huge problem. 
________________________________________
From: Peter Thatcher [pthatcher@google.com]
Sent: Monday, January 26, 2015 1:04 PM
To: Bernard Aboba
Cc: public-ortc@w3.org
Subject: Re: Issue 170: Response to connectivity checks prior to calling iceTransport.start()?

If I send you connectivity checks, and you respond, and I go into the connected state, but you never call IceTransport.start,  is that giving a false sense of connectivity?  What am I connected to, exactly?

Perhaps I'm missing the value or the use case where this would be valuable.  Can you give a use case where this would be valuable?

On Sun, Jan 11, 2015 at 4:03 PM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:
Here is an update to the proposed text for Section 5.1:

An RTCIceGatherer instance is associated to an RTCIceTransport. As noted in [RFC5245] Section 7.1.2.3, an incoming connectivity check utilizes the remote ufrag and the local password, whereas an outgoing connectivity check utilizes the local ufrag and the remote password. Therefore an RTCIceGatherer possesses the information necessary to validate incoming connectivity checks and may respond to them before an RTCIceTransport is constructed or iceTransport.start() is called.

Since initiating connectivity checks requires the remote password, an RTCIceTransport can only initiate checks after iceTransport.start() is called. To enable an RTCIceTransport to initiate connectivity checks to peers that had previously sent connectivity checks, or to indicate to an RTCIceTransport that a connectivity check had previously been received (and whether it was responded to), the RTCIceGatherer must store information from incoming connectivity checks (such as the remote ufrag) along with an indication of whether it responded, and provide this to associated RTCIceTransport objects so that they can respond if the RTCIceGatherer did not, and can initiate their own connectivity checks.
________________________________________
From: Bernard Aboba
Sent: Friday, January 09, 2015 3:03 PM
To: public-ortc@w3.org<mailto:public-ortc@w3.org>
Subject: Issue 170: Response to connectivity checks prior to calling iceTransport.start()?

The question has been asked whether an RTCIceGatherer object can respond to incoming ICE connectivity checks prior to calling iceTransport.start() or even constructing an RTCIceTransport.

It seems to me that the RTCIceGatherer has the information needed to respond to incoming ICE connectivity checks (the local ufrag/password), but does NOT have the information needed to initiate its own connectivity checks (the remote ufrag/password).

However, having an RTCIceGatherer respond to incoming connectivity checks before iceTransport.start() is called is tricky because it means that outgoing connectivity checks will not be triggered until iceTransport.start() is eventually called, and doing so in a timely way may require the RTCIceGatherer to provide information from the incoming checks to the RTCIceTransport once iceTransport.start() is called.

Here is some proposed text for Section 5.1:

An RTCIceGatherer MAY respond to connectivity checks before an RTCIceTransport is constructed or iceTransport.start() is called. However, connectivity checks are only initiated by the RTCIceTransport, after iceTransport.start() is called.

Received on Monday, 26 January 2015 21:09:21 UTC