W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > October 2019

Re: [webrtc-pc] Add adaptivePtime to RTCConfiguration (#2309)

From: Elad Alon via GitHub <sysbot+gh@w3.org>
Date: Tue, 01 Oct 2019 10:51:19 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-536981440-1569927077-sysbot+gh@w3.org>
> What exactly did you test?

We are aware of the difficulties of testing this properly. A colleague of mine tested the happy-case, but a stressed version of it. The frame length was changed every 3s, cycling some select values between 20ms and 120ms (therefore "stressed"). Network conditions were kept constant, and favorable, throughout the test (therefore "happy-case"). We are aware that this is only a partial test. That's why we're not turning it on by default on Chrome, but rather leaving it up to the web-app. And the web-app is welcome to negotiate this capability on its own, using whatever method it chooses.

Repeat - one can negotiate this OOB if one is concerned about interoperability.

> Are you actually planning to update frame length 50 times per second?

I do not need to update 50 times per-second. What I want is to minimize response time. If you poll every second, you can have a delay of up to 1s from conditions changing, and your response to them. If you poll 50 times per second - which the UA easily can, but the web-app shouldn't - your max response time drops to 20ms. That's important for our usecase.

> First of all, most web application are quite useless at 60kbps.

I'm here to fix that. *micdrop*

Kidding aside, though (hope it will be taken in good spirit), this feature can save ~20kbps of overhead. If you're concerned about web-apps underperforming at lower bitrates, you're my target audience for this feature. I understand that you would be better served by a negotiated feature, but that would mean the feature is served to you later, or not at all (because I'd be forced to pick other, lower-hanging fruit, this season). Please negotiate this OOB if necessary.

> Second, using 120 ms frame results in very high delay making communication feel more like broadcast then actual interactive conversation.

We think our customers would prefer that over a dropped call. That's why we'll experiment with this feature. Others may either avoid this feature, or limit adaptation to something like 60ms using maxptime.

> P.S. I have some experience building and operating a VoIP application that was designed to work under low bitrate under adverse network conditions.

Thank you for sharing your experience. Your feedback is valued. Truly.

> All we needed to do, in addition to codec bitrate adaption, was to change ptime using regular offer/answer between 20/30/40/60 ms roughly 1-2 seconds after major network change was detected. This network change often corresponded to IP address change for the client, so offer/answer came naturally.

1. What about changes due to side-traffic? These can appear without a network change. They can persist for several seconds/minutes, then disappear as unexpectedly as they had come. This can happen frequently, too; perhaps more so than network changes.
2. I am curious about your solution - how it chose how long after a network change to set a new ptime, how it chose to change the ptime when the bandwidth estimation stabilized, etc. But this is probably not the right place to discuss this. Maybe face-to-face one day, or by email.

> I think @rshpount makes a good argument for possibly keeping ptime. If we end up supporting ptime I think we'd just need to say that if ptime is set than the UA is now allowed to use any other value. Don't think it's a blocker here.


> With regards to how or when the ptime dynamically changes, since we want the UA to be able to decide, my current suggestion is to not restrict how it changes, i.e. it's entirely up to the UA on each packet what length to use, as long as it is within valid values.

We're on the same page here.

GitHub Notification of comment by eladalon1983
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/pull/2309#issuecomment-536981440 using your GitHub account
Received on Tuesday, 1 October 2019 10:51:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:22:29 UTC