gecko-dev/media/mtransport
Byron Campen [:bwc] 6a9cca850e Bug 1571156: Wait for streams to be ready before trying to send packets. r=mjf
Differential Revision: https://phabricator.services.mozilla.com/D84251
2020-07-21 13:59:41 +00:00
..
build
fuzztest
ipc Bug 1497249 - P2: ipdl for nsIWebSocketConnection r=michal 2020-07-16 13:34:58 +00:00
mdns_service Bug 1640668 - Remove unwrap() call from MDNSService start; r=mjf 2020-05-28 16:46:54 +00:00
test Bug 1571156: Wait for streams to be ready before trying to send packets. r=mjf 2020-07-21 13:59:41 +00:00
third_party Bug 1651601: Filter gathered candidates when their component is obsolete. r=mjf 2020-07-10 17:11:32 +00:00
README
SrtpFlow.cpp
SrtpFlow.h
WebrtcTCPSocketWrapper.cpp
WebrtcTCPSocketWrapper.h
common.build
dtlsidentity.cpp Bug 1512478 - Use sync IPC to get client auth data from parent process r=keeler,mccr8 2020-04-28 20:12:43 +00:00
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_prsock.cpp Bug 1648010 - Replace uses of NS_LITERAL_STRING/NS_LITERAL_CSTRING macros by _ns literals. r=geckoview-reviewers,jgilbert,agi,hsivonen,froydnj 2020-07-01 08:29:29 +00:00
nr_socket_prsock.h
nr_socket_tcp.cpp Bug 1646273 - Add a nullptr check in ns_socket_tcp before sending data, r=bwc 2020-06-18 15:41:36 +00:00
nr_socket_tcp.h
nr_timer.cpp
nricectx.cpp Bug 1193437: Use config structs in NrIceCtx, and centralize pref lookups some. r=mjf 2020-07-09 15:36:07 +00:00
nricectx.h Bug 1193437: Use config structs in NrIceCtx, and centralize pref lookups some. r=mjf 2020-07-09 15:36:07 +00:00
nricemediastream.cpp Bug 1326005: Make this log at INFO because that's the level we log on the sending side. r=mjf 2020-07-08 18:00:20 +00:00
nricemediastream.h
nriceresolver.cpp
nriceresolver.h Bug 1625213 - Make txt records be resolved with onLookupComplete r=dragana 2020-04-07 12:39:45 +00:00
nriceresolverfake.cpp
nriceresolverfake.h
nricestunaddr.cpp
nricestunaddr.h
nrinterfaceprioritizer.cpp
nrinterfaceprioritizer.h
rlogconnector.cpp
rlogconnector.h
runnable_utils.h Bug 1625138 - Part 17: Replace mozilla::Decay with std::decay. r=froydnj 2020-03-28 13:57:15 +00:00
sigslot.h
simpletokenbucket.cpp
simpletokenbucket.h
stun_socket_filter.cpp
stun_socket_filter.h
test_nr_socket.cpp
test_nr_socket.h
transportflow.cpp
transportflow.h
transportlayer.cpp
transportlayer.h
transportlayerdtls.cpp Bug 1615443: re-add DTLS protocol version telemetry. r=dminor 2020-03-18 17:59:07 +00:00
transportlayerdtls.h
transportlayerice.cpp
transportlayerice.h
transportlayerlog.cpp
transportlayerlog.h
transportlayerloopback.cpp
transportlayerloopback.h
transportlayersrtp.cpp
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.