Re: Review of current WebRTC PC spec

Cullen - do you want to separate these into issues and file them into
github yourself, or do you want/expect someone else to pick up the
filing for you?


Den 20. sep. 2016 11:51, skrev Cullen Jennings (fluffy):
> 
> Few comments - most small things or just questions on things we might want to consider changing mixed with a few more substantial things where I think we are missing some needed text. 
> 
> RTCIceCredentialType. “turnToken” would be better name than “token”  to not add confusion when other token types are defined. 
> 
> In RTPtcpMyxPolixy value of negotiate. Need to clearly indicate browsers are not required to implement and negotiate this and applications should not assume this will work. Need an error if it does not. 
> 
> Make it clear that when voiceActivityDetection is false, that browser must send media even if it silent 
> 
> What does “cannot be applied at the media layer” mean 
> 
> The algorithm for applying local / remote SDP does not deal with errors caused when setting things state where that is not allowed - an error should be generated. This is in step 3 and for of step 2 of stuff that starts with “To set an RTCSessionDescription description “
> 
> The algorithm in 4.3.1 is 6 pages long. We need a way to references the steps in it. One way to do this would make all the numbers increment for the whole section and sub lists be like 3.4.5 so I could refer to step 3.4.5. I don’t care how we do it but really hard for implementers to even put in comments that link the code with appropriate part of spec when writing this way. 
> 
> 
> Let say offer/answer done with ufrag1 and PC is in stable state. Now a reoffer is done a new ufrag2. ICE start gathering candidates and PC is not in stable state. The currentLocalDescription returns SDP with ufrag1 while pendingLocalDescription returns SDP with ufrag2. Any new ICE candidates that are being gathered should be added to pendingLocalDescription but stuff with ufrag2 should not be added to SDP with ufrag1 in the currentLocalDescription. Think the spec has this wrong. An interesting case to consider is in the case where ufrag2 did not change and was ufrag1, then seems like it should be added to bother. 
> 
> 
> What is a "trusted origins”. This note needs to be updated 
> 
> The note about defaultIceServers privacy needs to be updated to say that if the user thinks a proxy has been configured but it is not used, that causes significant privacy problems because there IP address gets revealed when they expected the proxy to hide it. A browser sometime using a discovered proxy for and sometimes not or chasing this behavior between version will cause loss privacy in some cases. 
> 
> A single error for all the intros that can go wrong in generating a identity assertions is not enough. Need to be able to separate all they different types of errors. 
> 
> Need ways to report errors of checking identity assertions
> 
> Need way to report what went wrong in SDP when caressing error on a set local/remote 
> 
> In the WebIDL interface for RTPeerConnection for backwards compatable, addIceCandidate is not linked to a definition
> 
> WebRTC says The following values must be supported by a user agent: { name: "RSASSA-PKCS1-v1_5", modulusLength: 2048, publicExponent: new Uint8Array([1, 0, 1]), hash: "SHA-256" }, and { name: "ECDSA", namedCurve: "P-256" }.
> - does this match the other webertc specs ?
> 
> - Do we need to be able to do something smaller to support phones, embedded devices etc. DataCahhenl with IoT Device.
> 
> - Do we ned to control what is in SNI and Certname of DTLS connections
> 
> **** Moving into section 5 **********
> 
> 
> The “the CollectSenders algorithm “ (and similar algorithms” are gratuitous and don’t help implementations. They make the spec harder to comprehend. Lets remove stuff like this that just provides useless detail on how to implement the obvious.  
> 
> - what happens to labels like left, right etc getting into the SDP ….
> 
> - think it is critical to solve the early media problem for th use case were an PR answer with data channel only was received, then media starting arriving for audio and video. So pranswer will have ice info, fingerprint etc.  This would only work for apps that expected early media and did things like carte MST for audio and video to process the early media. 
> 
>  - like time to present in meeting stuff that “Issue #2 in draft”
> 
> *** into section 5.2
> 
> Many applications need to be able to scale video to a particular size, not scale it by a factor. This will become increasing true with dynamically scaled video sizes. The proposed solution in the WG that you can read the size with stats, and then apply a scale factor should be documented here along with a MTI way to get the size that the scale will be applied to. 
> 
> How does ddx interface with iceActivityDetection policy
> 
> Right now RTX and FEC are identified by SSRC. I think it would also be good to be able to get the rid for them (if it exists) 
> 
> Seems like the stuff in RTCRtpCodecParameters should be read only 
> 
> How do we end up with Transceiver with a null mid ?
> 
> What error do I get if the fingerprint of a DTLS connection does not match 
> 
> In section 6.1 
> 
> In data channel, a type error is not what I really expect if a string is the right type but too long. Having multiple different types of mistakes all  generate the same error sounds really bad. Could we actually get the API to report what went wrong 
> 
> Do any browsers implement “The browser may increase the duration and interToneGap times to cause the times that DTMF start and stop to align with the boundaries of RTP packets but it must not increase either of them by more than the duration of a single RTP audio packet.”  ? Any interopabiliyt results with equipment that does not do that ?
> 
> In 8.1 - when doing simulcast, do we need per encoding selectors ?
> 
> Section 8.4 is not specified enough to implement - it is not clear what derived dictionaries. An example would help here. 
> 
> The whole of section 8 needs significant updating before it is ready for review. Someone reading this should be able to figure out what a JS program can query. It is not clear how cross linked things works like how a the feb RTP might get associated with the RTP it provides fec for. To be clear, I’m not saying any of our stats design is wrong - it might be fine - but it’s not documented enough here that an implementor could know how to use it and also not enough to review it. 
> 
> We need to know what are the MTI stats in WebRTC 1.0 
> 
> Not clear how stats are extended or how vendors define non standardized stats. 
> 
> 
> Section 9 
> 
> When I implemented this before I sent a bunch of comments which are in varies stages of getting incorporated. I think once those are resolved we need to review this section carefully from point of view of it we can receive adequate errors about failures. 
> 
> I think the draft need to provide a SHOULD level guideline of when to time out an IdP. This gives browsers advice on what to implement and provides IdP a target of what they need to meet. Without standardization of this, it’s a crap shoot for both the IdP and Browsers. 
> 
> 
> I did not review the examples because I don’t think we are quite at stage yet. 
> 
> The RTCRtpSender and RTCRtpReceiver objects were initially described by Mathew Kaufman well before ORTC. 
> 
> 
> How get errors like “can’t connected to turn server” , “bad credentials” , “TLS failed” 
> 
> What happens if cert expires mid call ?
> 
> With bad SDP, how figure out what part of it is bad 
>

Received on Tuesday, 4 October 2016 13:20:22 UTC