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

Would it make sense to rephrase this question as the following?

How do we want to deal with the case where ICE connectivity checks may
arrive before signalling (because the remote side calls
IceTransport.start() before you get their IceParameters)?


Options seem to be:
1.  Discard the check.
2.  Send back an ICE connectivity response from the IceGatherer.
3.  Buffer the check and send a response when IceTransport.start() is
called.
4.  Add some kind of IceTransport.listen(IceGatherer) which puts an
IceTransport into a "responder" state without going in to the full
"checking" state.

I'm not sure I like any of the options.

#1 seems sub-optimal. We'd be throwing away information.
#2 seems risky, since the remote side thinks its connected to something,
even though it isn't.
#3 seems tricky to implement right, and adds some unnecessary delay.
#4 adds complexity to the API and requires more effort from JS to get the
right behavior.  Although, it would give a natural way to do ice lite.


It seems like we're stuck between requiring the JS to give us more
information (that it wants a IceTransport to repond to pings before an the
remote parameters are available) and doing something tricky (either sending
responses from the gatherer or buffering the checks).






On Mon, Jan 26, 2015 at 1:23 PM, Bernard Aboba <Bernard.Aboba@microsoft.com>
wrote:

> Note that in the sample code, there are IceTransport objects constructed
> for which .start() is not called.  In Example 5 of Section 4.4, an Offerer
> creates IceGatherer, IceTransport and DtlsTransport objects for Audio RTP,
> Audio RTCP, Video RTP and Video RTCP, but doesn't decide whether to call
> IceTransport.start() (or DtlsTransport.start(), for that matter) on the
> created objects until it receives the Answer and figures out whether the
> Answerer supports BUNDLE and RTP/RTCP mux.
> ________________________________________
> From: Bernard Aboba [Bernard.Aboba@microsoft.com]
> Sent: Monday, January 26, 2015 1:08 PM
> To: Peter Thatcher
> Cc: public-ortc@w3.org
> Subject: 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.
>
>
>