This repository was archived by the owner on Jun 19, 2023. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Interop test between Go and Js implementations #23
Interop test between Go and Js implementations #23
Changes from all commits
dc2042f
345d65c
2cb112f
d6adda2
2956313
e74f877
ea298c2
47dd8ed
a16b1dc
19db64e
9d6b10b
0f467df
efd09ca
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why not just put
const closed = ['closed', 'failed', 'disconnected'].includes(this.peer.connectionState);
Avoids the whole switch statement etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
our linting rules must be pretty relaxed as normally you would get an "empty interface" complaint here, no?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
where do these numbers come from, might be nice to add a line of comment about them?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure if a comment explaining is useful, but here is the grammar for the candidate line: https://www.rfc-editor.org/rfc/rfc8839.html#name-candidate-attribute .
The foundation (first number) is a way to encode ice candidates. The RFC specifies what the foundation should do here: https://www.rfc-editor.org/rfc/rfc8445.html#section-5.1.1.3 , but in practice it is not used much. This can be any number for our purposes.
The second number is the stream component.
1
is RTP and2
is RTCP. Since we multiplex RTP and RTCP over the same component, we use1
.The third number (after UDP) is the candidate priority. Since we have only 1 candidate, this does not matter in this SDP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I would do is make constants for this with very explicit declarative names, and you can link to the relevant paragraph in an RFC for each constant. I think that's enough documentation. Gives all the info with little effort.