Re: Moving forward with SDP control

I have two "Why+What's" and one "How":

1. Pause/resume sending of a MediaStreamTrack
---------------------------------------------
Why: There are many scenarios where it would make sense to be able ask 
the browser to send a MediaStreamTrack (while keeping RTCP going). One 
example is in a multiparty service using simulcast. If the large scale 
version of your video is not shown for any of the other participants in 
the session, it makes sense to pause the sending (but be able to quickly 
resume if a talker switch means your video will be shown).

Currently we have "disable" on MediaStreamTrack level, but that 
corresponds to sending blackness /silence.

Note also that the very first use-case in [1] talks about the 
possibility to pause sending of audio and video.

What: This depends on how we signal pause/resume. *If* this is done by 
using sendonly/recvonly/inactive in the SDP this is what I think should 
be available in an API. (I still think RTCP signaling for this makes 
more sense.)


2. Setting BW for a MediaStreamTrack
------------------------------------
Why: There are situations where a suitable start bit-rate can be known, 
or guessed. If this knowledge could be used the perceived end-user 
quality could be improved (since a higher quality is available from 
start since there is no need to start at a really low bit-rate).

There are also situations where it could be beneficial if min and max 
bit-rates to be used can be influenced.

* The app developer may know that below a certain bit-rate the quality 
is so bad that the browser could stop sending it, and likewise there may 
be knowledge about a bit-rate above which the quality does not improve.

* There are situations when there is an agreement between the service 
provider and the connectivity provider about min and max bit-rates.

What: Again, this depends on how much BW info is included in the SDP. 
But my understanding is that there should be some (since RTCP rates to 
be used are based on this info IIUC).

(3. Other stuff, but not signaled
--------------------------------
There are other parameters on how media (per MediaStreamTrack) is 
handled when to be sent over the network that do not need any signaling 
- such as priority, type of audio (to determine if AGC should be used or 
not), etc., mentioned in [1]. While not signaled, it could make sense to 
have the same API surface for this kind of settings.)

How:
----
I think that what I proposed a long time ago [2] is not completely 
broken. I mimics the DTMFSender pattern, it re-uses the constraint model 
that we already have in "Media Capture and Streams" [3], it offers one 
surface to control parameters related to sending a MediaStreamTrack over 
the network. It also does not break any existing applications since the 
use of it is not needed. Using certain constraints or methods would lead 
to a "negotiationneeded" event since the SDP is affected, others would 
not (since they will not need any signaling).

But I'm sure we will see better proposals.

Stefan

[1] 
http://datatracker.ietf.org/doc/draft-ietf-rtcweb-use-cases-and-requirements/?include_text=1
[2] 
http://lists.w3.org/Archives/Public/public-webrtc/2013Jan/att-0005/PrioAPI.pdf
[3] http://dev.w3.org/2011/webrtc/editor/getusermedia.html



On 7/16/13 2:19 PM, Harald Alvestrand wrote:
> Hi all,
>
> Recently there has been a lot of discussion (primarily in the
> IETF/rtcweb space though, but this topic really belongs here) about the
> desire to meet most use-cases without having to parse, modify or
> construct SDP.
> This was discussed already as part of the discussion on whether
> PeerConnection and SDP should be maintained or not last year [1].
>
> In the meantime, a number of API extensions have been created, notably
> the constraints setting and modification interfaces, which seem likely
> to be useful in achieving the goals people seek to achieve by SDP mangling.
>
> However, this work has not progressed very quickly, or very comprehensively.
> It may be time for a more structured approach.
>
> We think it makes sense to divide the information needed into subcategories:
>
> * Define the use cases for which SDP mangling is currently thought to be
> required - the "why" of the SDP tweaking.
>
> * Propose what parameters one should be able to control/influence
> without having to do SDP mangling. A proposal should describe what the
> current API specification produces, what the needed mangling is, and
> what the desired effect of the mangling is - the "what" of the SDP tweaking.
>
> * Propose suitable API surfaces to control/influence how media is
> encoded and transported over the network - the "how" of the SDP
> tweaking. We think that a requirement should be that working
> applications do not break when adding this surface - if it is not used
> things should work as today.
>
> Someone may make a proposal encompassing all 3 pieces of information
> (why, what and how) - or just some of the first ones - or a proposal for
> a latter one that builds upon others' proposals (a "how" building on
> someone else's "why" and "what"). But we would not want to consider a
> "how" without a "what", or a "what" without a "why" - it just becomes
> impossible to figure out whether the original requirement is satisfied
> if we don't build all 3 layers of the proposals.
>
> Does this sound like a way we could move forward?
>
> Harald for the chairs.
>
> [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Sep/0098.html
>
>

Received on Thursday, 18 July 2013 12:22:02 UTC