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

NITs #76

aboba opened this Issue May 2, 2014 · 0 comments


None yet
2 participants
Copy link

aboba commented May 2, 2014

From Shijun Sun:

  1.  RTCDtlsParameters, “fingerprint” could be “fingerprints”.  (singular --> plural)
  2.  Missing example 1, some other examples…
  3.  We expect RTCDtlsTransportState should be monotonic. Please confirm and specify in the spec.
  4.  RTCIceTransport allows empty constructor.  This can’t be usable given all the attributes are read-only. Should fix the constructor.  Remove “optional”.
  5. setRemoteParameters is still used in the Example 2
  6. RTCIceListener right now is still just an “options”.  First, we can’t set a dictionary (like the “options”) as an attribute to start with.  What else are expected on the listener?  Why “options” is not readonly?  What if the “options” changes while being used to create other transport?
  7. RTCRtpSender, the spec should provide algorithms/steps when “track” and “transport” changes dynamically.  Using method, e.g. setTrack(…) will be better.
    a. For example, what is the state of current “track” and “transport”, and what is the state of the new “track” or new “transport”.
    b. Can the new “track” be different type? E.g. video -> audio
    c. When the new “transport” uses different ICE ports, should the RtpParameters be renegotiated?
    d. etc.
    e. Events/eventhandlers should be defined if any async operations and feedbacks are expected
  8. RTCRtpReceiver, same on the “transport” given it is not read-only.
    a. Does a “transport” change mean a “track” change implicitly? What is the impact to downstream?
    b. Might just be clearer to use a new RTP receiver.
  9. RtpCodec, what is the meaning of Codec Clock?  Is numChannels applicable to video?  Why is it nullable?  No need of “?” marks?
  10. RTCRtpCodecParameters, payloadType is nullable, so need a “?” after “byte”.
  11. Same in RTCRtpEncodingParameters, 3 items.
  12. RTCRtpEncodingParameters.  What is the purpose of “active”?
    a. Why “codecName” is nullable?
    b. “priority” should have a range.
    c. “scale” should not be more than 1.0
  13. RTCRtpFecParameters, can we get an enum for “mechanism”?
  14. RTCRtpRtxParameters, “ssrc” should be nullable, i.e. with “?”
  15. RTCRtpHeaderExtensionParameters, “id” with a “?”

@robin-raymond robin-raymond added the 1.1 label May 2, 2014

robin-raymond pushed a commit to robin-raymond/ortc that referenced this issue May 14, 2014

Robin Raymond
- ICE restart explanation added, as described in Issue 59

-Fixes for error handling, as described in Issue 75

- Fixes for miscellaneous NITs, as described in Issue 76

- Enable retrieval of the SSRC to be used by RTCP, as described in Issue 77

- Support for retrieval of audio and video capabilities, as described in Issue 81

- getStats interface updated, as described in Issue 82

- Partially addressed SVC issues described in Issue 83

- Partially addressed statistics update issues described in Issue 85
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment