-
Notifications
You must be signed in to change notification settings - Fork 476
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
Status of 2.X? #140
Comments
You're probably right, it's time to release 2.0.0. There haven't been many issues popping up on the master branch and the code has been there for quite some time. I'll do the release in the near future. |
May you please clarify regarding my question above (global or per session SSRC table)? :) |
The SSRC is global to srtp_ctx_t. The application can instantiate multiple srtp_ctx_t (a.k.a. srtp_t) if needed. Therefore, I wouldn't conclude that SSRC is handled globally by the library. There are currently no plans to change this hierarchy. |
Sorry, my fault. Just a simple question:
Will the latest call remove the internally created Thanks a lot. |
And I hope such a hierarchy is never changed :) |
In theory you're proposal should work. I've never tested this exact flow myself. But assuming you have the stream template setup right, it should work. |
2.0.0 has been released. |
Thanks! |
Thanks a lot @ukreator |
Hi, which is the status of the 2.x version? is it production/testing ready?
The API is much better and clean, with proper
SRTP_
andsrtp_
prefixes for all the exported stuff. Good work.Just a question: does 2.x still handle SSRC globally? 1.x handles them globally, which means that the same SSRC cannot be used within different SRTP sessions (this is not cool when it comes to a SFU server architecture, in which the server relays an incoming stream to N endpoints, having to rewrite the incoming SSRC to N different values).
The text was updated successfully, but these errors were encountered: