Re: [webrtc-pc] Review issues reported to last in September

Responding to most items in https://lists.w3.org/Archives/Public/public-webrtc/2016Sep/0071.html below:

>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.

RTCIceCredentialType uses has members "password" and "oauth", for the later we talk about "accessToken" - solved.

>
>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.

4.3.1, step 3 says "If configuration.rtcpMuxPolicy is negotiate, and the user agent does not implement non-muxed RTCP, throw a NotSupportedError." - solved.

>
>Make it clear that when voiceActivityDetection is false, that browser must send media even if it silent 

Opened https://github.com/w3c/webrtc-pc/issues/1308, could you supply a PR proposing text?

>
>What does “cannot be applied at the media layer” mean 

https://github.com/w3c/webrtc-pc/issues/1307 opened.

>
>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 “

Opened https://github.com/w3c/webrtc-pc/issues/1309

>
>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. 

Opnened https://github.com/w3c/webrtc-pc/issues/1310

>
>
>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.

Opened https://github.com/w3c/webrtc-pc/issues/1311

>
>
>What is a "trusted origins”. This note needs to be updated 

Opened https://github.com/w3c/webrtc-pc/issues/1312

>
>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. 

Opened https://github.com/w3c/webrtc-pc/issues/1313

>
>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. 

Opened https://github.com/w3c/webrtc-pc/issues/1314 and assigned to you. Can you do a PR?

>
>Need ways to report errors of checking identity assertions

Opened https://github.com/w3c/webrtc-pc/issues/1314 and assigned to you. Can you do a PR?


>
>Need way to report what went wrong in SDP when caressing error on a set local/remote 

I don't completely follow. Can you expand?

>
>In the WebIDL interface for RTPeerConnection for backwards compatable, addIceCandidate is not linked to a definition

Seems to be in the current version.

>
>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 ?

Opened https://github.com/w3c/webrtc-pc/issues/1315

>
>- Do we need to be able to do something smaller to support phones, embedded devices etc. DataCahhenl with IoT Device.

--

>
>- 

Opened https://github.com/w3c/webrtc-pc/issues/1316

>
>**** 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.

Seems editorial. Do you want to propose something?

>
>- 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. 

This has been discussed a lot in MMUSIC and I understand the current view is that this can't happen.

>
> - 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. 

Seems editorial. Will you propose something?

>
>How does ddx interface with iceActivityDetection policy

ddx??

>
>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)

I think this is in the spec now.

>
>Seems like the stuff in RTCRtpCodecParameters should be read only 

Much of this has been updated, clearly saying which ones are read-only.

>
>How do we end up with Transceiver with a null mid ?

I guess if one is created but no SDPs have been exchanged?

>
>What error do I get if the fingerprint of a DTLS connection does not match 

fingerprintfailure ? Related to https://github.com/w3c/webrtc-pc/issues/1092?

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

Opened https://github.com/w3c/webrtc-pc/issues/1317

>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 ?

Do we need to pursue this?

>
>In 8.1 - when doing simulcast, do we need per encoding selectors ?

Stats related, has undergone a lot of changes. Still relevant?

>
>Section 8.4 is not specified enough to implement - it is not clear what derived dictionaries. An example would help here. 

Can you propose text?

>
>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. 

Can you propose something?

>
>We need to know what are the MTI stats in WebRTC 1.0 

Stats related, has undergone a lot of changes. Still relevant?

>
>Not clear how stats are extended or how vendors define non standardized stats. 

Seems process related more than spec related.

>
>
>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. 

Opened https://github.com/w3c/webrtc-pc/issues/1319

>
>
>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 is the status of these now? I think we have updated errors a bit.

>
>What happens if cert expires mid call ?

Opened https://github.com/w3c/webrtc-pc/issues/1318

>
>With bad SDP, how figure out what part of it is bad 

We did add line number, no?


-- 
GitHub Notification of comment by stefhak
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1269#issuecomment-305468506 using your GitHub account

Received on Thursday, 1 June 2017 11:38:57 UTC