Subject: Re: [rtcweb] JS app interaction with congestion control

From: Randell Jesup <[email-masked]>
Date: Wed, 01 Feb 2012 09:02:09 -0800

This really is almost all W3c stuff; cc'ing that list where most 
discussion should occur.

Updated suggestion based on Justin's comments:  (largely for W3C 
discussion)

This is rough, and a first cut, but we need to start somewhere.

I propose we add a callback on PeerConnection and some attributes on it
and MediaTracks:

{
...
     // allow app to limit total bitrate used for the PeerConnection
     attribute unsigned long maxBitrate;
     attribute readonly unsigned long currentBitrate;  // [Open issue] - 
how much smoothing?

     attribute Function? onBitrateChange;
     // don't notify until change since last notify is more than this
     attribute unsigned long minBitrateChangeToNotify;
     attribute Function? onResolutionChange;  // not strictly needed

     // These are global settings that can be overridden on a per-track 
basis
     attribute float minFramerate;
     attribute float maxFramerate; // might not be needed
     attribute boolean preferMotion;  // false means preference for 
Resolution
}

To each MediaTrack:

{
...
     // If the app bumps up the currentBitrate of one track and doesn't 
lower another track, the
     // system will make cuts to keep the total bitrate within bounds.
     attribute unsigned long currentBitrate;
     attribute short priority;  // for allocating bits

     // The rest of these are for video (is short guaranteed enough, 
always?  Probably)
     attribute unsigned short width;  // Let app override the values 
chosen automatically
     attribute unsigned short height;
     attribute float framerate;
     attribute float minFramerate;
     attribute float maxFramerate; // might not be needed
     attribute boolean preferMotion;  // false means preference for 
Resolution

     // typically derived from QP
     attribute readonly unsigned short videoQuality;
     // audioQuality?? (samplerate?)

}

Should some of these be echoed in MediaTrackLists or MediaStreams?

-- 
Randell Jesup
[email-masked]

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 13 Feb 2012 08:10:02 -0700

There are really a lot of things that are along the lines of of providing JS control of echo cancellation, bandwidth etc. I'd like to figure out an bit of extensible framework for adding these types of things. It might be that in the end we end up with exactly this but we have been talking about some other ways of doing it to - I think Dan is going to send a proposal to the list at some point. 

On Feb 1, 2012, at 10:02 AM, Randell Jesup wrote:

> This really is almost all W3c stuff; cc'ing that list where most discussion should occur.
> 
> Updated suggestion based on Justin's comments:  (largely for W3C discussion) 
> 
>     attribute readonly unsigned long currentBitrate;  // [Open issue] - how much smoothing? 
> 
>     // These are global settings that can be overridden on a per-track basis 
>     attribute boolean preferMotion;  // false means preference for Resolution 
> } 
> 
> 
> To each MediaTrack: 
> 
> { 
> ... 
>     // If the app bumps up the currentBitrate of one track and doesn't lower another track, the 
>     // The rest of these are for video (is short guaranteed enough, always?  Probably) 
>     attribute unsigned short width;  // Let app override the values chosen automatically 
>     attribute boolean preferMotion;  // false means preference for Resolution 
>

---

From: "Suhas Nandakumar (snandaku)" <[email-masked]>
Date: Mon, 13 Feb 2012 14:00:49 -0600

I was wondering why should we link ICE candidate gathering procedures to
call setup flow. 
Can't this be done by browser periodically independent of RTCWeb call ?

This may end up saving ton of time if the network topology doesn't
change frequently.

Is this a valid argument ?

Cheers
Suhas

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Feb 2012 10:23:02 +0100

> Is this a valid argument ?
the chief problem with that thought is that with current APIs, the 
browser does not know which STUN/TURN server to use before the 
PeerConnection is created (it's an init parameter).

If we want this separation, we would have to create some object 
(PeerConnectionFactory?) that would take the STUN/TURN server name as 
parameters, gather the candidates and generate a PeerConnection object 
with these candidates when required.

This may be a Good Thing for other reasons (the rehydration case - 
reestablishing a connection when the user does "reload"), but does 
complicate the simple case.

              Harald

---

From: Justin Uberti <[email-masked]>
Date: Tue, 14 Feb 2012 08:51:00 -0500

On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand <[email-masked]>wrote:

> the chief problem with that thought is that with current APIs, the browser
> does not know which STUN/TURN server to use before the PeerConnection is
> created (it's an init parameter).
>
> parameters, gather the candidates and generate a PeerConnection object with
> these candidates when required.
>
One issue with this is that a single preallocator can't do the right thing
if you want to have multiple PeerConnections, or multiple unbundled m=
lines.

As an alternative, you could simply create a PeerConnection, call startIce
to gather candidates (pre-call), and only getUserMedia/send the offer when
you are ready to place the call.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 14 Feb 2012 15:07:37 +0100

On 02/14/2012 02:51 PM, Justin Uberti wrote:
>
>
> On Tue, Feb 14, 2012 at 4:23 AM, Harald Alvestrand 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     (PeerConnectionFactory?) that would take the STUN/TURN server name
>     as parameters, gather the candidates and generate a PeerConnection
>     object with these candidates when required.
>
> One issue with this is that a single preallocator can't do the right 
> thing if you want to have multiple PeerConnections, or multiple 
> unbundled m= lines.
If multiple local ports are needed (and the code seems to be simplest if 
they are): yes, we need to allocate more than one port. That doesn't 
mean that a preallocator can't do it, just that it needs to know how 
many are needed.

>
> As an alternative, you could simply create a PeerConnection, call 
> startIce to gather candidates (pre-call), and only getUserMedia/send 
> the offer when you are ready to place the call.

Which made me realize that this isn't clear from the current drafts: If I do

pc = new PeerConnection()
pc.startIce()
<wait 3 seconds>
pc.CreateOffer()

will the created offer contain the candidates that have been generated?

If it does, it seems to me that people who don't need/can't use trickle 
candidates don't need to handle the ICE machinery at all.

                     Harald

---

From: Justin Uberti <[email-masked]>
Date: Tue, 14 Feb 2012 09:21:50 -0500

On Tue, Feb 14, 2012 at 9:07 AM, Harald Alvestrand <[email-masked]>wrote:

> **
> they are): yes, we need to allocate more than one port. That doesn't mean
> that a preallocator can't do it, just that it needs to know how many are
> needed.
>

You are correct. I should have said that it is harder for the preallocator
to know what to do (i.e. we would need more API for it).

> startIce to gather candidates (pre-call), and only getUserMedia/send the
> offer when you are ready to place the call.
>
>

Yes. If you use the IceCallback, you can be notified when all the
candidates are ready, instead of using a timeout. But a timeout would work
too.

> candidates don't need to handle the ICE machinery at all.

Exactly. I tried to indicate that in section 4.5 of the -01 draft.