Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

No way to use the RTX SSID of a TrackLocalStaticRTP #2994

Open
jech opened this issue Jan 7, 2025 · 7 comments
Open

No way to use the RTX SSID of a TrackLocalStaticRTP #2994

jech opened this issue Jan 7, 2025 · 7 comments

Comments

@jech
Copy link
Member

jech commented Jan 7, 2025

I have a TrackLocalStaticRTP, and I have successfully negotiated an associated RTX SSID. Unfortunately, there is no way I can find to write a packet on the associated RTX SSID.

(The obvious workaround would be to use an interceptor, but this is difficult in my case, since I'm sharing a single NACK buffer between multiple PeerConnections, and there is no way to pass the packet buffer to the interceptor. It could probably be hacked around, but it seems simpler to provide a direct handle to the RTX SSID.)

@jech
Copy link
Member Author

jech commented Jan 7, 2025

The obvious solution is to add a method WriteRTX to TrackLocalStaticRTP, which I'm quite willing to do.

Any better ideas?

@joeturki
Copy link
Member

joeturki commented Jan 7, 2025

I think adding it to TrackLocalStaticRTP maybe wouldn't be a good abstraction.

@joeturki
Copy link
Member

joeturki commented Jan 7, 2025

I'm considering rethinking the entire RTX logic to make it more systematic. One idea is to provide an API that allows for manual handling of all RTX logic, like creating a reusable RTX writer. additionally, we could introduce a "semi-automatic" approach where users can make a " RTPPacketHistory " interface to implement their own logic. Also all while making interceptors to work seamlessly.

rn, I'm reading entire Pion codebase i do plan to come up with a new design for handling RTX. should include the introduction of new types and more flexibility for custom logic and reusability, also it should be up to the spec, i will try to come with something in two days.

@jech
Copy link
Member Author

jech commented Jan 7, 2025

Joe, we're only just getting to grips with v4. If you change everything, you're going to lose a lot of people.

@joeturki
Copy link
Member

joeturki commented Jan 7, 2025

I'm just saying we should add more tooling to handle RTX streams, including exposing a RTXWriter type and a RTPPacketHistory type for example. these additions shouldn't break anything,

I think just adding WriteRTX and WriteRTPRTX would be easiest fix for this issue but we should have a better RTX abstraction.

@jech what do you think?

@jech
Copy link
Member Author

jech commented Jan 7, 2025

The RTXWriter suggestion seems fairly uncontroversial. For RTPPacketHistory, please see https://github.com/jech/galene/tree/master/packetcache, and please make sure it can be adapted to your interface.

@joeturki
Copy link
Member

joeturki commented Jan 7, 2025

Thank you, I'm going to read this, I think i will make a proposal for the suggestion (no code, just design), before I implement anything :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

Successfully merging a pull request may close this issue.

2 participants