weird behavior for TURN over TCP in WebRTC sessions
Reported by
tsa...@testrtc.com,
Sep 14 2016
|
||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.101 Safari/537.36 Steps to reproduce the problem: 1. Run AppRTC 2. Force TURN over TCP 3. Look at the resulting graphs What is the expected behavior? bitrate should ramp up faster on the incoming and have no packet losses You can read more on how I got there here: http://testrtc.com/happens-webrtc-shifts-turn-tcp/ (Item 2 in the list of scenarios). If needed, can be easily reproduced over the testRTC service - just ask... What went wrong? The graph is all wrong... Did this work before? N/A Chrome version: 52.0.2743.116 Channel: stable OS Version: Ubuntu 16.04 Flash Version: Shockwave Flash 22.0 r0 Here's what Fippo thought about it: I have a slightly different theory about the difference between send and recv. - import this in http://fippo.github.io/webrtc-dump-importer/ - look at the graph bweforvideo (connection 437-1) - we can see that the BWE for outgoing (green) is ~300kbps until 9 seconds into the session (not sure why signaling takes that long?!). That is the stock estimate if no rtcp is received. - the sender starts ramping up - the receiver BWE (black) is not existing until 15 seconds. Then it starts ramping up slowly. - the receiver bandwidth follows that BWE. I bet google is doing very aggressive ramp-up only in the first few seconds and this misses the window for that. And yes, I double checked that both legs are using turn/tcp ;-) Tsahi: I'd really file a bug, especially if you can say "here is how to repro it on our test infra". What is also odd is that GUM requests 720p but gets 1080p in getStats... might be an issue with fake device
,
Sep 14 2016
probably most relevant for stefan@webrtc.org but I think hta@ will want to be cc'ed at least.
,
Sep 14 2016
btw: while this shows a significant difference between send and receive I do not see the ramp-up in five seconds that tsahi's graphs show. I suspect that his second theory from the blog post is true and the TURN server affects the behaviour here. If the TURN server drops RTCP would that explain the five second delay in the receiver bitrate estimate?
,
Sep 14 2016
,
Sep 15 2016
,
Sep 15 2016
ignore the theory in #3 -- the screen shot was off, the behaviour is symmetric in both dumps attached. One less variable. So now we just have the question why the receiver estimate is delayed that much.
,
Mar 13 2018
|
||||
►
Sign in to add a comment |
||||
Comment 1 by fi...@appear.in
, Sep 14 201682.6 KB
82.6 KB View Download