3 ms·

I am sure there are even more implementations that I am not aware of. * https://github.com/pion/sctp https://github.com/pion/sctp * https://github.com/aiortc/

I am sure there are even more implementations that I am not aware of. * https://github.com/pion/sctp https://github.com/pion/sctp * https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsctptransport.py https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsct... * https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/net/dcsctp/ https://source.chromium.org/chromium/chromium/src/+/main:thi... * https://github.com/sctplab/usrsctp https://github.com/sctplab/usrsctp People don't make these decisions for technical reasons only. Career wise it is a bad choice to spend your time working on pre-existing technologies. You don't become a distinguished engineer by iterating on existing technologies. You become one by being the creator of something new. I think QUIC is great and does a good job solving the problems it was designed to solve. It is disingenuous to pretend these decisions were made only for technical reasons.

Orphis 5y ago
3 of those are related to DataChannels in WebRTC, which at this point is baked into the standard and can't be replaced by another protocol. The SCTP in DataChannels is quite limited, that subset is reasonable to implement somehow. Only the last one is really general purpose and has had a lot of security issues as well. Fun fact: I do work on one of those implementations and with another one, and it's out of necessity rather than a career choice.
- Sean-Der 5y ago
  I know you understand libusrsctp Florent. I created Pion, I feel prety comfortable with SCTP and WebRTC in general as well. RtcQuicTransport tried to replace SCTP and it didn't work. It would be possible to replace SCTP if something better was available. SCTP has lots of great stuff like FORWARD-TSN. QUIC didn't offer anything compelling over it. Also would come with a huge cost of making WebRTC larger and losing interop with all the existing clients. libusrsctp has had security issues, but I don't think the protocol is the problem. The issue is C/C++. QUIC implementations are going to have the same class of bugs. Chrome/libwebrtc has plenty of security issues in other areas besides SCTP. Rust/Go doesn't fix everything, but one less thing to worry about at least.

Orphis 5y ago

3 of those are related to DataChannels in WebRTC, which at this point is baked into the standard and can't be replaced by another protocol. The SCTP in DataChannels is quite limited, that subset is reasonable to implement somehow. Only the last one is really general purpose and has had a lot of security issues as well. Fun fact: I do work on one of those implementations and with another one, and it's out of necessity rather than a career choice.

Sean-Der 5y ago
I know you understand libusrsctp Florent. I created Pion, I feel prety comfortable with SCTP and WebRTC in general as well. RtcQuicTransport tried to replace SCTP and it didn't work. It would be possible to replace SCTP if something better was available. SCTP has lots of great stuff like FORWARD-TSN. QUIC didn't offer anything compelling over it. Also would come with a huge cost of making WebRTC larger and losing interop with all the existing clients. libusrsctp has had security issues, but I don't think the protocol is the problem. The issue is C/C++. QUIC implementations are going to have the same class of bugs. Chrome/libwebrtc has plenty of security issues in other areas besides SCTP. Rust/Go doesn't fix everything, but one less thing to worry about at least.