Chrome M33 WebRTC release notes.

[Vikas Marwaha]

Hi,

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

Features:-

• Issue 2482 :- Added support for SCTP on Chrome for Android.

• Issue 2338 :- Added success/ failure callbacks to addIceCandidate API to make the API compliant with the spec. Currently on failure callback, a generic error is thrown.

• Issue 2219 :- Implemented stats report for IceCandidate. Added googTransportType, googLocalCandidateType and googRemoteCandidateType to ICE candidate stats.

• Issue 324464 :- Added support for device enumeration on Chrome for Android using getSources API. Currently Bluetooth is not supported.  

• Issue 307027 :-  Chrome on Android now remembers user's permissions for allow/deny camera and microphone access when served over https. This is now in sync with the behavior on desktops.  

• Issue 325153 :- In Chrome M33, GetUserMedia will fail if you pass sourceId as Mandatory constraint. You can only specify it as optional constraint.

• Issue 325692 :-  Added support for GetUserMedia with a list of sourceID's as optional constraints. Now you should be able to specify multiple optional sourceID's to GetUserMedia api and Chrome will pick the first valid source.

• Hardware AEC support in Nexus 7.2 and Nexus 5.  

Bug Fixes:-

• Issue 2647 :-  Failure to connect using TURN server when using URL in configuration has been fixed.

• Issue 2739 :- Fixed a memory leak in SCTP data channels.

• Issue 2475 :- Fixed failure in creating SCTP data channel when using same label. Now it should be possible to use same labels when creating SCTP data channels.

• Issue 2779 :-  Fixed bug on Mac, related to incorrect cursor position when screen sharing.

• Issue 313192 :- Fixed a bug, when calling GetUserMedia with optional sourceId constraint was not showing the sources the first time, but subsequent call to getUserMedia with the same constraint was working.

• Issue 336171 :- Fixed an issue related to getting AEC recordings from Chrome  to diagnose echo issues. You can get AEC recording by running chrome with --enable-webrtc-aec-recordings command line flag. 

• Issue 269139 :- Fixed an issue related to sourceId changing between sessions of the same application. According to spec, the sourceId which is the application-unique identifier for the source, must be valid between sessions of the application.

• Issue 315585 :- Unplugging a USB device, was stopping the mediaStream rather than the mediaStreamTrack from that  USB device. This has been fixed.

• Issue 328021 :- Audio was failing to play, if the video track was disabled before attaching to HTML video tag. This has been fixed.

• Issue 326566 :-  Fixed a regression bug, related to unable to transmit more than one separate video streams over a single peerconnection. The first one was rendering fine, but the second showed black on the video tag. This has been fixed.
  

Chrome://webrtc-internals :- 

• Issue 244648 :- Improvement in page layout for webrtc-internals. Now we put each PeerConnection on a tab in webrtc-internals. Also collapsed the stats table by default to avoid spamming page with uninteresting stats.

/Vikas

[SProgrammer]

Thank you. This is so CUTE and Lovely release.

Reg

Shamun

[PhistucK]

Thank you very much for all of this.

Regarding -

• Issue 2219 :- Implemented stats report for IceCandidate. Added googTransportType, googLocalCandidateType and googRemoteCandidateType to ICE candidate stats.

Justin wrote in November -

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

What happened to that?

If you really need this for debugging for now, perhaps add a command line flag that would enable these (non prefixed) properties rather than enabling them by default until they are standardized?

☆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/d/optout.

[Philipp Hancke]

I was expecting a fixed data channel bug where duplicate onmessage event were sent on the wrong channels (i.e. I sent a message on channel A while another channel B was open and it was received on both A and B)... 

does this sound familar? I can still repro that in chromium M32.

Thanks for doing this, I usually find at least one or two bugs I missed

[Harald Alvestrand]

If you have not already, can you file a bug with a repro?

--

[Justin Uberti]

On Fri, Mar 14, 2014 at 1:45 AM, PhistucK <phis...@gmail.com> wrote:

Thank you very much for all of this.

Regarding -

