• Home
  • History
  • Annotate
Name Date Size #Lines LOC

..30-Mar-2022-

build/H30-Mar-2022-4538

fuzztest/H30-Mar-2022-6845

ipc/H30-Mar-2022-1,9801,380

mdns_service/H30-Mar-2022-887765

srtp/H30-Mar-2022-1712

test/H30-Mar-2022-12,1789,352

third_party/H30-Mar-2022-35,81523,170

READMEH A D30-Mar-20221.8 KiB4633

SrtpFlow.cppH A D30-Mar-20227.3 KiB260194

SrtpFlow.hH A D30-Mar-20222.1 KiB7043

WebrtcTCPSocketWrapper.cppH A D30-Mar-20224.5 KiB12694

WebrtcTCPSocketWrapper.hH A D30-Mar-20222.2 KiB7034

common.buildH A D30-Mar-20223.3 KiB9588

dtlsidentity.cppH A D30-Mar-20229.9 KiB329249

dtlsidentity.hH A D30-Mar-20223.4 KiB10263

logging.hH A D30-Mar-20222.5 KiB6646

m_cpp_utils.hH A D30-Mar-2022708 2611

mediapacket.cppH A D30-Mar-20223.5 KiB143108

mediapacket.hH A D30-Mar-20222.9 KiB11678

moz.buildH A D30-Mar-2022747 2418

nr_socket_proxy_config.cppH A D30-Mar-20221.1 KiB3722

nr_socket_proxy_config.hH A D30-Mar-20221.2 KiB4220

nr_socket_prsock.cppH A D30-Mar-202250.5 KiB1,7841,272

nr_socket_prsock.hH A D30-Mar-202210.7 KiB321203

nr_socket_tcp.cppH A D30-Mar-20228.2 KiB311189

nr_socket_tcp.hH A D30-Mar-20223.7 KiB11851

nr_timer.cppH A D30-Mar-20227.7 KiB256140

nricectx.cppH A D30-Mar-202232.6 KiB1,113806

nricectx.hH A D30-Mar-202212.9 KiB423254

nricemediastream.cppH A D30-Mar-202221.6 KiB717532

nricemediastream.hH A D30-Mar-20227.5 KiB226110

nriceresolver.cppH A D30-Mar-20227.4 KiB235157

nriceresolver.hH A D30-Mar-20224.1 KiB12466

nriceresolverfake.cppH A D30-Mar-20225.2 KiB17696

nriceresolverfake.hH A D30-Mar-20224.3 KiB13977

nricestunaddr.cppH A D30-Mar-20222.9 KiB9569

nricestunaddr.hH A D30-Mar-20221 KiB3720

nrinterfaceprioritizer.cppH A D30-Mar-20227 KiB259205

nrinterfaceprioritizer.hH A D30-Mar-2022454 1910

rlogconnector.cppH A D30-Mar-20225.1 KiB187137

rlogconnector.hH A D30-Mar-20224.3 KiB12841

runnable_utils.hH A D30-Mar-20226.4 KiB222170

sigslot.hH A D30-Mar-202220.7 KiB620403

simpletokenbucket.cppH A D30-Mar-20222 KiB6131

simpletokenbucket.hH A D30-Mar-20221.4 KiB5519

stun_socket_filter.cppH A D30-Mar-202214.1 KiB433335

stun_socket_filter.hH A D30-Mar-20221.4 KiB4228

test_nr_socket.cppH A D30-Mar-202237.3 KiB1,140827

test_nr_socket.hH A D30-Mar-202213.3 KiB372189

transportflow.cppH A D30-Mar-20222.1 KiB7946

transportflow.hH A D30-Mar-20223.1 KiB10642

transportlayer.cppH A D30-Mar-20221.4 KiB5233

transportlayer.hH A D30-Mar-20223.2 KiB11158

transportlayerdtls.cppH A D30-Mar-202245.9 KiB1,5611,213

transportlayerdtls.hH A D30-Mar-20226 KiB191127

transportlayerice.cppH A D30-Mar-20226 KiB184100

transportlayerice.hH A D30-Mar-20221.7 KiB6534

transportlayerlog.cppH A D30-Mar-20221.5 KiB5031

transportlayerlog.hH A D30-Mar-20221 KiB4020

transportlayerloopback.cppH A D30-Mar-20223.4 KiB12383

transportlayerloopback.hH A D30-Mar-20222.6 KiB11472

transportlayersrtp.cppH A D30-Mar-20226.8 KiB224166

transportlayersrtp.hH A D30-Mar-20221.1 KiB4425

README

1This is a generic media transport system for WebRTC.
2
3The basic model is that you have a TransportFlow which contains a
4series of TransportLayers, each of which gets an opportunity to
5manipulate data up and down the stack (think SysV STREAMS or a
6standard networking stack). You can also address individual
7sublayers to manipulate them or to bypass reading and writing
8at an upper layer; WebRTC uses this to implement DTLS-SRTP.
9
10
11DATAFLOW MODEL
12Unlike the existing nsSocket I/O system, this is a push rather
13than a pull system. Clients of the interface do writes downward
14with SendPacket() and receive notification of incoming packets
15via callbacks registed via sigslot.h. It is the responsibility
16of the bottom layer (or any other layer which needs to reference
17external events) to arrange for that somehow; typically by
18using nsITimer or the SocketTansportService.
19
20This sort of push model is a much better fit for the demands
21of WebRTC, expecially because ICE contexts span multiple
22network transports.
23
24
25THREADING MODEL
26There are no thread locks. It is the responsibility of the caller to
27arrange that any given TransportLayer/TransportFlow is only
28manipulated in one thread at once. One good way to do this is to run
29everything on the STS thread. Many of the existing layer implementations
30(TransportLayerIce, TransportLayerLoopback) already run on STS so in those
31cases you must run on STS, though you can do setup on the main thread and
32then activate them on the STS.
33
34
35EXISTING TRANSPORT LAYERS
36The following transport layers are currently implemented:
37
38* DTLS -- a wrapper around NSS's DTLS [RFC 6347] stack
39* ICE  -- a wrapper around the nICEr ICE [RFC 5245] stack.
40* Loopback -- a loopback IO mechanism
41* Logging -- a passthrough that just logs its data
42
43The last two are primarily for debugging.
44
45
46