RE: RTPSender/Receiver - The case for Constraints

Hello Bernard

  Some thoughts inline.

From: Bernard Aboba []
Sent: Friday, May 16, 2014 10:36 AM
To: Stefan Håkansson LK;
Subject: RE: RTPSender/Receiver  - The case for Constraints

Stefan said:

"All of those constraints are applicable to the MediaStreamTrack that is added to the PeerConnection. "

[BA] Right.   Why apply those same constraints twice?

I do agree with you that no constraints are needed if the ones applied at the MST leave suffices for 
a given session. 

At the same time, I see a need to apply constraints on RTPEncoding(RTPStream) level for 
the reasons mentioned below

1. New constrainable attributes that applies only to the RTP Stream such as bandwidth, QOS,  and
goes along with the one defined at the track level (resolution, framerate).

2. The cases where we want PC to act as a Media Source Transform so that any such transformations
via constraints will not impact the originating media source and other associated sinks. 

3. I am aware we might not be interested in solving Simulcast/Layered coding like Multi-streams
per track at this point in time, but enabling RTPStream level constraints is quite useful to achieve
such a functionality.


Received on Friday, 16 May 2014 22:27:50 UTC