Transport Control

From Web Real-Time Communications Working Group Wiki
Jump to: navigation, search

Intro

This really started off with a mail calling for input of attributes in the SDP that should be possible to control without mangling the SDP itself ([1]). The discussion that followed showed that there was a desire to be able to influence some aspects related to transport of media (and some aspects may be present in the SDP - if SDP is maintained - and other's are not in the SDP). This page is an attempt to collect what has be expressed in one place (but naturally further discussion on what should go into 1.0 and what should not is needed).

It should be noted that there were also feedback saying that everything in the SDP must be exposed for reading with most of it being exposed for writing, and that we should not use SDP at all, as well on that looking into this only makes sense once we have agreed (with the IETF) exactly on how SDP should be used in WebRTC. But this page is an idea to collect the input on what should be available to the app (regardless of whether SDP is maintained or not).

Update September 5 2013: Updated based on the discussion at the WebRTC telconf of September 3rd.

The list

In scope for V1

Priority

Requesting different priority for different MediaStreamTrack's (and data channels). Part of requirements in the use-case document.

The main purpose of priority is to pick an appropriate DSCP code point for outgoing packets as specified in draft-ietf-rtcweb-qos (currently expired). This means that priority can be set locally on the sender side only.

It may also serve as guidance for bandwidth allocation when congestion control limits how much can be sent. It remains to be discussed whether we need to specify an algorithm here (strict priority versus weighted round robin, for instance).

Max bitrate

It should be possible to indicate the maximum bitrate to use. Some thought it would be sufficient to do this on PeerConnection level, others think it must be possible to control per MediaStreamTrack.

For version 1, we agree that an overall requested max bitrate per PeerConnection is necessary. There's no consensus on whether a max bitrate per MediaStreamTrack has to be in version 1.

In all cases, max bitrate will never increase the instantaneous bitrate beyond that allowed by the congestion control algorithm in use.

Disable Bundle

Done on PeerConnection level. The use case is to control calls where the network has the ability to prioritize properly traffic on separate ports, but does not have the ability to prioritize properly traffic that shares the port.

Detailed Bundle mangling (such as bundling tracks A and B into one bundle, while tracks C and D go into another bundle) is left for later versions.

Sender side Pause

The spec already contains the ability to disable a stream. Defining "disabled" as silence / blackness allows it to be sent without any need for signalling. This may be sufficient for version 1.

Needs further discussion, maybe for later versions

Pause/resume

It was proposed that it should be possible to pause (and resume) sending of media. Use case was to save transmission and coding capacity when there is temporarily no need to transmit. Currently a MediaStreamTrack can be disabled, which corresponds to silence (audio) and blackness (video). It was argued that this would be sufficient for 1.0 (as silence/blackness compresses well).

Configure codec settings

E.g., select whether AGC (suitable for speech) should be used or not (this was also referred to as a music/speech selector), select low, normal or high delay, enable/disable DTX at speech pauses, etc. This is partly covered in the use case document.

It has also been proposed that it should be possible to influence the browser to create offers where that same codec if offered with different settings (and different PTs).

On some codecs, such as OPUS, almost all configuration can be done on the sender side (no changes will be visible in the SDP). In other cases, and with other codecs, negotiation of extensions or parameters might be necessary.

Select which codec(s) that are offered/used

Minimum and start bitrates

The point was made strongly that "start bitrate" should never allow a bitrate that would be exceeding the bitrate that is considered safe by our congestion control algorithms. "Start bitrate", if it exists at all, is only a hint that the application wishes to ramp up to that bitrate as soon as possible.

Minimum bitrate can be useful as a trigger for an "overconstrained" callback - indicating that the available bitrate for a track has fallen below what the application deems an useful bitrate. The application can then choose to remove or reconfigure the track.

Handling Layered codecs

More advanced handling of Simulcast

(Basic simulcast already possible)

API proposals

One proposal has been made on the list, http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0005.html. It is repeated below, but with the name change proposed in http://lists.w3.org/Archives/Public/public-webrtc/2013Oct/0034.html:

Addition to PeerConnection

partial interface RTCPeerConnection {
       RTCMediaTrackTransmissionController getMediaTrackTransmissionController (MediaStreamTrack track);
};


The getMediaTrackTransmissionController() method creates an RTCMediaTrackTransmissionController object that references the given MediaStreamTrack.
The MediaStreamTrack MUST be an element of a MediaStream that's currently in the RTCPeerConnection object's local streams set; if not, throw an
InvalidMediaStreamTrackError exception and abort these steps.

Parameter	Type			Nullable Optional Description
track		MediaStreamTrack  	✘	 ✘	
Return type: 	RTCMediaTrackTransmissionController

New object

interface RTCMediaTrackTransmissionController {
	readonly attribute MediaStreamTrack track;
};
RTCMediaTrackTransmissionController implements Constrainable;


The initial constraints - and settings and capabilities - to support could be:

  • priority (either 0 - 4 or a very-low/low/medium/high/very-high Enum)
  • maxBitrate (in kpbs - how to calculate need TBD)

(note, possibly "bitrate" defined as a PropertyValueRange with min and max would be better)

Conceptually, the RTCMediaTrackTransmissionController always exists. If it doesn't have a handler for the overconstrained event, the overconstrained event simply disappears.

Example

Example: Assume that a MediaStream, containing (video) track X, has been added to PeerConnection PC.

We'd like to allow up to 400 kbps for transmission of this track over the network, and give it high priority (4). But none of those constraints are mandatory - we use optional ones.

var transmissionController_for_X = PC.getMediaTrackTransmissionController(X);

var transmissionConstraints = {
	optional: [
		{"maxBitrate" : 400},   //max 400 kbps
		{"priority" : 4}
	]
}

transmissionController_for_X.applyConstraints(transmissionConstraints, success, error);

function success (appliedConstr) {
	console.log("transport constraints successfully applied");
	console.log("settings: ");
	var settings = transmissionController_for_X.settings();
	if (settings.maxBitrate) console.log("maxBitate setting currently: " + settings.maxBitrate)
        else console.log("no setting for maxBitrate";
	if (settings.priority) console.log("priority setting currently: " + settings.priority)
        else console.log("no setting for priority";
}

function error (failedConstraint) {
	//Deal with the error
}
	

/* At some later point in time, the app somehow gets the information
that higher bandwidth is available, and therefore increases maxBitrate */

transmissionConstraints.optional[0] = {"maxBitrate" : 800};

transmissionController_for_X.applyConstraints(transmissionConstraints, success, error);