Not handling SCTP ParamType 32769

[daweifeng]

Your environment.

• Version: pion/[email protected], [email protected]
• Client: libdatachannel
• Other Information - related issue: Having Issue Opening Negotiated Data Channels paullouisageneau/libdatachannel#1030

What did you do?

I am trying to establish a WebRTC connection between a C++ client using libdatachannel and pion/webrtc. While using the latest commit from libdatachannel, the WebRTC connection keeps failing because libdatachannel implemented SCTP_ACCEPT_ZERO_CHECKSUM, which will send a SCTP ParamType 32769. It is not correctly handled by pion/webrtc causing the connection to failed. More discussion can be found on this Github discussion: paullouisageneau/libdatachannel#1030

Here is a log from pion/webrtc

sctp WARNING: 2023/11/15 22:28:55 [0xc0001c41e0] unable to parse SCTP packet failed to unmarshal INIT body: failed unmarshalling param in Init Chunk: unhandled ParamType: Unknown ParamType: 32769
sctp WARNING: 2023/11/15 22:28:55 [0xc0001c41e0] unable to parse SCTP packet failed to unmarshal INIT body: failed unmarshalling param in Init Chunk: unhandled ParamType: Unknown ParamType: 32769
ice TRACE: 22:28:55.776219 selection.go:176: Checking keepalive
sctp WARNING: 2023/11/15 22:28:56 [0xc0001c41e0] unable to parse SCTP packet failed to unmarshal INIT body: failed unmarshalling param in Init Chunk: unhandled ParamType: Unknown ParamType: 32769
ice TRACE: 22:28:57.777205 selection.go:176: Checking keepalive

What did you expect?

I am not an expert of WebRTC, but based on my discussion on with the auther of libdatachannel, ParamType: 32769 should be handled based on RFC9260

[Sean-Der]

Thanks for the ticket @daweifeng!

We need to get pion/sctp#284 merged. I will review

If you are interested @daweifeng I would appreciate your help reviewing the PR :)

[daweifeng]

Thank you! The PR fixes my issue. I will take a look at the PR as well!

[paullouisageneau]

@Sean-Der This has been marked as completed but the corresponding PR is not merged. The bug is still present and is breaking compatibility between pion and libdatachannel 0.20.

As discussed in paullouisageneau/libdatachannel#1030 (comment), the actual issue is not that parameter type 0x8001 is not handled (which is implemented by pion/sctp#284), it's that unmarshalling in pion seemingly fails on all unhandled parameters.

An SCTP endpoint does not need to support Zero Checksum Acceptable extension to connect with an endpoint that does. According to RFC 9260 that the endpoint behavior must depend on the highest-order two bits of the parameter type. Here it's 10, so the endpoint must skip the parameter and continue to process other parameters if it doesn't know it. Failing on unknown parameters breaks if peers attempt to negotiate SCTP extensions.