W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

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

From: Peter Thatcher <pthatcher@google.com>
Date: Fri, 19 Jul 2013 18:56:50 -0700
Message-ID: <CAJrXDUFHYCGRQRksgHbWY3Ob7yaxAua9kHm5G8nryLHHP6WkDA@mail.gmail.com>
To: Cullen Jennings <fluffy@iii.ca>
Cc: public-webrtc@w3.org, "&lt,rtcweb@ietf.org&gt," <rtcweb@ietf.org>, "Matthew Kaufman (SKYPE)" <matthew.kaufman@skype.net>
On Jul 19, 2013 6:47 PM, "Cullen Jennings" <fluffy@iii.ca> wrote:
>
>
> 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.
>
>
> On Jul 19, 2013, at 7:49 AM, Peter Thatcher <pthatcher@google.com> wrote:
>
> > "mindless works fist"?  There's a deep meaning there, but I'm still
trying to figure it out...
> >
> >
> > On Fri, Jul 19, 2013 at 7:04 AM, Cullen Jennings <fluffy@iii.ca> wrote:
> > Folks wanted to sort out how mindless works fist before getting to
theses smaller details but in general I think progress is being made on all
of these
> >
> > On Jul 17, 2013, at 2:58 PM, "Matthew Kaufman (SKYPE)" <
matthew.kaufman@skype.net> wrote:
> >
> > > Bernard Aboba:
> > >>
> > >> The problem was that we never defined what mangling browsers had to
> > >> support. Given all the SDP specs that is actually a huge work item.
> > >
> > >
> > > This is exactly what my slides that weren't presented last November
started to touch upon. It only takes a few minutes with RFC3264 and its
references to start documenting cases that are clearly "valid SDP
offer/answer" and yet for which I cannot for the life of me figure out what
a browser should do if they're presented.
> > >
> > > Just off the top of my head:
> > >
> > > 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.
>
> > > - Change the rtpmap associations before calling setLocal?
>
> you can remove or reorder
>
> > > - Change a=sendrecv to a=recvonly before calling setLocal?
>
> Current JSEP draft says that is done with constraints
>
> > > - 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
>
> > > - What if someone adds an r= or p= or e=?
>
> Current JSEP draft says the browser does not need to allow that
>
> > - 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.
>
>
> > > - Can I remove a=group:BUNDLE (or add it) before calling setLocal?
>
> Current JSEP draft says that is done with constraints
>
> > > - How about removing a=rtcp-mux?
>
> Current JSEP draft says that is done with constraints
>
>
> > > - Should I do something special at my end if you set
a=ice-options:google-ice ?
>
> Do whatever the ice spec say
>
> > > - 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.
>
>
> > > - Can I delete the a=ssrc lines?
>
> Current JSEP draft says the browser does not need to allow that to be
changed.
>
>
> > > - Is a=rtcp:1 IN IP4 0.0.0.0 valid or not?
>
> Why would a browser want to generate that?
>
> > > - What about 0.0.0.0 in the o= line?
>
> Why would a browser want to generate that?
>
> > > - 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.
>
> > > - 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
>
>
> > >
> > > 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.
>
> 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.

FYI, Adam today said "we're nowhere close" and now you're saying it "won't
be much work".

>
> > >
> > > Matthew Kaufman
> > >
> > > _______________________________________________
> > > rtcweb mailing list
> > > rtcweb@ietf.org
> > > https://www.ietf.org/mailman/listinfo/rtcweb
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
>
Received on Saturday, 20 July 2013 01:57:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:35 UTC