x186k / deadsfu

Dead-simple WebRTC broadcasting. From the browser, or your application. Cloud-native and scalable.

x186k

Steve Jobs said: “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.”

deadsfu's Issues

Observed issue with ipv6 ddns5.com registration

ubuntu@ip-172-26-5-146:~$ sudo ./sfu1 -urls https://foobadbad12.ddns5.com -https-detect-ip public
E 00:20:04.127287 debug output NOT enabled
E 00:20:06.128514 https://foobadbad12.ddns5.com is BROWSER URL
E 00:20:06.128652 https://foobadbad12.ddns5.com/pub is ingress signalling URL
E 00:20:06.128726 https://foobadbad12.ddns5.com/sub is egress signalling URL
), url: [https://api.ddns5.com/update?domains=foobadbad12.ddns5.com&ipv6=%3Cnil%3E&token=&verbose=true], body: KO
Bad IP address <nil>
ubuntu@ip-172-26-5-146:~$

Implement N audio, N video tracks

Detect mDns ice candidates, and report on stderr about issues

Ubuntu 20.04 doesn't support mdns out of the box, as far as I can tell,
and chrome's use of it caused my stuff to break.
This would be nice to report on the stderr console to users.

SFU-Subscriber-side: Make SFU generate offer, not subscriber

I've had many discussions on the Pion Slack group regarding who should generate the offer
at the subscriber side of the SFU: SFU vs subscriber.
It was always or often said the SFU should generate the offer.
I never could get a straight answer as to why this was better, and could not see a large advantage
regarding media negotiation.

Also, for us, with simple HTTP signaling, it is nice for the sub to generate it, as offer goes in body, and ans goes in resp.

I finally see a strong case for why the SFU should generate the offer, and we should then have double-HTTP requests in order to do so.

If the SFU (the upstream) generates the offer, the downstream can use the number of audio+video tracks
to generate the answer. So, if the upstream offers 20 tracks of video, the downstream-SFU can craft an
answer to accept 20 all 20 tracks.
This is important as part of an SFU hierarchy.

With the current model (downstream-offers), the downstream must choose how many tracks to receive without
regards to how many the upstream has available.
The current code allows three tracks.
We really want to the downstream-SFU to forward all tracks, whether 3 or 100.

Implement SFU aud/vid channel REST call and aud/vid count parameter

Replace http.ListenAndServe to enable ReadTimeout and WriteTimeout

Instead, create a http.Server instance with ReadTimeout and WriteTimeout and use its corresponding methods, like in the example a few paragraphs above.

https://blog.cloudflare.com/the-complete-guide-to-golang-net-http-timeouts/

Lack of Camera causes silent failure on html

in the console, we get this error when the camera is disconnected:

pub error DOMException: Requested device not found

Decouple RX/TX packet goroutines

Remove the many subMapMutex.Lock(), Unlock() calls, possibly

Because of the nature of Go maps, iterating the subscribe set means a fair number
of subMapMutex.Lock(), Unlock() calls

It might be cleaner to translate the subscriber uniq id to an array/slice index, which
then gets iterated, skipping empties.

No Location header in response when using WHIP

Hi there, it's me again 😄

I'm still working on those WHIP interop tests, so after getting your WHIP/WHAP client to work with my WHIP server (and Janus), I now wanted to test my WHIP client with deadsfu instead.

A first attempt got my WHIP client to crash, and apparently the cause was a missing Location header for the WHIP resource in the response to the POST. I fixed the crash in my client, but this now means I have no way to trickle candidates to deadsfu the WHIP way. Is this indeed not supported anymore? Should candidates be added as part of the SDP offer instead? If so I'll have to update the WHIP client as I think I don't support this yet.

Thanks!