Respond with ParamOutgoingResetRequest

[algesten]

This is a fix for the issue reported in algesten/str0m#286

[algesten]

This is marked as Draft, since I think we need to check spec here. It might be the close calls shouldn't be automatic in sctp-proto, but a stream from outside stream.stop() – looking at pion that might be what we want to do.

@k0nserv is good with the spec detective work.

[k0nserv]

The spec seems pretty clear: respond with an OutgoingResetRequest when one is received to confirm the closure. However, I'm not sure Pion implemented it like this in the end, there's a lot of relevant discussion in pion/sctp#238

[Marcel-G]

I tried to replicate pion's fix in webrtc-rs/webrtc which seems to work

[algesten]

So maybe this solve is more correct. If only we could make it close straight away and not wait for the next RTO.

[algesten]

We are not waiting for any RTO. We are sending something straight away, but it seems this gets rejected and then we manage to send the close confirm on retransmit.

[algesten]

I think this might be ready. The problem was that the response ParamOutgoingResetRequest needs to have the reconfig_request_sequence_number set. And now it does. The channels close promptly.

[algesten]

Hi @rainliu what do you think about this fix?