Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Philipp Hancke's Review Comments #198
Review comments from Philipp Hancke are available here:
changed the title from
Phillip Hancke's Review Comments
Phillipp Hancke's Review Comments
May 11, 2015
Repeating the comments out here, number + page (in the pdf) + section followed by quote and comment.
RTCPeerConnection does not mandate a media signaling protocol or format either. This text is just going to offend certain people.
Sending datachannels sounds odd.
No, see comment on page 1
i'd suggest moving it either after the next paragraph or after the picture. Here I have no idea why those objects are defined.
a high level description of the relationship between the objects would be helpful before this.
does it expose the level and description of the alert? (e.g. 'fatal' + handshake failure)
what happens when calling getStats after this? There was some discussion of that case for the PC
SDP can only deal with a single fingerprint (surprise...)
move up to match order of attributes in spec.
the order of sections here is somewhat confusing... first we are doing DTLS, then ICE, then RTP. Whereas on the network, DTLS is run on top of ICE.
either do "ufrag and pwd" or "usernameFragment and password" for consistency
order of attributes doesn't match description here
this is missing my favorite "failed" state from RTCPeerConnection
missing " [after .net --] bug was fixed in webrtc-pc IIRC
ugh... I found it surprising that urls can be a string. But it also can in PC
move down to match order
how does this deal with the extensibility defined in RFC 5245 --
I don't think those attributes are useful, just a potential leak of ip addresses when forcing turn-only relays. So I would not expose them.
is this case-sensitive?
for TURN, this is the srflx candidate this is derived from
see case question above (19). Jingle and SDP and consequently chrome and firefox disagree here
Just make it 
cross-ref would be helpful
this example seems to make some assumptions about the signaling protocol. For Jingle, the callback might be triggered when receiving an which does not imply the session has been accepted, just that the offer has been received.
 is shorter
I have a note here about rewriting these conditions to make them clearer, but can't remember how I wanted them to be more clear.
unnecessary semicolon (jshint nitpick mode)
The indent seems wrong here which makes this confusing. Probably what I had in mind with comment 28.
unnecessary semicolon. There seems to be a closing '}' missing, indent makes it hard to read.
doesn't it concat local and remote separated by a colon? I always forget in which order...
add a note about setting rel-addr to 0.0.0.0 then
I don't see that
move below the definition of mySendLocalCandidate
this seems very odd semantics for a callback...
Outdated ref [actually section 17 now and empty]
http://webrtc.github.io/samples/src/content/peerconnection/dtmf/ has a much nicer example :-)
In order for these changes to be accepted Philipp Hancke will need to join the CG, agree to the CLA and preferably subscribe to the mail list, if he is not already doing so. Erik will email &yet to try and attempt to get this sorted out. Until then, we will have to wait on vetting and integrating these proposed changes.