Re: Cisco's position on the WebRTC API

On Tue, Jul 23, 2013 at 6:48 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> On Wed, Jul 24, 2013 at 11:14 AM, Eric Rescorla <ekr@rtfm.com> wrote:
>
> > I wasn't at the conference, but I think it would really be helpful if
> your
> > complaint here
> > was more precise. As I understand it, Cullen's position is something like
> > the following:
> >
> > - In general, people won't have to deal with SDP because the API will let
> > you do
> >   what you want to do without interacting with SDP.
>
> Sorry to have to say this, but this is not true. For anything that is
> a bit more than a basic peer-to-peer connection, you have to mangle
> the SDP.
>

There is a reason I wrote this in the future tense. I agree this is not
currently true.


That includes trivial things like muting,


I think you're conflating a number of features here:

1. Stop sending media to the other side. This needs to be done with
some API call on the media stream to mute it. In Firefox, at least
you do this by setting .enabled to false. I'm not sure if there
is WG consensus that this is the right plan. Regardless, no
signaling is required.

2. Stop playing the media from the other side. This is just done
by muting the element the MS is playing into.

3. Tell the other side to stop sending media (often called "hold").
It's not clear how one would do that. Note that this also plays into
the question of how one rejects an incoming MST offer.


> changing bandwidth use,


Yes, there's no way to do that. We would need to add something.



> or
> receive-only.


"OfferToReceiveVideo" and "OfferToReceiveAudio"




> I don't think you can seriously state that the API is
> complete even for simple WebRTC applications.


I'm not claiming that. I'm saying that that's the objective.


> At minimum I'd like to
> see an extension of the constraints API.
>
> Some things may need to be added to getUserMedia (such as a .mute()
> function on MediaStream), but since it has effect on SDP and requires
> renegotiation, it likely needs to be specified in both specs (webrtc
> 1.0 and getUserMedia).
>
>
> > - To the extent to which there are meaningful use cases that the API
> doesn't
> >   deal with, we want to eventually add features to the SDP to deal with
> > that.
>
> Add features to the SDP? I think first we need to add API functions
> that lets us deal with features that are already possible with the
> existing SDP.
>
> That was a typo. I meant "add features to the API"


> Do take my suggestion for a .mute() function on MediaStream as such a
> concrete proposal.
>

I think this is more complicated than you suggest, as indicated above. I
agree
something is needed.



> Another concrete proposal is to add a bandwidth limitation to the
> constraints handling.
>
> This would be good.


And a third is to introduce receive-only peer connections instead of
> having to do:
> desc.sdp = desc.sdp.replace(/a=sendrecv/g, "a=recvonly");
> Maybe this part can go into the RTCConfiguration?
>
> I think this already exists.

Thanks for listening,
>

Thanks for making a concrete proposal.

Best,
-Ekr


> Silvia.
>