Some questions:

Can it handle the signalling on its own?

Can it substitute any part of a webrtc session? That is, can I have either browser-aiortc, aiortc-browser or aiortc-aiortc?

Can it be used to build, say, a desktop application doing webrtc communication?

You can indeed use aiortc facing a browser, itself or any valid WebRTC endpoint.

Sure, you can use aiortc for a desktop application. However for this specific usecase embedding a browser which supports WebRTC (say QtWebEngine) might be a good option too.

But I can only notice quite a bit of mismatch between your APIs and the current spec. Do you plan on updating your implementation to match it?

I've had some great interactions with the Mozilla crowd (hey Lennart, hey Nils) - looking forward to more of the same!

For example, RTCRtpSender.getParameters is missing and the setParameters seems to be missing (unless that's the send function). And as far as I can tell, you are not supposed to call setParameters without getParameters first, so that's not spec compliant ;)

And of course, the sendEncodings property of the init parameters in addTransceiver is missing. It is required to setup simulcast (and later SVC when we standardize it).

https://github.com/jlaine/aiortc/issues/76

aiortc's RTCPeerConnection indeed uses RTCRtpSender.send to apply parameters. This is directly inspired by ORTC:

http://draft.ortc.org/#dom-rtcrtpsender-send

If you want to implement ORTC, fine, but you should probably do it in another package and make sure you don't expose fields in WebRTC that aren't part of the standard. Some fields (like the SSRC field) is not exposed for good reasons.

It's really important for libraries like this to exist so more people can build apps without binding to massive hard-to-compile browser codebases. Thank you for working on it!

Also kudos for going asyncio and Python 3 right from the gate.

--

[1] At least semi-functioning with DataChannel support. Lots of started attempts that have never gotten this far. The other implementation is in Go: https://github.com/pions/webrtc

Also somebody has forked erlyvideo to deal with WebRTC

https://github.com/jlaine/aiortc/tree/master/examples

I personally like the "server" and "apprtc" demos as you can easily talk to a browser. They illustrate slightly different things:

- "apprtc" relies on a third-party signaling service, and shows you how you can play media from a file / record it to a file, or generate video frame-by-frame.

- "server" shows you how you can combine media and signaling into a single Python-based server, and how you can apply image processing on the fly to the received video.

It could really change how people design systems, have servers exchange data directly instead of overloading message brokers. Could have an even bigger impact on users! Instead we could see users exchanging files directly instead of depending on paid services!

I am the author of https://github.com/pions/webrtc we implemented SCTP, SRTP and working on DTLS now. So if you ever want to grab anything please do :) and always happy to chat if there is anything that could be better/any way we could help the rust implementation

Any info or branch where I can watch? I am watching your project closely and curious about the OpenSSL requirement for DTLS considering Go's quality crypto stack. Is the work you're talking about for removing this dependency? If not, I might take a stab at it.

There isn't a DTLS implementation right now that is maintained, and adopting one would be more work then starting from scratch. I didn't know anything about TLS before I started, so learning as I go.

I would love to work together on this! If you want to open a PR/issue I can give you commit access. Also join the Gophers slack and join the #pion channel, there is plenty of work to do and would love to split it with someone else :)

Yes this will remove the OpenSSL dependency! I am really excited when people can build for any platform that Go is supported on. After that I also want to start shipping C APIs, hoping people can build lots of cool things with it then.

> After that I also want to start shipping C APIs, hoping people can build lots of cool things with it then.

I've found Go's FFI export story to be weak, especially on Windows.

I am as well. After having read the spec and seeing its differences from TCP-based TLS, I may have a go, but not sure when. I'll give a shout if I get anywhere of note.

https://bugzilla.mozilla.org/show_bug.cgi?id=1443032

One implementation (libusrsctp-based) you might want to interop with is rawrtc. Like aiortc's datachannel-cli example, it features copy-and-paste signaling which makes testing easy.

https://github.com/rawrtc/rawrtc

Lennart, rawrtc's author is very knowledgeable in all things DataChannels and active in the standardization process.

Is your work on github/gitlab?

[1] https://github.com/simmons/webrtc-sctp [2] https://cafbit.com/post/rust_webrtc_data_channels/

Starting with aiortc 0.9.9, there is now also deep integration with PyAV for all your FFmpeg needs.

- At the lowest level : aiortc uses PyAV's AudioFrame and VideoFrame class, and PyAV is soon to gain more ndarray converters: https://github.com/mikeboers/PyAV/pull/415

- At a higher level : aiortc provides MediaPlayer and MediaRecorder classes to read or write audio/video

Can this library in the current state record audio of both local and remote streams at the same time and could you mute a user for every participant on the call?

I've found heavy usage of asyncio.Queue to bridge consumers / producers does not lead to amazing performance, so I'm trying to cut down on that pattern in favour of.. callbacks (I know - not very asyncio-ish). A good testcase for testing performance without media encoding is transferring large amounts of data over datachannels (see datachannel-filexfer example). I usually hit ~ 70Mbps on the loopback interface, which is more than I've managed to get out of browsers.

I can't say I have experience with using aiortc at scale yet, so there are almost certainly so hotspots I haven't seen.

https://groups.google.com/a/chromium.org/forum/#!topic/blink...

In any case, the SCTP reference implementation in FreeBSD can do RFC 6951 encapsulation, someone could add it to Linux too.

That FreeBSD can do that is neat, but just it doing that is pretty much the answer why a library wouldn't implement it, or at least not as a priority.

In short ORTC is: break WebRTC into objects you manipulate directly, instead of everything being instanciated via RTCPeerConnection. There is significant overlap between the two specs, for instance RTCRtpReceiver / RTCRtpSender.