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