• Issue 2219 :- Implemented stats report for IceCandidate. Added googTransportType, googLocalCandidateType and googRemoteCandidateType to ICE candidate stats.

Justin wrote in November -

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

What happened to that?

If you really need this for debugging for now, perhaps add a command line flag that would enable these (non prefixed) properties rather than enabling them by default until they are standardized?

These stats were added prior to this discussion. I will check as to whether they can be replaced with a non-prefixed property now. 

[Raju]

Hi Vikas,

Is there a url where we can get this webrtc specific feature/fix info for every release? 

Thanks

Raju

[Vikas]

Hi,

Thanks, currently all the release notes are being posted on the discuss list. 

/Vikas

[Justin Kahn]

Hi,

Is anyone having issues using Chrome to Chrome to connect a WebRTC call?  I am able to run successful calls between chrome to firefox and firefox to firefox with no issues. However, once I go Chrome to Chrome the video freezes while the audio remains.  Please let me know any thoughts you may have.

Thanks!

Justin

[Vikas]

Hi,

Are you able to recreate this with apprtc demo? 

/Vikas

[Justin Kahn]

Hi Vikas,

When I use apprtc, everything is working fine. However, when using Opentok for the call, that is where I am running into the issue. I have run the opentok diagnostics and searched the web to see if they or google was having an issue, but I have not been able to find anything. Any suggestions?

Thanks!

Justin Kahn
CEO
TruClnic, LLC
877.340.0410 (toll free)
801.610.1895 ext. 301 (office)
801.755.9300 (mobile)
801.326.4775 (fax)
jk...@truclinic.com

www.TruClinic.com

Privacy Statement: The information contained in this email message is intended only for the personal and confidential use of the designated recipients named above. This message may be a privileged communication, and as such is privileged and confidential. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you have received this document in error, and any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please immediately notify our System Administrator at TruClinic LLC.

--

---
You received this message because you are subscribed to a topic in the Google Groups "discuss-webrtc" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/discuss-webrtc/lAn7IvSIQ_g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to discuss-webrt...@googlegroups.com.

[Vikas]

Hi,

You can also take a look at the graphs in Chrome://webrtc-internals to see if that gives any insight to the problem see if video packets are actually being received, is there packet loss, etc.

Thanks,

Vikas

[Nicholas Buchanan]

Nexus 7 2nd Gen running Kit Kat 4.4.2 tested - the video element does not display the webcam stream correctly. The stream is not fit into the element but rather portrays in a full screen mode inside the video element. This does not reproduce on my Droid Mini Kit Kat 4.4.0 M33.

Is this a Kit Kat 4.4.2 + M33 issue? I tested Chrome beta on Nexus 7 and this does not reproduce.

[Wei Jia]

This could be fixed by https://src.chromium.org/viewvc/chrome?view=rev&revision=240955 which is in M34 (current beta).

Wei

On Sun, Mar 30, 2014 at 10:06 PM, Nicholas Buchanan <omnipot...@gmail.com> wrote:

Nexus 7 2nd Gen running Kit Kat 4.4.2 tested - the video element does not display the webcam stream correctly. The stream is not fit into the element but rather portrays in a full screen mode inside the video element. This does not reproduce on my Droid Mini Kit Kat 4.4.0 M33.

Is this a Kit Kat 4.4.2 + M33 issue? I tested Chrome beta on Nexus 7 and this does not reproduce.

--

---

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.

[subhendu das]

Hi,

  I need one information. Is DTLS-SRTP is by default enabled in the latest chrome versions for webrtc calls. Do we still have any means to disbale and use only SRTP.

/Subhendu

[Dennis]

Subhendu I think what you're trying to do is this:

var pc = new RTCPeerConnection(iceservers, { 'mandatory': {'DtlsSrtpKeyAgreement': 'false'}});

by setting DTLS to false on creation of the PC, that re-enables SDES-SRTP.

[Vikas]

Hi,

Please refer to issue 2774. Now SDES is disabled in Chrome and DTLS is by default enabled. If DTLS is disabled through the DtlsSrtpKeyAgreement:false constraint, SDES will be enabled as before.

/Vikas