New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 677543 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Chrome sending both sender report and receiver report when it is an active sender

Reported by ryoz...@gmail.com, Dec 29 2016

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:50.0) Gecko/20100101 Firefox/50.0

Steps to reproduce the problem:
1. Open appr.tc in chrome to create a room
2. Join appr.tc from any other browser
3. Dump packet and event recording

What is the expected behavior?
According to RFC: https://tools.ietf.org/html/rfc3550#section-6.4  Chrome should send reception blocks in sender report since it's a sender.

What went wrong?
Chrome sends receiver report while it's also sending sender report without reception block.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 55.0.2883.95  Channel: n/a
OS Version: OS X 10.11
Flash Version: Shockwave Flash 24.0 r0

Also tested on Chrome 57.0.2960.0 canary, it has the same problem.
 
Components: -Blink>WebRTC Internals>WebRTC
Cc: kkaluri@chromium.org
Labels: TE-NeedsTriageHelp
Labels: -OS-Mac
Removing Mac label.
Components: -Internals>WebRTC Blink>WebRTC>Video
Owner: mflodman@chromium.org
Magnus, is the video team the right team for sender reports?

Comment 5 by tommi@chromium.org, Apr 26 2017

Cc: holmer@chromium.org
Cc: brandtr@chromium.org
holmer@,brandtr@, could one of you help triage/route this issue? It seems like it might be an interop issue. 
Labels: -Pri-2 Pri-3
Owner: danilchap@chromium.org
Status: Assigned (was: Unconfirmed)
Danil, would you like to take a look at this? It's low priority, but it would be nice to get fixed at some point.
Cc: nisse@chromium.org

Sign in to add a comment