search

sipsorcery-org / sipsorcery

A WebRTC, SIP and VoIP library for C# and .NET. Designed for real-time communications apps.
https://sipsorcery-org.github.io/sipsorcery
Other
1.42k stars 432 forks source link

Datachannel Reliability Implementation #701

Open camnewnham opened 2 years ago

camnewnham commented 2 years ago

Currently RTCDataChannelInit doesn't appear to have any effect: https://github.com/sipsorcery-org/sipsorcery/blob/c153907c3d478e179974ed8aa426233be5a7aeaa/src/net/WebRTC/RTCDataChannel.cs#L92 https://github.com/sipsorcery-org/sipsorcery/blob/fb00a8405ae36f96f62653d4c0bb46db53863edf/src/net/WebRTC/RTCPeerConnection.cs#L1422 So by extension presumably all data channels created are reliable and unordered - even those that are remotely created to be unordered/unreliable. https://github.com/sipsorcery-org/sipsorcery/blob/c153907c3d478e179974ed8aa426233be5a7aeaa/src/net/WebRTC/RTCDataChannel.cs#L199

Are there any current plans to continue this implementation? If not; can you provide any guidance on implementation so I can investigate further (and PR if successful).

sipsorcery commented 2 years ago

The SctpDataSender and SctpDataReceiver classes support both ordered and unordered packets. There are also a bunch of unit tests checking that both work. That'd be the place to start for a PR.

The SctpDataSender has a hard coded value of false for unordered. For the RTCPeerConnection options to have effect they need to get down to that method and the equivalent for the receiver.

It shouldn't be that big of a job. The big chunk of work, the SCTP implementation is done. I just lost steam at the end of if and didn't get around to wiring up all the configuration options. I defaulted to supporting the hardest case, or ordered packets, and left the easier cases for later. And of course real work got in the way and I didn't end up comign abck to it.

camnewnham commented 2 years ago

Thanks for the advice. I've done some reading of the datachannel and sctp specs, and into your implementation of both.

From the datachannel spec:

SCTP, as specified in [RFC4960] with the partial reliability extension (PR-SCTP) defined in [RFC3758] and the additional policies defined in [RFC7496], provides multiple streams...

So those documents should define a pretty clear implementation plan for this feature - most notably the addition of the FORWARD_TSN chunk type.

They don't define the conditions for when a chunk should be abandoned - so it makes sense that we can plug in the maxRetransmits and maxPacketLifetime to determine this.

I'll look into implementing the extension and additional policies.