- From: Bernard Aboba <Bernard.Aboba@microsoft.com>
- Date: Fri, 6 Feb 2015 23:24:40 +0000
- To: "public-ortc@w3.org" <public-ortc@w3.org>
- CC: "robin@hookflash.com" <robin@hookflash.com>
> Issue: > What do we do about DTLS packets that can arrive before there's a DTLS > transport to receive the DTLS packets [BA] Actually, the problem can occur even if there is a constructed DtlsTransport. Before iceTransport.start() is called, there is no associatiobetween an IceGatherer and an IceTransport. So even if a DtlsTransport is associated to an IceTransport, an incoming DTLS packet cannot be delivered to the DtlsTransport. > Possible options: > 1) Drop DTLS packets incoming, force DTLS client re-transmit (i.e. > consequence is a slow started or disrupted connections); [BA] I would prefer to avoid this option. > 2) Buffer DTLS packets incoming for a period of time and deliver packets > to eventual IceTransport.start() which specifies a matching remote > ufrag/password (i.e. consequence is insufficient buffering, over-buffering > (DOS attack), or timeouts that drop packets pre-maturely before signalling > arrives). [BA] I don't think the issue is buffering so much as *where* the buffering occurs. Buffering DTLS packets within an ICE-related object (whether IceTransport or IceGatherer) seems wrong to me. > 3) Put IceTransport into a .listen() mode of operation with a pre-wired > DTLS transport (i.e. consequence is a larger / more complex ORTC API > surface and one that must handle forking scenarios). This idea was briefly > mentioned in last ORTC CG meeting. [BA] There is a 4th option. Originally, the IceTransport constructor included an (optional) IceListener argument, so that it was possible to associate an IceListener/IceGatherer with an IceTransport before calling iceTransport.start(). Bringing back the constructor argument seems like a simpler solution than adding an iceTransport.listen() method
Received on Friday, 6 February 2015 23:25:15 UTC