Chrome WebRTC M31 Release Notes.

[Vikas Marwaha]

Hi,

Please find below WebRTC Release Notes for Chrome M31. Below is the list of major changes:

Features:-

• Issue 383 :- Added support for relaying a remote video track to another peer. Relaying a remote audio track is still being worked on see issue 2192.
  
• Issue 2245 :- Added support for SCTP data channels in Chrome, without a flag.
• Issue 1488 :- Device Enumeration API for chrome on Android now available. The device enumeration only applies to video currently.
  
• Issue 1526 :- Implemented ICE stats in getStats. Added bytesSent, bytesReceived, googWritable, googReadable, googActiveConnection, googLocalAddress & googRemoteAddress fields in the candidatePair. 
• Issue 1862 :- DTLS-SRTP is now enabled by default.
  
• Issue 1688 :- Added support for a=setup attribute for DTLS-SRTP. 
• Issue 237907 :- Implemented windows picker dialog for screen sharing, currently supported with chrome.desktopCapture extensions API. This API is only available on dev channel now, but will be promoted to stable in a future release.
• Issue 274623 :- Implemented key stroke detection in chrome.
• Issue 277162 :- Added chrome flag to auto allow getUserMedia without prompting. This is useful for JS developers whose test environment is http instead of https.
• Issue 285967 :- Mac Video capture format change ARGB->YUY2 to improve performance.
• Issue 247027 :- Support multiple sources for media stream AudioTrack.

Bug fixes :-

Issue 2236 :- SCTP OPEN message not sent when Data channel's readyState becomes 'open'.
Issue 2279 :- SCTP interop between FF and Chrome.
Issue 2270 :- Sending binary data fails when using SCTP.
Issue 2407 :- SCTP doesn't respect SCTP port number specified in remote sdp.
Issue 2119 :- Performance issues identified in M27->M28. 
Issue 256512 :- Properly handle getUserMedia() requests from app's.

Announcement:

• The getUserMedia error 'PERMISSION_DENIED' is renamed to 'PermissionDeniedError' as the spec has been updated.

/Vikas

[PhistucK]

Thank you for the notes!

Is this (below) essentially considered a prefixed implementation ("googReadable")?​

On Sat, Nov 16, 2013 at 3:39 AM, Vikas Marwaha <vikasm...@google.com> wrote:

Implemented ICE stats in getStats. Added bytesSent, bytesReceived, googWritable, googReadable, googActiveConnection, googLocalAddress & googRemoteAddress fields in the candidatePair. 

☆PhistucK

[Eric Davies]

With regards to the bug fix for Issue 2279 (SCTP Interop), what code are you using to test/verify this works now?

Thank you.

Eric.

[Vikas]

@Eric, at the moment we don't have a public code/demo to test SCTP interop. If you want to try, you can probably add data channel code to apprtc and test it locally between Chrome & FF. 

@Phistuck, the goog prefix means the parameters not standardized yet, is that what you wanted to know?

[PhistucK]

Yes.

Blink has a no prefix policy. Why does WebRTC introduce new prefixed implementations to the platform (instead of implementing them behind a command line flag)?

☆PhistucK

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Vikas]

it's not a blink change, also there have been prefixed stats before as well. 

[PhistucK]

I know it is not, but this is being exposed to the platform and developers now rely on non standard features.

Having prefixed implementations before does not justify adding new ones (or even adding those in the first place).

Just wanted to start a discussion about this in blink-dev.

☆PhistucK

[SProgrammer]

Will this release allow us to do the following, was there any special improvement in networking packets exchange? so that if the user is in Enterprise networks or behind firewall still it must work? (whereas like Skype, Adobe Flash web cams chatting sites always works in any networks)

if still we have networking / behind firewall problems, is there still any improvement on this following method to break NAT/firewall issues and let webRTC/appRTC work like better then Skype/Adobe Flash web cam chatting sites

- Embedded VPN Client 

    via Javascript initialize VPN client session to VPN server? 

    When connection to VPN server is established, we get a VPN dhcp IP, as a result we are having no NAT problem at all (which we have day n night with ICE, Stun, Turn, NAT Traversal methods and not robust in many random network topology )

[Justin Uberti]

Fair point. Our rationale has been that it is better to give app developers as much debugging info as possible, but use prefixes to indicate that some parts are not yet standardized. We are discussing with the Blink team though to make sure we are aligned.

[Justin Uberti]

Agreed. Going forward we plan to adopt the Blink policy for any new stats and clean up the remaining googisms.

On Thu, Nov 21, 2013 at 8:40 PM, Elliott Sprehn <esp...@chromium.org> wrote:

This doesn't feel different than adding an extra object to requestAnimationFrame's callback that returns lots of "goog" prefixed values like googLastFrameTime and googTimeRemainingUntilNextFrame. That would be very useful to developers, but we'd still not allow it without a flag and a spec (at least I hope not). I hope we don't add any more goog prefixed things and I also hope that "this is not a blink change" is never accepted as an excuse for adding prefixes to JS APIs. Otherwise we can just move half our stuff up out of blink and start prefixing whenever we want defeating the policy. :(