-
Notifications
You must be signed in to change notification settings - Fork 115
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
Adding unassignedmedia event #283
Conversation
Thanks @martinthomson |
LGTM |
when authenticated media packets arrive from the remote peer that | ||
are not assigned to a <code><a>MediaStreamTrack</a></code>. | ||
Unauthenticated packets are always discarded without generating an | ||
event. |
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 do you mean by unauthenticated. There are two cases here ... one is a ranodm packet with where SRTP integrity fails, and one where a valid DTLS session is set up and the packet is valid SRTP encrypted with keys set up in DTLS but there is not yet a answer with a fingerprint that for that DTLS session. We don't want to drop those - the whole point is to get notified about them.
one comment but looking reasonable good. I still would like the option of playing media where I did not yet know the fingerprint of the far end and this PR seems to keep avoiding addressing that problem. |
<dt>unsigned long ssrc</dt> | ||
<dd>See <a><code>RTCUnassignedMediaEvent.ssrc</code></a></dd> | ||
<dt>unsigned byte payloadType</dt> | ||
<dd>See <a><code>RTCUnassignedMediaEvent.payloadType</code></a></dd> |
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.
Wasn't this syntax (type.field) what was objected to because it looks like an accessor to a static? @adam-be has been fixing some of these - he may have comments.
Closing per Seattle discussion, to be replaced by new text (responsible @pthatcherg) |
@stefhak, @fluffy, I think that this is a good replacement for #29.
This is mostly a restoration of the previous one, but I removed provision for delaying the event (that hides information). I also provided a little better justification. We can talk about justification in more detail at the interim.