Datachannel Reliability Implementation

[camnewnham]

Currently RTCDataChannelInit doesn't appear to have any effect:

sipsorcery/src/net/WebRTC/RTCDataChannel.cs

Line 92 in c153907

// TODO: Apply init settings.

sipsorcery/src/net/WebRTC/RTCPeerConnection.cs

Line 1422 in fb00a84

// TODO: Set reliability, priority etc. properties on the data channel.

So by extension presumably all data channels created are reliable and unordered - even those that are remotely created to be unordered/unreliable.

sipsorcery/src/net/WebRTC/RTCDataChannel.cs

Line 199 in c153907

ChannelType = (byte)DataChannelTypes.DATA_CHANNEL_RELIABLE_UNORDERED,

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]

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 back to it.

[camnewnham]

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.