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>
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
> 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.
>