receive() rtcp.ssrc advice for implementations

[robin-raymond]

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

[ibc]

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]

@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]

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]

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]

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]

"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]

Then yes :)