Max media/video streaming bitrate API

[maheshc01]

Hi team,

I have a feature proposal which I think is a good fit for this API proposal/API family.
The proposal is focussed on helping streaming applications to get an insight on what is the maximum bit rate support by a device so that they can use the same information for streaming.

MediaRateAPI_CamaraProposal.pdf
Please find more details about the proposal in the attached file.
I would like to know the team's opinion if this proposal would be a good fit for this API working group.

[eric-murray]

Hi @maheshc01

Thanks for the proposal. Using the current maximum downlink media bitrate as a quality measure is, I think, a good proposal as it is simple, intuitive, and applicable to many uses case even when these are not directly video streaming applications.

So I would suggest to open an issue (or comment in this one) to introduce the API proposal. There is a meeting this Wednesday where it can be discussed.

It may be that longer term the API is moved to a separate repository specific for the use case (as was done for DeviceDataVolume) but, given that maximum media bitrate can be considered to be a quality indicator, and given there are no other specific proposals for this API, I think this is as good a home as any for such an API at the moment.

On the specific proposal, I would comment:

• For your documented use case where the app client calls the API, this will generally be done using the authorisation code flow to identify the device. The only change you need to make to the YAML is to make the device parameter optional (for use only with client credentials).
• For the output parameter, I would suggest to copy the schema used by the qos-profiles API for the maxDownstreamRate parameter. Following the naming convention used by that API, the output parameter name should probably be maxDownstreamMediaRate.
• Although your call flow shows only a limited number of rate options (2, 4 and 900(!) Mbps), my preference would be to keep same granularity as defined in qos-profiles, which allows arbitrary rates to be specified in 1 bps increments up to 1024 Tbps. Any quantisation (e.g. rounding to the nearest Mbps), can be left up to each API provider.

[maheshc01]

Hi Eric,

Thank you for your response and support for this API Proposal.
I will go ahead and create a issue for this API proposal and also a PR for the API yaml and supporting documents.
I have updated the yaml to address all the 3 points you have mentioned. for bitrate, I have updated the type to number and doest have any limits as of now. I have aligned to the Spring 25 ICM and Commonalities standards.

based on the review comments i get i can plan for additional updates.