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

receive() rtcp.ssrc advice for implementations #462

Closed
robin-raymond opened this issue Apr 7, 2016 · 7 comments
Closed

receive() rtcp.ssrc advice for implementations #462

robin-raymond opened this issue Apr 7, 2016 · 7 comments

Comments

@robin-raymond
Copy link
Contributor

I think we need to advice how to auto-fill this value in implementations.

@ibc
Copy link
Contributor

ibc commented Apr 7, 2016

I think that the browser should fill it, and the API should expose a getter to retrieve it, and a setter to override the value initially chosen by the browser.

@robin-raymond
Copy link
Contributor Author

@ibc I don't want to expand the scope of the bug; This is just about advice on how to auto-fill by implementations; Otherwise this bug could end up being 20 comments deep like other issues!

@ibc
Copy link
Contributor

ibc commented Apr 16, 2016

Sorry, I was obsessed with Trending Topic. Regarding the original text:

I think we need to advice how to auto-fill this value in implementations.

I don't think it is a good idea to mix both the API spec and "guidelines for implementors" in the same doc (this includes the "RTP Matching Rules" section).

@robin-raymond
Copy link
Contributor Author

I don't think it is a good idea to mix both the API spec and "guidelines for implementors" in the same doc (this includes the "RTP Matching Rules" section).

We don't have two specs currently. The idea is (and has been for a while) that the spec is enough for an implementer to take down and with all related documents be able to implement. It's not exclusively a "how to program using the API" specification. Also, this ensures that people using the API can have an expected consistent behaviour which is non ambiguous where we can point to a spec for compliance. Anyway, that's a separate issue than the original comment.

@ibc
Copy link
Contributor

ibc commented Apr 16, 2016

Anyway, that's a separate issue than the original comment.

Well, IMHO it is not a separate issue from the original comment, because it is my rationale to argue that "we don't need to advice how to auto-fill SSRC values in implementations". :)

But, if the spec covers both API and stuff for implementors, then sure.

@robin-raymond
Copy link
Contributor Author

"we don't need to advice how to auto-fill SSRC values in implementations"

Understood; but as splitting into two specs is a bigger scope issue (and would involve a lot of changes), the original issue stands on its own regardless if in one spec or split into two;

@ibc
Copy link
Contributor

ibc commented Apr 16, 2016

Then yes :)

aboba added a commit that referenced this issue May 5, 2016
aboba added a commit that referenced this issue Jun 6, 2016
aboba added a commit that referenced this issue Jul 8, 2016
Fix for Issue #462

Rebase of PR #536
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants