gecko-dev/media/mtransport
Dan Minor eae489fda9 Bug 1554976 - Use StunAddrs to set interface for mdns_service; r=mjf
The Rust get_if_addrs library previously used does not build on Android with
our build system. Since we're already using nICEr to determine the local
interface addresses, rather than fix the Rust library, we can use those
addresses to set the interface on which mdns_service listens.

Differential Revision: https://phabricator.services.mozilla.com/D42760

--HG--
extra : moz-landing-system : lando
2019-08-28 19:51:18 +00:00
..
build
fuzztest
ipc Bug 1554976 - Use StunAddrs to set interface for mdns_service; r=mjf 2019-08-28 19:51:18 +00:00
mdns_service Bug 1554976 - Use StunAddrs to set interface for mdns_service; r=mjf 2019-08-28 19:51:18 +00:00
test Bug 1554976 - Add plumbing to enable/disable host address obfuscation; r=mjf 2019-08-28 19:50:06 +00:00
third_party Bug 1554976 - Generate mDNS addresses in nricectx; r=mjf 2019-08-28 19:49:24 +00:00
common.build
dtlsidentity.cpp
dtlsidentity.h
logging.h
m_cpp_utils.h
mediapacket.cpp
mediapacket.h
moz.build
nr_socket_proxy_config.cpp
nr_socket_proxy_config.h
nr_socket_proxy.cpp
nr_socket_proxy.h Bug 1570158 - Add proxy information to candidates table in about:webrtc r=bwc,baku 2019-08-21 10:04:45 +00:00
nr_socket_prsock.cpp
nr_socket_prsock.h Bug 1570158 - Add proxy information to candidates table in about:webrtc r=bwc,baku 2019-08-21 10:04:45 +00:00
nr_timer.cpp
nricectx.cpp Bug 1554976 - Use mdns_service to generate UUIDs; r=mjf 2019-08-28 19:50:44 +00:00
nricectx.h Bug 1554976 - Add plumbing to enable/disable host address obfuscation; r=mjf 2019-08-28 19:50:06 +00:00
nricemediastream.cpp Bug 1570158 - Add proxy information to candidates table in about:webrtc r=bwc,baku 2019-08-21 10:04:45 +00:00
nricemediastream.h Bug 1554976 - Generate mDNS addresses in nricectx; r=mjf 2019-08-28 19:49:24 +00:00
nriceresolver.cpp
nriceresolver.h
nriceresolverfake.cpp
nriceresolverfake.h
nricestunaddr.cpp
nricestunaddr.h
nrinterfaceprioritizer.cpp
nrinterfaceprioritizer.h
README
rlogconnector.cpp
rlogconnector.h
runnable_utils.h
sigslot.h
simpletokenbucket.cpp
simpletokenbucket.h
SrtpFlow.cpp
SrtpFlow.h
stun_socket_filter.cpp
stun_socket_filter.h
test_nr_socket.cpp Bug 1576502 - Fix some wording issues r=mhoye 2019-08-27 15:38:58 +00:00
test_nr_socket.h Bug 1570158 - Add proxy information to candidates table in about:webrtc r=bwc,baku 2019-08-21 10:04:45 +00:00
transportflow.cpp
transportflow.h
transportlayer.cpp
transportlayer.h
transportlayerdtls.cpp
transportlayerdtls.h
transportlayerice.cpp
transportlayerice.h
transportlayerlog.cpp
transportlayerlog.h
transportlayerloopback.cpp
transportlayerloopback.h
transportlayersrtp.cpp
transportlayersrtp.h
WebrtcProxyChannelWrapper.cpp
WebrtcProxyChannelWrapper.h

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.