Re: Fwd: Proposal for some constrains we need

This feels like we are heading down the path of creating a low-level API,
but using constraints, which seems like the wrong control surface.

Wouldn't it be better to provide accessors on SessionDescription to allow
these properties to be set directly? This would allow any configuration to
be set without having to a) add a constraint for each feature and b)
perform any SDP munging.






On Mon, Jan 28, 2013 at 6:29 AM, Stefan Håkansson LK <
stefan.lk.hakansson@ericsson.com> wrote:

> On 2013-01-28 15:11, Cullen Jennings (fluffy) wrote:
>
>>
>> Resend of message to list with no attachment.
>>
>>
>> Begin forwarded message:
>>
>>  Hi Cullen
>>>
>>> Your message hasn't made it to the list, because its size (due to the
>>> attachment) is larger than what our list accepts; you could post the
>>> attachment somewhere else (e.g. on the group wiki, or as an attachment
>>> to a message to www-archive@w3.org) and then re-send your message with a
>>> pointer to the on-line version of the file?
>>>
>>> Thanks,
>>>
>>> Dom
>>>
>>> Le dimanche 27 janvier 2013 à 23:11 +0000, Cullen Jennings (fluffy) a
>>> écrit :
>>>
>>>> In several meetings we have discussed that we need to do things like
>>>> allow the JS to disable the bundle option but that never got that in the
>>>> API draft.
>>>>
>>>> We have also discussed that for common things that people want to do to
>>>> manipulate SDP, it's better to privde a simple programatic way of doing
>>>> that than making them parse and recreate SDP. I'd like to propose a simple
>>>> set of constraints to add to the PeerConnection to do the things people
>>>> have identified in the past as desirable. Note that 99% of JS applications
>>>> would probably never set any of these. I've considered the code in FF &
>>>> Chrome a bit and they seem easy to implement.
>>>>
>>>>
>>>>
>>>> UseRtpMUX
>>>>
>>>> This is an enum type constraint that can take the values "true",
>>>> "false". The
>>>> default is a non mandatory "true".
>>>>
>>>> This indicates that a the RTP packets should all be multiplexed on the
>>>> same
>>>> UDP port.
>>>>
>>>> UseRtcpMUX
>>>>
>>>> This is an enum type constraint that can take the values "true",
>>>> "false". The
>>>> default is a non mandatory "true".
>>>>
>>>> This indicates that a the RTCP and RTP packets should all be
>>>> multiplexed on
>>>> the same UDP port.
>>>>
>>>> UseAVPF
>>>>
>>>> This is an enum type constraint that can take the values "true",
>>>> "false". The
>>>> default is a non mandatory "true".
>>>>
>>>> This indicates that RTCP Feedback Capability Attribute mechanisms as
>>>> specified
>>>> in RFC 4585 should be used.
>>>>
>>>> UseRtpExtensions
>>>>
>>>> This is an enum type constraint that can take the values "true",
>>>> "false". The
>>>> default is a non mandatory "true".
>>>>
>>>> This indicates that RTP header extensions can be used.
>>>>
>>>
> For the above, it is not clear where/when they can be applied. It could be:
> a. At PeerConnection creation (meaning that all offers/answers created
> would follow those constraints)
> b. At createOffer/Answer - but then what should happen e.g. if you have a
> session going that is all multiplexed, but then you create a new Offer with
> constraints saying "do not multiplex"? Should the complete session
> re-negotiate (to not use multiplexing), or should just new streams/tracks
> follow the new constraints?
> c. associated with a certain MediaStream or MediaStreamTrack. Would mean
> that some streams/tracks could use multiplexing, some not.
>
> To me a. seems the clearest.
>
>
>
>>>> JavascriptMediaAccess
>>>>
>>>> This is an enum type constraint that can take the values "true",
>>>> "false". The
>>>> default is a mandatory "false".
>>>>
>>>> This indicates that JavaScript can access the media content such as
>>>> audio or
>>>> video. The reason for defaulting to false is to make it easier to
>>>> detect an
>>>> applications that changes it to true. Browsers MUST support this
>>>> constraint
>>>> and MUST implement the "false" option as this is important for security.
>>>>
>>>
> Is this not more relevant for the getUserMedia document, and less for
> webrtc?
>
>
>
>>>> AudioFrameSize
>>>>
>>>> This is an max type constraint. The default is a non mandatory "20".
>>>>
>>>> This indicates the desired size for RTP audio frames in mili seconds.
>>>> If you
>>>> think you need to adjust this, it will probably reduce your
>>>> interoperability
>>>> with other systems.
>>>>
>>>> AudioEncodingComplexity
>>>>
>>>> This is an integer type constraint that can take the values 1 to 10. The
>>>> default is a non mandatory "5". Open Issue: IANA Constraints registry
>>>> does not
>>>> seem to work for this.
>>>>
>>>> This indicates the relative amount of CPU that should be used by the
>>>> audio
>>>> encoder. 10 means more CPU. 1 means less. What this does will be
>>>> dependent on
>>>> the implementations and the codec chosen. If you feel you need to
>>>> adjust this,
>>>> it probably won't do what you want.
>>>>
>>>> VideoEncodingComplexity
>>>>
>>>> This is an integer type constraint that can take the values 1 to 10. The
>>>> default is a non mandatory "5". Open Issue: IANA Constraints registry
>>>> does not
>>>> seem to work for this.
>>>>
>>>> This indicates the relative amount of CPU that should be used by the
>>>> video
>>>> encoder. 10 means more CPU. 1 means less. What this does will be
>>>> dependent on
>>>> the implementations and the codec chosen. If you feel you need to
>>>> adjust this,
>>>> it might make some difference.
>>>>
>>>> ConstantBitRateAudio
>>>>
>>>> This is an enum type constraint that can take the values "true",
>>>> "false". The
>>>> default is a mandatory "true".
>>>>
>>>> This indicates if the audio and codecs should allow variable or
>>>> constant bit
>>>> rate audio encoding. Due to possible security concerns with variable
>>>> bit rate
>>>> audio, this defaults to using constant bit rate. Browsers MUST
>>>> implement this
>>>> constraints and MUST support a constant bitrate option as this is
>>>> important
>>>> for security.
>>>>
>>>> MaxBandwidth
>>>>
>>>> This is an max type constraint that specifies the upper bound of the
>>>> bandwidth
>>>> in kilobits per second. The default is a non mandatory infinity.
>>>>
>>>
> I think these last 5 are more related to individual tracks than to the
> session. (You might want to give an important video more CPU than a less
> important one).
>
>
>
>>>>
>>>> TODO
>>>> need to
>>>> sort out if this limit is for PeerConnection, Stream, or Track.
>>>>
>>>>
>>>> WIth them added, the spec would look roughly like
>>>>
>>>>
>>>
>>
>>
>
>