gecko-dev/media/mtransport
Paul Vitale 09f4c06235 Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer
This replaces the tunnel using a new nr_socket implementation.  Proxy detection
code is still done in the peer connction.  However, the result is only used to
detect a proxy.  The result is unused.  Address resolution is done by necko code
in the parent process.  The new socket wraps a WebrtcProxyChannel which uses
necko to handle proxy negotiation.  This has a happy side effect of enabling all
authentication modes that necko already supports for http proxies.

This adds a protocol for Necko to manage, WebrtcProxyChannel.  This new protocol
serves as a pipe for a CONNECT tunnel.  It is only used in WebRtc and not built
in no WebRtc builds.

--HG--
extra : rebase_source : a951841f95eaaa0562886cf76b405b01f1adf70e
extra : intermediate-source : 5c3da21957fc80b07188bc8a405437b858027a22
extra : source : 594a32883463ab051677ba06e22fa6d062b4b4a9
2018-06-05 12:10:16 -05:00
..
build Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
fuzztest
ipc Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
test Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
third_party Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
README
SrtpFlow.cpp Bug 1498068: fixed SRTP key length assertion for GCM 128 bit. r=mt 2018-10-16 03:30:57 +00:00
SrtpFlow.h Bug 1498068: fixed SRTP key length assertion for GCM 128 bit. r=mt 2018-10-16 03:30:57 +00:00
WebrtcProxyChannelWrapper.cpp Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
WebrtcProxyChannelWrapper.h Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
common.build Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
dtlsidentity.cpp
dtlsidentity.h
logging.h
m_cpp_utils.h
mediapacket.cpp Bug 1494301: Single API for mtransport. r=mjf 2018-10-26 00:39:07 +00:00
mediapacket.h Bug 1494301: Single API for mtransport. r=mjf 2018-10-26 00:39:07 +00:00
moz.build
nr_socket_proxy.cpp Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
nr_socket_proxy.h Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
nr_socket_proxy_config.cpp Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
nr_socket_proxy_config.h Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
nr_socket_prsock.cpp Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
nr_socket_prsock.h Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
nr_timer.cpp
nricectx.cpp Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
nricectx.h Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
nricemediastream.cpp Bug 1494301: Single API for mtransport. r=mjf 2018-10-26 00:39:07 +00:00
nricemediastream.h
nriceresolver.cpp
nriceresolver.h
nriceresolverfake.cpp
nriceresolverfake.h
nricestunaddr.cpp
nricestunaddr.h
nrinterfaceprioritizer.cpp
nrinterfaceprioritizer.h
rlogconnector.cpp
rlogconnector.h
runnable_utils.h
sigslot.h Bug 1376873 - Make lock_block explicit; r=bwc 2018-08-02 13:56:10 -04:00
simpletokenbucket.cpp
simpletokenbucket.h
stun_socket_filter.cpp
stun_socket_filter.h
test_nr_socket.cpp Bug 1203503 - part 2. replace proxy tunnel with new ipc-based tunnel r+bwc, r+mayhemer 2018-06-05 12:10:16 -05:00
test_nr_socket.h
transportflow.cpp Bug 1494301: Single API for mtransport. r=mjf 2018-10-26 00:39:07 +00:00
transportflow.h
transportlayer.cpp
transportlayer.h
transportlayerdtls.cpp Bug 1505733: add recording of DTLS protocol version used by PeerConnections. r=mt 2018-11-10 20:29:57 +00:00
transportlayerdtls.h Bug 1505733: add recording of DTLS protocol version used by PeerConnections. r=mt 2018-11-10 20:29:57 +00:00
transportlayerice.cpp Bug 1494301: Single API for mtransport. r=mjf 2018-10-26 00:39:07 +00:00
transportlayerice.h Bug 1494301: Single API for mtransport. r=mjf 2018-10-26 00:39:07 +00:00
transportlayerlog.cpp
transportlayerlog.h
transportlayerloopback.cpp
transportlayerloopback.h
transportlayersrtp.cpp Bug 1494301: Single API for mtransport. r=mjf 2018-10-26 00:39:07 +00:00
transportlayersrtp.h

README

This is a generic media transport system for WebRTC.

The basic model is that you have a TransportFlow which contains a
series of TransportLayers, each of which gets an opportunity to
manipulate data up and down the stack (think SysV STREAMS or a
standard networking stack). You can also address individual
sublayers to manipulate them or to bypass reading and writing
at an upper layer; WebRTC uses this to implement DTLS-SRTP.


DATAFLOW MODEL
Unlike the existing nsSocket I/O system, this is a push rather
than a pull system. Clients of the interface do writes downward
with SendPacket() and receive notification of incoming packets
via callbacks registed via sigslot.h. It is the responsibility
of the bottom layer (or any other layer which needs to reference
external events) to arrange for that somehow; typically by
using nsITimer or the SocketTansportService.

This sort of push model is a much better fit for the demands
of WebRTC, expecially because ICE contexts span multiple
network transports.


THREADING MODEL
There are no thread locks. It is the responsibility of the caller to
arrange that any given TransportLayer/TransportFlow is only
manipulated in one thread at once. One good way to do this is to run
everything on the STS thread. Many of the existing layer implementations
(TransportLayerIce, TransportLayerLoopback) already run on STS so in those
cases you must run on STS, though you can do setup on the main thread and
then activate them on the STS.


EXISTING TRANSPORT LAYERS
The following transport layers are currently implemented:

* DTLS -- a wrapper around NSS's DTLS [RFC 6347] stack
* ICE  -- a wrapper around the nICEr ICE [RFC 5245] stack.
* Loopback -- a loopback IO mechanism
* Logging -- a passthrough that just logs its data

The last two are primarily for debugging.