Action Items from ORTC CG Meeting #8 - May 13

>From Minutes:

[10:32] <emcho> signalling end-of-candidates throuth the API
[10:32] <emcho> TAKE AWAY / ACTION: investigate whether we need some kind
of value in the empty dictionary that signals end-of-candidates

*RTCIceCandidateComplete dictionary*
https://github.com/openpeer/ortc/issues/207

[10:33] <emcho> juberti: sample code would make things clearer
[10:33] <emcho> ACTION: file an issue on this

Added to #207 ^^

[10:34] <emcho> calling gatherer.close() woujld close the port though
[10:35] <emcho> as for DTLS: closing that would also close the ICE transport
[10:35] <emcho> but the implications are not clear
[10:36] <emcho> ACTION: open an issue on this (although we might already
have one)

*RTCIceGatherer.close affect on RTCIceTransport / RTCDtlsTransport*
https://github.com/openpeer/ortc/issues/208

[10:44] <emcho> pthatcher: for audio, does this mean clipping?
[10:45] <emcho> juberti: yes
[10:45] <emcho> juberti: again, shouldn’t affect the vast majority of
users
[10:46] <emcho> robin: especially fine for telephony
[10:46] <emcho> robin: this should also play into 170
[10:47] <emcho> TAKE AWAY: we should (at least for now) have a very clear
security policy where the stack only bubbles up to the application
whatever’s been verified. this means buffering stuff only so that we the
decoder can be in the rights state. this means we are basically throwing
away audio but keeping video

Comments added to #200
*Incoming media prior to Remote Fingerprint Verification*
https://github.com/openpeer/ortc/issues/200


[11:16] <emcho> robin: basically you are proposing a factory method?
[11:16] <emcho> pthatcher: yes
[11:17] <emcho> roman: does this really exist?
[11:17] <emcho> pthatcher: yes
[11:17] <emcho> because signalling and connchecks are in different threads
in chrome
[11:17] <emcho> robin: i’d also have the issue in my impl
[11:19] <emcho> CONSENSUS CALL: does everybody like Method 1 but with the
presumption that we can solve the forking problem. we are still taking this
to the list to confirm and look  for other solutions
[11:20] <emcho> roman: we need the full solution before we pick a direction
[11:20] <emcho> pether: ACTION I’ll send a fuller proposal to the list

Comments added to #170, Peter to send fuller proposal to list
*Response to connectivity checks prior to calling iceTransport.start()?*
https://github.com/openpeer/ortc/issues/170#issuecomment-105629219

[11:26] <emcho> CONSENSUS for createAssociatedGatherer() and generally
making it easier for the RTCP-MUX
[11:27] <robinraymond> remove from transport if possible

Original #188 - Priority Calculation, new bug #209
*Trying to remove RTCIceTransport.createAssociatedTransport(component)*
https://github.com/openpeer/ortc/issues/209

[11:29] <emcho> ACTION: emil will ask Philipp Hancke to convert his
comments into something that everyone can read (not only adobe acrobat
reader users)

*Philipp Hancke's Review Comments*
https://github.com/openpeer/ortc/issues/198
*Comments added: We will not be able to accept these proposed changes until
Philipp joins the CG and agrees to the CLA.*

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> | *Hookflash
<http://hookflash.com/>* | 1 (855) Hookflash ext. 2 | Twitter
<http://twitter.com/elagerway> | WebRTC.is Blog <http://webrtc.is/> *