fix(webrtc): preserve read half on STOP_SENDING frames

[racequite]

Description

Preserve WebRTC stream half-close semantics when processing control frames.

A payload-less STOP_SENDING frame previously caused poll_read to return Ok(0), incorrectly signaling EOF even though STOP_SENDING only closes the local write half. Continue polling for inbound data after handling this flag.

Report RESET as ConnectionReset on the first read instead of initially returning normal EOF. When a FIN frame carries a payload, deliver the payload before reporting EOF.

AI Assistance Disclosure

Tools used (required — write none if no AI was used): OpenAI Codex

Attestation (required):

• I have read every line of this diff, understand what it does, and can explain it in review.

Notes & open questions

The protobuf schema permits a flag and payload in the same frame. The implementation therefore delays handling a payload-carrying FIN until its payload has been consumed. RESET remains immediate and discards its payload.

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• A changelog entry has been made in the appropriate crates

[getong]

Besides, webrtc releases 0.20, can you also update webrtc in this pr?
https://crates.io/crates/webrtc

[racequite]

Besides, webrtc releases 0.20, can you also update webrtc in this pr? https://crates.io/crates/webrtc

Thanks for the heads-up. I tried updating webrtc from 0.17 to 0.20 locally, but it does not appear to be a straightforward dependency bump.

Besides the removal of the pem feature, 0.20 replaces the old APIBuilder / RTCPeerConnection and detached PollDataChannel APIs with the new PeerConnectionBuilder and event-based DataChannel API.

More importantly, the current libp2p WebRTC Direct transport relies on a custom UDP mux through SettingEngine::set_udp_network, while that support appears to be unavailable / still TODO in 0.20.

Would you prefer to keep this bug-fix PR focused and track the 0.20 migration separately? If the migration should be done in this PR, could you point me to the intended replacement for the custom UDP mux and detached data-channel APIs?

[getong]

https://github.com/getong/rust-libp2p/tree/webrtc-0.20
You can fork this branch , and copy some files from it. I am nor webrtc professional, I made it with codex.

[racequite]

https://github.com/getong/rust-libp2p/tree/webrtc-0.20 You can fork this branch , and copy some files from it. I am nor webrtc professional, I made it with codex.

I think you should submit a separate PR to do this.

[getong]

I am not good at webrtc, you can take a review and copy it .

[racequite]

I am not good at webrtc, you can take a review and copy it .

I'm just curious, are you the maintainer of this project or something else?

[getong]

no

[racequite]

no

We'd better listen to the advice of the maintainers or members first.

[racequite]

@jxs Hi, would you mind reviewing this WebRTC stream fix?

It preserves the read half after STOP_SENDING, reports RESET as ConnectionReset, and delivers a payload before EOF when FIN and data arrive in the same frame. Regression tests cover all three cases.

I’m keeping the webrtc-rs 0.20 migration out of this PR because that requires broader transport/API changes and seems better handled separately.

Thanks.