EricssonResearch / EricssonResearch/openwebrtc
Gap to current standard specs
- Dominant language
- C
- Stars
- 1.8k
- Forks
- 531
- PR merge metrics
- No merged PRs in 30d
Description
List pulled off the top of my head (you can edit/add of course - I likely will):
- [ ] Change addStream to addTrack
- [ ] Introduce Transceiver and addTransceiver
- [ ] Support for port multiplexing and "Bundle" (Bundle is the SDP negotiation mechanism for port mux)
- [ ] change "RTP/SAVPF" to "UDP/DTLS/RTP/SAVPF" (something like that :) ) in offers, and fall-back to the old string if an incoming offer comes with the old string (eventually only the new way is needed, but FF/Chrome does it this way) - a PR for this has been created: #497
- [ ] Add "MID" to outgoing RTP headers and to SDP, and MID must be selectable beforehand from application (i.e. not something the RTP stack decides at activation time)
- [ ] Be able to send and receive ArrayBuffers on data channel
- [ ] Allow selection of cameras and microphones (? already supported?)
- [ ] set-able SSRC for RTX
- [ ] stop receiving if Fingerprint does not match
- [ ] APIs for certificate management
- [ ] Isolated media, Identity support
- [ ] Stats API
- [ ] Recorder
- [ ] Capture from DOM element
Contributor guide
Research direction
The issue lists several possible gaps with current WebRTC specifications, including transceivers, SDP negotiation, data channels, and stats, but does not identify files, tests, or a single scoped change. First choose a specific item and compare the existing API and behavior with the relevant standard; done would need to be defined for that item. The issue is years old, so check whether the work remains relevant before starting.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- audio-video-rtc
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 15/100