RE: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

From: Cullen Jennings [mailto:fluffy@iii.ca]:
> 
> Well that was clearly one or my more mindless emails
> 
> What I mean to say was something along lines of
> 
> Folks want to sort out the multiplexing / bundle stuff first.
> 
> So let me suggest that folks read section 6 of the JSEP draft and see if they
> can answer most of of the questions below. I'm not saying that section 6 is
> right, in fact I think some of it is wrong. But at least act like you have read it.
> 

Well, first off the "JSEP draft" is an Internet Draft, and I thought we were writing a W3C API here. But I'll play along this time. I'm assuming of course that we're all talking about the latest JSEP draft, which appears to be draft-ietf-rtcweb-jsep-03, wherein "section 6" is only a page and a third long.

> > > Can I...
> > > - Change the t= line to be something other than t=0 0?
> 
> Current JSEP draft says the browser does not need to allow that to be
> changed.

Where? Don't see that at all.

> 
> > > - Change the rtpmap associations before calling setLocal?
> 
> you can remove or reorder

But can I change which numbers are assigned? Like if I want 115 for opus instead of 112?

> 
> > > - Change a=sendrecv to a=recvonly before calling setLocal?
> 
> Current JSEP draft says that is done with constraints

And it says "these changes may also be be performed by manipulating the SDP returned from createOffer/createAnswer" (and yes, it really does say "be be")

So I guess the answer to this one is "yes"

> 
> > > - What do you do when you see a=content:sl ?
> 
> not in current spec but you can find dissection on list about making sure that
> is available to API


Agreed, not specified.

> 
> > > - What if someone adds an r= or p= or e=?
> 
> Current JSEP draft says the browser does not need to allow that


No, it says that since should accept valid SDP, it should accept it. At least that's how I read the spec.

> 
> > - What is the RFC that describes a=group:BUNDLE (as seen in some browser
> implementations)?
> 
> Uh, I'll leave that as an exercise to the readers. Try hard and see if you can
> find it.

Appears to be work in progress in the MMUSIC WG. So no normative spec that can be referenced. Guess it must not be allowed, huh?

> > > - Can I remove a=group:BUNDLE (or add it) before calling setLocal?
> 
> Current JSEP draft says that is done with constraints

(Or by modifying the SDP, see above... and there's no API for said constraint)

> 
> > > - How about removing a=rtcp-mux?
> 
> Current JSEP draft says that is done with constraints

(Or by modifying the SDP, see above... and no API for this constraint either)

> 
> 
> > > - Should I do something special at my end if you set a=ice-options:google-
> ice ?
> 
> Do whatever the ice spec say

Section 15.5 of RFC5245 says absolutely nothing about what I'm supposed to do with this. And that's the only place a=ice-options is discussed.

> 
> > > - If you put a=ssrc lines in there, can I change the ssrc before passing it
> back to setLocal?
> Current JSEP draft says the browser does not need to allow that to be
> changed.

Not true. The current spec says that the non-changeable lines are the "number, type and port number of m-lines" "the generated ICE credentials" and "the set of ICE candidates and their parameters". 

Section 4.1 R-8 suggests that RFC5576 MUST be implemented to signal RTP SSRC values, but nowhere does it tell me (and especially not in section 6) if the browser will or should let me change them between createOffer and setLocal.


> 
> 
> > > - Can I delete the a=ssrc lines?
> 
> Current JSEP draft says the browser does not need to allow that to be
> changed.

Disagree. See above.

> 
> 
> > > - Is a=rtcp:1 IN IP4 0.0.0.0 valid or not?
> 
> Why would a browser want to generate that?

I don't know. I have output from browsers that have generated that in the past. Was that a bug?

> 
> > > - What about 0.0.0.0 in the o= line?
> 
> Why would a browser want to generate that?

(Same as previous comment)

> 
> > > - If I get a bunch of a=candidate lines, can I swap them around to change
> the priority before calling setLocal?
> 
> Current JSEP draft says the browser does not need to allow that to be
> changed.

This appears to be correct. Which is of course unfortunate, as I might very well wish to do this. Or delete candidates, which also appears to be forbidden in section 6, despite several *very* valid use cases for deleting candidates a browser happens to generate.

> 
> > > - What if someone claims SAVP instead of SAVPF but gives me rtcp info?
> 
> We need to add text to explicitly cover that. You can find text on what I think
> we should do for this in
> draft-jennings-rtcweb-plan-01

Then we should add that text. To a W3C specification that covers what the browser must do.

> 
> 
> > >
> > > At the *very least* for each and every line that comes from createOffer
> and createAnswer you must be able to answer the following:
> > > - Can I delete it?
> > > - Duplicate it?
> > > - Change it?
> > > - If not, how are violation handled? (Both when passed to another
> browser at the far end and when these modifications happen before calling
> setLocal)
> > > - And can I add additional valid SDP to what came from createOffer or
> createAnswer and pass it back to setLocal or not?
> > >
> > > We appear to be nowhere near a document which explains the answers
> to these questions, certainly not in the W3C WG, and not in any IETF RFC or
> draft I can locate.
> 
> draft-ietf-rtcweb-jsep-03 has tried to address some of these. I certainly don't
> claim it is perfect but if people have use cases that suggest a change to this,
> love to get text on what it should be.

I don't think it is close at all. See above comments.

> 
> Mathew has been very clear along the way of "we need to define X to have
> an interoperable system" and for most values of X he has proposed, I agree
> with him. However, I think we just need to do that and that it actually won't
> be much work once we get the framework in place to deal with thinks like
> how many ports is the RTP using and how many m-lines does the SDP have.

Well, at least we do agree that the specification for what the browser must do should be written down somewhere.

What we don't agree on is how trivial that problem is.

Matthew Kaufman

Received on Saturday, 20 July 2013 03:39:39 UTC