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

Status of 2.X? #140

Closed
ibc opened this issue Jan 22, 2016 · 10 comments
Closed

Status of 2.X? #140

ibc opened this issue Jan 22, 2016 · 10 comments

Comments

@ibc
Copy link
Contributor

ibc commented Jan 22, 2016

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_ and srtp_ 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).

@jfigus
Copy link
Contributor

jfigus commented Feb 2, 2016

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.

@ibc
Copy link
Contributor Author

ibc commented Feb 2, 2016

May you please clarify regarding my question above (global or per session SSRC table)?

:)

@jfigus
Copy link
Contributor

jfigus commented Feb 2, 2016

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.

@ibc
Copy link
Contributor Author

ibc commented Feb 2, 2016

The SSRC is global to srtp_ctx_t. The application can instantiate multiple srtp_ctx_t (a.k.a. srtp_t) if needed.

Sorry, my fault. Just a simple question:

  • I create a srtp_t with policy ssrc_any_inbound.
  • I receive a SRTP packet with ssrc 1234 and unprotect it.
    • Here I assume that a new srtp_stream_t is created with ssrc 1234 within the srtp_t session.
  • Later I call srtp_remove_stream(session, 1234).

Will the latest call remove the internally created srtp_stream_t session so I can start receiving again packets with ssrc 1234 with a 100% reseted stream and sequence numbers?

Thanks a lot.

@ibc
Copy link
Contributor Author

ibc commented Feb 2, 2016

Therefore, I wouldn't conclude that SSRC is handled globally by the library. There are currently no plans to change this hierarchy.

And I hope such a hierarchy is never changed :)

@jfigus
Copy link
Contributor

jfigus commented Feb 2, 2016

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.

@jfigus
Copy link
Contributor

jfigus commented Feb 2, 2016

2.0.0 has been released.

@ibc
Copy link
Contributor Author

ibc commented Feb 2, 2016

Thanks!

@ukreator
Copy link
Contributor

ukreator commented Feb 2, 2016

@ibc make sure you call srtp_remove_stream(session, htonl(1234)). See #105 for details

@ibc
Copy link
Contributor Author

ibc commented Feb 2, 2016

Thanks a lot @ukreator

@jfigus jfigus closed this as completed Feb 3, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants