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

From: Peter Thatcher <[email-masked]>
Date: Wed, 3 Jul 2013 14:06:30 -0700

After about a week of input, and feedback from 19 developers doing a wide
range of things using the WebRTC API, we have some data about their opinion
of the current API.

*Short answer*:

61% "Good for simple Stuff"    49% "Bad for simple stuff"
 6% "Good for advanced stuff"      94% "Bad for advanced stuff"
46% "Good/OK/tolerable for 1.0"    54% "Horrible/intolerable for 1.0"
 7% "Good/OK/tolerable long-term"  93% "Need a better API long-term"

In general the attitude is *"It's OK for simple stuff but bad for advanced
stuff",  *and *"We can tolerate it for 1.0, but we need something better
for 2.0".  *But the majority of the feedback was against it even for the
1.0, so the last one is a bit of a stretch.

*Long Answer*:

I had to interpret the results a little to fit into these buckets, so if
you don't like the interpretation, you're more than welcome to interpret
your own results from the raw data:
https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1

There seem to be 4 or 5 different camps:

Camp #1:  Doing very simple things, doesn't touch the SDP.  Everything is
fine, except they might have things they want to control but can't.

Camp #2:  Does somewhat more advanced things, touches the SDP a little, has
pain, anticipates more pain, would like something better, but thinks this
is OK for 1.0.

Camp #3:  Is trying advanced things, is touching the SDP a lot, and really
feels pain.  Wants something better, and might tolerate this API for 1.0,
but not for long.

Camp #4:  Doesn't want SDP or O/A in the API at all.  Has a very strong
dislike for it.  Won't tolerate it, even for 1.0.  The IETF and W3C should
be embarrassed for even suggesting such a terrible API.  It's better to go
back to the drawing board (if you think those words are strong, go read the
spreadsheet or mailing list!)

Oh, and of course, for completeness, we should describe Camp #0, which
didn't have any input in this feedback:

Camp #0:  I've used SDP for years and I'm very comfortable with it.  Using
SDP as the control surface really helps my use case, which is legacy
interop.  Defining an API without SDP would be too much work, and probably
fail.  Look at what happened with SDPng!  Supporting all these advanced use
cases doesn't seem worth it.   If developers are doing that much advanced
stuff, they can learn to munge SDP.  It isn't that bad.

(By the way, I'm not a member of Camp #0, so I may be a little off in my
description of it.  If any member of Camp #0 would like to adjust that
description, please feel free).

*Suggested Next Step: Figure out what is needed for WebRTC++*
*
*
As Cullen recently pointed out, we need to get a list of things developers
want to be able to control in a future version of the API which could
hopefully make developers happier Whether that future API is 1.0, 2.0, or
1.1 is an orthogonal question, but let's call it WebRTC++ for now.
Clearly, they want a way to control things without SDP, and perhaps without
O/A at all.  But what do they want to control?  We need a good list.

I suggest we reach out more closely to the developers, and use their input
to create not only a list of things they want to do, but a WebRTC++ API
that fulfills those needs without requiring SDP munging.  I think we can do
this in parallel with the current  API work without detracting from it
(from the current work, that is).    Certainly there is plenty of energy
from people interested in working on it (WebRTC++, that is).  Such parallel
work would not only better capture the needs of developers, but could also
improve the WebRTC (not ++) API  by incorporating ideas from it.

So far, such activity has been frowned on, perhaps out of fear that it's a
threat to the current work.  But I think it can be done in a way that
doesn't threaten anything, and even learns from and builds on the valuable
input we are receiving from developers.  The alternative is to ask all
these developers to wait an indefinite amount of time and munge SDP like
crazy until then, and that seems like a rather poor answer.  Therefore, I
would support an exploratory effort at a "WebRTC++ API".

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jul 2013 14:20:41 -0700

> stuff, they can learn to munge SDP.  It isn't that bad.

Hmm... That's not my understanding of the situation at all.

Rather, I believe the expectation is that you shouldn't have to modify the
SDP but rather there should be API points to cover most of the use cases
that people want. This isn't to say that all those API points exist or that
they work or whatever.

-Ekr

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 3 Jul 2013 14:25:59 -0700

On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla <[email-masked]> wrote:

> On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <[email-masked]>wrote:
>
>> Camp #0:  I've used SDP for years and I'm very comfortable with it.
>>  Using SDP as the control surface really helps my use case, which is legacy
I'm glad to be wrong here.  Is the phrase "you shouldn't have to modify the
SDP but rather there should be API points to cover most of the use cases"
 the consensus of the working group?  That would be (good) news to me.
 Because if it's true, then we can just go ahead and add those API points
and make the developers happy.

Along with that, is "use Jingle for signalling" included in your set of
"most of the use cases"?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Jul 2013 23:35:48 +0200

El 03/07/2013 23:26, "Peter Thatcher" <[email-masked]> escribió:

"most of the use cases"?

+1 good question. Hope there is a so good answer for it. Is it?

BTW not just Jingle but any (future?) media signaling protocol not based on
atomic full SDP blob exchange. Could somebody explain me how to do that
without mangling the SDP blob generated by PC?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jul 2013 14:36:36 -0700

On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <[email-masked]> wrote:

> I'm glad to be wrong here.  Is the phrase "you shouldn't have to modify
> the SDP but rather there should be API points to cover most of the use
> cases"  the consensus of the working group?
>

I thought it was, but I'm not the chair, so maybe you could ask Harald or
Stefan.

> "most of the use cases"?

No, I don't think it is, since it's not SDP.

Maybe I could phrase this differently: It was my understanding that you
should have
API points to get the PC to emit SDP that would express the policies,
preferences,
actions, etc. that the application wants. If you want something that's not
SDP you would
need to gateway.

This may or may not be a satisfactory state of affairs, but it was the rule
I was using
(based on what I thought the WG expected) for when use cases needed new API
points.

-Ekr

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 3 Jul 2013 23:42:41 +0200

So compatibility with SIP is important but compatibility with Jingle is
just impossible. And this is supposed to be the API proposed to W3C...

--
Iñaki Baz Castillo
<[email-masked]>
El 03/07/2013 23:37, "Eric Rescorla" <[email-masked]> escribió:

> On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <[email-masked]>wrote:
>
>  actions, etc. that the application wants. If you want something that's
> not SDP you would
> need to gateway.
>
> This may or may not be a satisfactory state of affairs, but it was the
> rule I was using
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jul 2013 15:04:56 -0700

> just impossible. And this is supposed to be the API proposed to W3C...
Who said anything about impossible? It's a mechanical transformation
(see: http://xmpp.org/extensions/xep-0167.html).

Anyway, it's not like this feature is a surprise to anyone--well at
least anyone who was paying attention--it's been a feature of the
specification since before the WG was even formed. As I said
earlier, it was in the original WHATWG spec that Ian Hickson
wrote.

-Ekr

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 3 Jul 2013 15:16:54 -0700

> earlier, it was in the original WHATWG spec that Ian Hickson
There are lots of application developers who weren't around back then, so
it's not reasonable to expect them to have been paying attention back then.
 Many are very new to this, and there are lots of surprises for them.

And as many developers are now trying to use the WebRTC API, we're now
getting feedback on how well it works for them.  The point of my original
post in this thread was to summarize the feedback we've received so far for
the WG.

It wasn't my intention to re-start arguments between one camp and another.
  But your clarification of "Camp #0" was helpful, so thank for you for
that.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 4 Jul 2013 00:17:21 +0200

> earlier, it was in the original WHATWG spec that Ian Hickson

I know, and I was a  "SDP supporter" at the beginning (and much others
like me who, after dealing with it for something more than just single
audio+video phone calls, have changed their mind). I don't consider
that such a "original WHATWG spec" is written in a stone. It was an
initial proposal after all. Nothing prevents it to be radically
modified/improved now.

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jul 2013 15:20:49 -0700

>  There are lots of application developers who weren't around back then,
> so it's not reasonable to expect them to have been paying attention back
> then.  Many are very new to this, and there are lots of surprises for them.
>

The person I was responding to has posts on this mailing list going back as
far as September 2011.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jul 2013 15:27:43 -0700

On Wed, Jul 3, 2013 at 3:17 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> audio+video phone calls, have changed their mind).

This leaves me puzzled by your complaint that the current specification
doesn't support Jingle out of the box, since that's been obvious from the
very beginning and it's not like that's something that required extensive
developer experience to discern. If this is important, why didn't you
complain then?

-Ekr

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 3 Jul 2013 15:28:07 -0700

On Wed, Jul 3, 2013 at 3:20 PM, Eric Rescorla <[email-masked]> wrote:

>
>
>
> On Wed, Jul 3, 2013 at 3:16 PM, Peter Thatcher <[email-masked]>wrote:
>
>>
>>
>>
>>> On Wed, Jul 3, 2013 at 2:42 PM, Iñaki Baz Castillo <[email-masked]>wrote:
>>>
> The person I was responding to has posts on this mailing list going back
> as far as September 2011.
>
> -Ekr
>

You said "it's not like this feature is a surprise to anyone",  and I
thought "anyone" was a bit broader than that.  Sorry for the
misunderstanding.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 3 Jul 2013 15:34:04 -0700

> developer experience to discern. If this is important, why didn't you

Looking back at your posts from back then, I see you did in fact suggest
a set of API modifications that would have included an abstract session
description. That would in fact have made Jingle somewhat (though not
really that much) easier. So my last sentence here is unfair. My apologies.

-Ekr

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 4 Jul 2013 08:35:46 +0200 (CEST)

> (see: http://xmpp.org/extensions/xep-0167.html).

That is true for simple usage and works reasonably well. See my
strophe.jingle code on github. I'd note that I want to revamp
the API such that it wraps the peerconnections SDP apis more closely.

Things like the content-add/content-remove are harder because the API 
user is required to calculate an SDP delta/diff. The appendix A.1.3 of the 
JSEP draft calls this createContentAdd, parseContentAdd, 
createContentAccept and parseContentAccept. Has anyone ever implemented 
those operations in javascript and can demonstrate running code?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 4 Jul 2013 10:21:06 +0200

> really that much) easier. So my last sentence here is unfair. My apologies.

Initially I though that SessionDescription was a powerful JS Object
with all the fields and attributes to construct a SDP, so a developer
could extract those media/transport fields and create a SDP via JS. At
the same time, the SessionDescription object would include helper
methods (defined by the WebRTC API) to build a plain SDP (i.e. toSDP)
and some others like XML-SDP (i.e. toXMLSDP).

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Binod <[email-masked]>
Date: Thu, 04 Jul 2013 14:40:31 +0530

> and some others like XML-SDP (i.e. toXMLSDP).
I like that approach. Have an API to specify all/most of what is
in the SDP and then use a toSDP to generate actual SDP string to be sent
across the wire.

Other side should be able to reconstruct the browser side
object(s) using the received SDP string.

thanks,
Binod.

---

From: Robin Raymond <[email-masked]>
Date: Thu, 04 Jul 2013 07:32:50 -0400

+1 on object model with a "toSDP / fromSDP"  (FYI - an object model 
draft is looming shortly)

I think it's best to put "toSDP / fromSDP" outside the browser binary as 
a common github JS library because I know a lot of SIP folks love custom 
SDP extensions and being able to fork/tweak the SDP without petitioning 
the browser vendors for an "update" is important.

-Robin

> Binod <mailto:[email-masked]>
> 4 July, 2013 5:10 AM

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 4 Jul 2013 08:03:45 -0700

You will still be required to wrestle the browser's offer-answer state machine into submission to get the results you want.

Matthew Kaufman

(Sent from my iPhone)

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 6 Jul 2013 06:33:57 +0000

On 7/3/13 11:37 PM, Eric Rescorla wrote:
> On Wed, Jul 3, 2013 at 2:25 PM, Peter Thatcher <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Wed, Jul 3, 2013 at 2:20 PM, Eric Rescorla <[email-masked]
>     <mailto:[email-masked]>> wrote:
>
>         On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>             Camp #0:  I've used SDP for years and I'm very comfortable
>             with it.  Using SDP as the control surface really helps my
>             use case, which is legacy interop.  Defining an API without
>             SDP would be too much work, and probably fail.  Look at what
>             happened with SDPng!  Supporting all these advanced use
>             cases doesn't seem worth it.   If developers are doing that
>             much advanced stuff, they can learn to munge SDP.  It isn't
>             that bad.
>
>
>     I'm glad to be wrong here.  Is the phrase "you shouldn't have to
>     modify the SDP but rather there should be API points to cover most
>     of the use cases"  the consensus of the working group?
>
>

I definitely think this is the consensus of the working group.

I think the exception would be when interoperating with other systems 
that use another dialect of SDP - I don't think we could cover such 
translations with API points.

>
>
>     Along with that, is "use Jingle for signalling" included in your set
>     of "most of the use cases"?
>
>

---

From: Roman Shpount <[email-masked]>
Date: Sun, 7 Jul 2013 17:14:53 -0400

> I definitely think this is the consensus of the working group.
Can you point out when exactly this consensus was reached? This is news to
me, but I definitely could have missed something.
_____________
Roman Shpount

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Jul 2013 20:40:31 -0700

On Jul 3, 2013, at 2:42 PM, Iñaki Baz Castillo <[email-masked]> wrote:

> So compatibility with SIP is important but compatibility with Jingle is just impossible.

The mapping of SDP to jingle is in the Jingle specs … I'm not express any opinion on this one way or another other but the authors of theses specs have always claimed Jingle fully mapped to and from SDP.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Jul 2013 12:38:41 +0200

> The mapping of SDP to jingle is in the Jingle specs … I'm not express any opinion on this one way or another other but the authors of theses specs have always claimed Jingle fully mapped to and fro…

XEP-0167 defines a XML based SDP. Mapping it from/to plain SDP
requires, at least, having all the attributes of the SDP. Instead you
are proposing that the JS receives an opaque SDP blob from the
browser, so it must be parsed via JS if the app wants to convert it
into XML SDP.

It's really ugly and the worst specification for the Web.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 8 Jul 2013 12:11:56 +0000

On 7/7/13 11:14 PM, Roman Shpount wrote:
>
> On Sat, Jul 6, 2013 at 2:33 AM, Stefan Håkansson LK
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Can you point out when exactly this consensus was reached? This is news
> to me, but I definitely could have missed something.

No I can't really. To be clear, no consensus call (or similar) has been 
held. But every time this is discussed, what I hear is people agreeing 
and no objections. It was discussed a bit, e.g., at the f2f at TPAC last 
year, if you read the minutes [1] you will find some traces of that 
discussion.

And, I don't understand why there would be a debate about this. There 
are obviously many who want to define APIs (or constraints) that allow 
most use-cases to be met without having to modify the SDP. Why would 
anyone have anything against that? If there is anyone who really wants 
to modify the SDP instead (I have no clue why, but anyway) they can 
still do that.

[1] http://lists.w3.org/Archives/Public/public-webrtc/2012Nov/0072.html

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 06:56:48 -0700

Just in case it is missed elsewhere in the thread, I'll reply directly to
my own message.  It was pointed out to me that I made a mistake with my
addition.  The first line should have read:

61% "Good for simple Stuff"        39% "Bad for simple stuff"

Sorry about that.

On Wed, Jul 3, 2013 at 2:06 PM, Peter Thatcher <[email-masked]> wrote:

> In general the attitude is *"It's OK for simple stuff but bad for
> advanced stuff",  *and *"We can tolerate it for 1.0, but we need
> something better for 2.0".  *But the majority of the feedback was against
> it even for the 1.0, so the last one is a bit of a stretch.
>
>
> *Long Answer*:
>
> Camp #2:  Does somewhat more advanced things, touches the SDP a little,
> has pain, anticipates more pain, would like something better, but thinks
> this is OK for 1.0.
>

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 07:38:05 -0700

> discussion.

No objections at all?  That is rather surprising to me.  I asked for some
feedback the API in the spreadsheet from web developers, at there many
objections from them about this part of the API.  A majority did say it was
good enough for simple use cases, but he objections were still clearly
non-zero.

I think perhaps the web developers are not well represented at TPAC.  But I
could be wrong.  Perhaps they are but changed their mind.  Or maybe they're
objecting on the IETF mailing list when they should object on the IETF
mailing list.   Or maybe the spreadsheet has a sample bias, while TPAC is
the true sample.   I don't know, but it seems like something is going on,
and I'd like to know what it is.

Stefan, what do you think?  What could explain the apparent contradiction
between objections on the mailing list vs. no objections f2f?

Also, on discussions about the API, should those who want to propose
additions (such as the NoPlan JS API I proposed) and other comments put
them on the W3C mailing list instead of the IETF one?  Is everyone barking
up the wrong tree?

Thanks in advance for your input.

> most use-cases to be met without having to modify the SDP.  Why would

anyone have anything against that?

I think your question actually has two questions:

1.  Is anyone against making additions to the API to avoid SDP munging?

2.  Why are they against additions to the API to avoid SDP munging?

My personal experience for #1 is that there are some notable people in the
WG who are very much against making additions to the API to avoid SDP
munging.  Some of them are rather upset with me for proposing a few minor
additions to the API (the NoPlan JS API) precisely because it allows the JS
to go around the SDP in many cases, and they don't like that.  So, from my
experience, it's clear that the answer to #1 is "yes, many do".

And since many object to such additions, and others want such additions,
you end up with debate.

How about #2?  Why do they object?  My experience is that they view any
additions as a threat to API as a threat to the current API, which means
it's a threat to the current WG progress, which means it's a threat to
getting done.  They are very sensitive to such threats, and so object to
any additions or changes that would allow JS to avoid using SDP.  Also, I
think they don't want to ways of doing things, so SDP must remain the one
true way.

But that's just my personal experience and perspective.  I could just be
seeing it wrong, or maybe the only person experiencing this.

> I If there is anyone who really wants

Well, no one is going to hit themselves in the head with a hammer if they
don't have to, but there are many uses cases that currently be done only by
SDP munging, and I don't see any API additions on the horizon that will
help those uses cases.    So, until we can agree on some API additions that
help SDP munging, many web developers are going to have to keep swinging
that hammer, no matter how much it hurts.

But clearly, if you gave them an API that didn't require such pain, they
would use it.

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 07:40:04 -0700

On Sun, Jul 7, 2013 at 8:40 PM, Cullen Jennings <[email-masked]> wrote:

> just impossible.
> The mapping of SDP to jingle is in the Jingle specs … I'm not express any
> opinion on this one way or another other but the authors of theses specs
> have always claimed Jingle fully mapped to and from SDP.
>

I think he meant "impossible without SDP munging", which I think is
undeniable.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 08 Jul 2013 08:45:23 -0600

On 7/8/13 8:40 AM, Peter Thatcher wrote:
> On Sun, Jul 7, 2013 at 8:40 PM, Cullen Jennings <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
>     On Jul 3, 2013, at 2:42 PM, Iñaki Baz Castillo <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     The mapping of SDP to jingle is in the Jingle specs … I'm not
>     express any opinion on this one way or another other but the authors
>     of theses specs have always claimed Jingle fully mapped to and from SDP.
> 
> 

What do you mean by "SDP munging"?

As we know, various things are being added to SDP. The Jingle specs have
not necessarily been updated yet to track those changes, although
proposals have been made on several points. If folks want to keep Jingle
in sync, that work would need to happen at the XSF. Feel free to join
the [email-masked] list if you have proposals:

http://mail.jabber.org/mailman/listinfo/jingle

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 07:47:59 -0700

> What do you mean by "SDP munging"?

I mean that if the JS wants to send Jingle XML over the wire, it has to
parse the SDP.  Then, when it receives Jingle XML, it has to serialize SDP.
  That parsing and serializing of SDP I call "munging".  We could come up
with better words for more specific activities, but that seems to be the
word everyone else uses, so it's what I've used.

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 07:51:12 -0700

> translations with API points.

Are you trying to say "API points couldn't cover uses cases where different
dialects of SDP go over the wire"?  Because I would have to disagree with
that.  I think we could very easily support such uses cases with rather
minor changes to the API.  In fact, the proposal I made for adding just 3
methods (the NoPlan JS API) allows for either Plan A or Plan B (or even
Jingle, mostly), which would make things a lot easier for such use cases.

Now, my design might not be the optimal.  Perhaps we could do better.  But
I think it is possible to serve all these uses cases with a pleasant API.

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 8 Jul 2013 16:54:04 +0200 (CEST)

On Mon, 8 Jul 2013, Peter Thatcher wrote:
> >     > So compatibility with SIP is important but compatibility with
> >     Jingle is just impossible.
> >
> >     The mapping of SDP to jingle is in the Jingle specs ? I'm not
> I mean that if the JS wants to send Jingle XML over the wire, it has to parse the SDP.  Then, when it receives Jingle XML, it has to serialize SDP.   That parsing and serializing of SDP I call "munging".  We could come up with better words for more specific
> activities, but that seems to be the word everyone else uses, so it's what I've used.

I think "mangle" is a better term here. People who want to do jingle are 
aware of the fact that this is more difficult than running their own 
proprietary stuff over xml. Or use SoX :-)

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 07:54:32 -0700

On Wed, Jul 3, 2013 at 11:35 PM, Philipp Hancke
<[email-masked]>wrote:

>> (see: http://xmpp.org/**extensions/xep-0167.html<http://xmpp.org/extensions/xep-0167.html>
>> ).
>>
>
> Things like the content-add/content-remove are harder because the API user
> is required to calculate an SDP delta/diff. The appendix A.1.3 of the JSEP
> draft calls this createContentAdd, parseContentAdd, createContentAccept and
> parseContentAccept. Has anyone ever implemented those operations in
> javascript and can demonstrate running code?
>

I think those were added about a week ago.  Both Chrome and Firefox try to
update quickly, but that would be amazing!

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 07:56:13 -0700

I'm fine with "mangle".

On Mon, Jul 8, 2013 at 7:54 AM, Philipp Hancke <[email-masked]>wrote:

>> with better words for more specific

---

From: Jim Barnett <[email-masked]>
Date: Mon, 8 Jul 2013 15:02:24 +0000

I think that we need a separate verb to describe the case where the developer needs to modify the SDP itself (i.e., rather than translation it into or out of another language).  Those are different use cases, and different sorts of problems.

-          Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: Monday, July 08, 2013 10:56 AM
To: Philipp Hancke
Cc: <[email-masked]>
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

I'm fine with "mangle".

On Mon, Jul 8, 2013 at 7:54 AM, Philipp Hancke <[email-masked]<mailto:[email-masked]>> wrote:

I think "mangle" is a better term here. People who want to do jingle are aware of the fact that this is more difficult than running their own proprietary stuff over xml. Or use SoX :-)

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Jul 2013 11:22:38 -0400

> [1] http://lists.w3.org/Archives/Public/public-webrtc/2012Nov/0072.html
I would not disagree that there should not be any debate that things that
can be done through API should be done through API. My question is, was
there ever consensus that SDP should be a opaque non modifiable blob which
should not be used within the application to control things. Or is SDP just
a more advanced API surface that is supposed to be used to implement more
advanced scenarios? Is this group even suppose to specify what can be
modified in by the application SDP or is it supposed to be an empty set?
So, was there ever a consensus that "developers MUST NOT touch SDP"?

_____________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 8 Jul 2013 08:26:15 -0700

Whoops, nevermind.  It's been there since
http://tools.ietf.org/html/draft-uberti-rtcweb-jsep-00, and it's not what I
thought it was at first glance.  So forget what I said :).

On Mon, Jul 8, 2013 at 7:54 AM, Peter Thatcher <[email-masked]> wrote:

>
>
>
> On Wed, Jul 3, 2013 at 11:35 PM, Philipp Hancke <[email-masked]
> > wrote:
>

---

From: Jim Barnett <[email-masked]>
Date: Mon, 8 Jul 2013 15:29:55 +0000

As I recall the consensus, developers are supposed to be able to modify the SDP, but we needed to specify what parts of the SDP could be modified.  In other words, there might be some limits to what could be modified, but we haven't yet determined/agreed on what they are.

-          Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Monday, July 08, 2013 11:23 AM
To: Stefan Håkansson LK
Cc: <[email-masked]>
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

On Mon, Jul 8, 2013 at 8:11 AM, Stefan Håkansson LK <[email-masked]<mailto:[email-masked]>> wrote:
> <[email-masked]<mailto:[email-masked]>
> <mailto:[email-masked]<mailto:[email-masked]>>> wrote:
>

I would not disagree that there should not be any debate that things that can be done through API should be done through API. My question is, was there ever consensus that SDP should be a opaque non modifiable blob which should not be used within the application to control things. Or is SDP just a more advanced API surface that is supposed to be used to implement more advanced scenarios? Is this group even suppose to specify what can be modified in by the application SDP or is it supposed to be an empty set? So, was there ever a consensus that "developers MUST NOT touch SDP"?

_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Jul 2013 11:37:40 -0400

On Mon, Jul 8, 2013 at 11:29 AM, Jim Barnett <[email-masked]>wrote:

>  As I recall the consensus, developers are supposed to be able to modify
> the SDP, but we needed to specify what parts of the SDP could be modified.
>  In other words, there might be some limits to what could be modified, but
> we haven’t yet determined/agreed on what they are.****
>
>
>
This is exactly what I thought.
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Jul 2013 09:18:07 -0700

Y

On Mon, Jul 8, 2013 at 8:37 AM, Roman Shpount <[email-masked]> wrote:

> Yes, this matches my understanding as well. However, I believe there was
also
general agreement that most things one would want to do should be
doable without modifying SDP.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Jul 2013 12:32:25 -0400

> doable without modifying SDP.

"Should be doable" being the operative word. We are not there yet. We need
both new API types (like capabilites) and more settings for existing API
methods(more constraints).This also means either a lot of API extensions in
the future (with new API extension for each new SDP based feature) or
always having SDP as a fallback API surface.  If this is done right we can
just keep constraints and get rid of SDP altogether.

______________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Jul 2013 09:41:17 -0700

On Mon, Jul 8, 2013 at 9:32 AM, Roman Shpount <[email-masked]> wrote:

> methods(more constraints).
>

Yes, I agree with that. What would be useful would be for people to
make a list of these use cases and the extensions which would
enable them.

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Mon, 8 Jul 2013 13:02:11 -0400

On Mon, Jul 8, 2013 at 12:41 PM, Eric Rescorla <[email-masked]> wrote:

>
> What would be useful would be for people to
This would be ability to modify all the information present in SDP. So the
rule of thumb should be that if you can remove SDP from the API call, then
you have done it right.

For me personally I would like to see:
1. Specify codec list including relative priorities, framerate, number of
channels, and per codec parameters (like useinbandfec for OPUS).
2. Specify ptimes and maxptime per media stream and per codec
3. Specify bandwidth per media stream
4. If we support SDES SRTP, specify encryption profiles
_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Jul 2013 19:06:52 +0200

> to modify the SDP instead (I have no clue why, but anyway) they can

This sounds to me like "SDP will be here forever because it was talked
about two years ago, but let us improve it by adding some more API
methods so there is no need to parse/mangle it".

Just to clarify:

- Some of us don't want a better API for the currently proposed SDP-based spec.

- SDP must be parsed/mangled anyway if you want a JS WebRTC app that
talks Jingle XEP 0167, so there is no "API improvement" that would
avoid such a pain.

- It's not just SDP but also the mandate of SDP O/A. What I think is
that it is not well understood that SDP O/A is an artificial constrain
introduced in WebRTC just because SIP phones do that ***at application
level*** (so you are mandating that *any* WebRTC application in the
future must play like-SIP rules and SDP O/A model, which is insane). A
better and more complete API for the current spec DOES NOT avoid this
artificial limitation.

In short: some of us DO NOT want a better JS API for the current
opaque-unmanageable-SDP-blob based "API". Period. We strongly consider
it can be done really better by throwing out SDP and SDP O/A and by
providing a *real* JS Objects based API.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Jul 2013 19:15:03 +0200

2013/7/8 Jim Barnett <[email-masked]>:
> As I recall the consensus, developers are supposed to be able to modify the
> SDP, but we needed to specify what parts of the SDP could be modified.  In
> other words, there might be some limits to what could be modified, but we
> haven’t yet determined/agreed on what they are.

At this rate, wasting so long time on extending SDP to fullfil WebRTC
requirements, it would be done within the next 3-4 years. SDP is the
main issue delaying WebRTC 1.0.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 8 Jul 2013 20:34:06 +0000

On 7/8/13 4:38 PM, Peter Thatcher wrote:
>
>
>
> On Mon, Jul 8, 2013 at 5:11 AM, Stefan Håkansson LK
>     <mailto:[email-masked]>
>      > <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>      >
>      >      >     modify the SDP but rather there should be API points
>     to cover
>      >     most
>      >      > I thought it was, but I'm not the chair, so maybe you
>     could ask
>      >     Harald or
>      >      > Stefan.
>      >
> No objections at all?  That is rather surprising to me.  I asked for
> some feedback the API in the spreadsheet from web developers, at there
> many objections from them about this part of the API.  A majority did
> say it was good enough for simple use cases, but he objections were
> still clearly non-zero.

I think we're discussing different things. I'm referring to adding API 
methods that would allow meeting most use-cases without SDP mangling - 
under the presumption that SDP O/A would be used as part of the design. 
And that is what we have been assuming, and the WebRTC WG confirmed this 
last year when it was up for discussion.

What I see being most discussed now is the role of SDP O/A - not that it 
would not be helpful to have API methods that allowed meeting use-cases 
without SDP mangling if SDP O/A stays.

>
> I think perhaps the web developers are not well represented at TPAC.
>   But I could be wrong.  Perhaps they are but changed their mind.  Or
> maybe they're objecting on the IETF mailing list when they should object
> on the IETF mailing list.   Or maybe the spreadsheet has a sample bias,
> while TPAC is the true sample.   I don't know, but it seems like
> something is going on, and I'd like to know what it is.
>
> Stefan, what do you think?  What could explain the apparent
> contradiction between objections on the mailing list vs. no objections f2f?

Again, I think that we are to some extent discussing different things 
(see above).

But I can only speculate. There is not a 100% overlap between people who 
have raised concerns on the rtcweb list and the people usually active in 
the W3C WebRTC WG, this can be a reason.

> them on the W3C mailing list instead of the IETF one?  Is everyone
> barking up the wrong tree?

I think API proposals should be taken to the W3C list.

> My personal experience for #1 is that there are some notable people in
> the WG who are very much against making additions to the API to avoid
> SDP munging.  Some of them are rather upset with me for proposing a few
> minor additions to the API (the NoPlan JS API) precisely because it
> allows the JS to go around the SDP in many cases, and they don't like
> that.  So, from my experience, it's clear that the answer to #1 is "yes,
> many do".

Just to be clear, what I meant in my comment was APIs that made the 
browser create an SDP that is suitable for the use-case at hand, not an 
API to go around SDP.

> any additions or changes that would allow JS to avoid using SDP.

I must admit I am personally also a bit afraid of WG progress if we 
change too much. If your proposed API addition would be "too much" is 
another question.

> Also,
> I think they don't want to ways of doing things, so SDP must remain the
> one true way.
>
>
> Well, no one is going to hit themselves in the head with a hammer if
> they don't have to, but there are many uses cases that currently be done
> only by SDP munging, and I don't see any API additions on the horizon
> that will help those uses cases.    So, until we can agree on some API
> additions that help SDP munging, many web developers are going to have
> to keep swinging that hammer, no matter how much it hurts.

I think I need to do some reading up because the info must all be there 
among all the mails, but it would really be helpful to have a list of 
things people would like to do, and that currently require SDP mangling.

>     [email-masked] <mailto:[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 8 Jul 2013 20:37:01 +0000

> So, was there ever a consensus that "developers MUST NOT

No, developers are free to touch the SDP (and probably must in certain 
cases).

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 8 Jul 2013 22:43:26 +0200

> No, developers are free to touch the SDP (and probably must in certain

Do you feel how much painful is "touching a browser generated SDP"? To be clear:

- JS requests "A" to browser.
- Browser returns "A" (in the form of unmanageable blob).
- JS modifies "A" to send "A-bis" in the wire.
- Remote peer receives "A-bis" and replies "B-bis".
- Both JS app are lying to their respective  browsers to get the
desired behavior.

This is really painful, really.

In the other side, as I explained in other thread (may be in this
one?) adding some methods to the current API (to avoid playing with
the SDP) is not the way to go. A specification in which the JS app
does not know what he is sending in-the-wire (a blob generated by the
browser) is doomed to failure.

Please remember that mandating SDP (plain SDP) means that no other
media signaling protocol can be implemented in future WebRTC apps.

SIP phones have *fixed* code and *fixed* logic. This is no longer true
in the Web.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 9 Jul 2013 13:03:12 +1000

> between objections on the mailing list vs. no objections f2f?

I'm not Stefan, but I have a theory.

I think there are two groups objecting and there are two things to
object against.

Here's what I'm reading...

Web Developers really just want to be given functionality. They can
build their own nice API on top of what browsers implement (jquery did
a marvellous job of that). But they want functionality. Seeing as some
things are not currently possible with SDP and O/A, they either want
to extend those to allow their functionality, or - in particular where
SDP & O/A are overkill - want an option to get out of using SDP & O/A
and use something else.

Telco engineers want their existing devices to be interoperable with
browsers as well as the ability to develop new devices in the future
with extended functionality. So, on behalf of the first goal, they
object to including functionality into SDP that other devices don't
already support, and on behalf of the second goal, they are torn
between extending SDP & O/A and starting new.

As to why you haven't seen anyone object at the TPAC (did you really
mean TPAC, btw? The next TPAC meeting is only in November) - maybe
none of the people of these two groups were present at last year's
TPAC? Or they didn't understand the consequences yet.... Also, it's
easy to object on a mailing list, while in a meeting room, you'd have
to provide an alternative and it's really hard to come up with such an
alternative IMHO.

I certainly want a simple API, but I am not sure whether what we
currently have is already the simplest possible (given current
circumstances), nor am I sure whether it wouldn't just be possible to
build a simple one on top the jquery way, which would be sufficient
for now.

HTH,
Silvia.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Jul 2013 20:44:04 -0700

On 8 July 2013 20:03, Silvia Pfeiffer <[email-masked]> wrote:
> Or they didn't understand the consequences yet.... Also, it's

Hey Silvia,

We were there, in person, in Lyon, last November, but there were just
two of us.  We even had a viable alternative.

It's easy to dismiss two people.  Almost as easy, if not even easier,
to dismiss an absent mass.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 9 Jul 2013 13:49:37 +1000

> two of us.  We even had a viable alternative.

Right!

> to dismiss an absent mass.

Agreed. But I think things are different now that there is so much
more experience so maybe next TPAC will look different.

Cheers,
Silvia.

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 9 Jul 2013 07:40:29 +0000

> two of us.  We even had a viable alternative.

I want to be very clear and careful on what I say. So I am repeating:

* My comment that I think Eric is right in that there is consensus on 
providing APIs that allow most use-cases to be met without SDP mangling 
is meant only in that context: SDP O/A is kept (and PeerConnection more 
or less as is and so on).

I don't think Martin or anyone else objected to this in Lyon or at any 
other discussion.

It is also true that an alternative API proposal, CU-rtcweb, was brought 
forward to the WebRTC WG earlier during 2012. The WG took this under 
consideration, and (at that time) decided to continue developing based 
on the PeerConnection API including SDP O/A.

I think the discussion in Lyon only evolved around PeerConnection (wiht 
SDP O/A), we did not discuss other API alternatives.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 9 Jul 2013 12:09:17 +0200

> between extending SDP & O/A and starting new.

Hi Silvia,

Another important point is that many of those telco engineers have
clearly recognized that they don't know Web, nor JS, nor designing JS
APIs for the Web, and that they just want WebRTC to be compatible with
their current business (literally: "I want browsers to be compatible
with SIP").

For example, two years ago the initial proposal by many of those telco
engineers was "allow plain RTP and mandate SIP as in-the-wire protocol
for WebRTC" (this is true). I also remember that somebody proposed
that the browser should include a "call history" panel, which clearly
shows a limited and wrong WWW vision.

They strongly think that by mandating SDP O/A they are done and have
accomplished their job in this WG on behalf of their big companies
(those that have never succeeded in the WWW). And of course, they are
much more used to IETF processes than Web guys (is Facebook
represented in this WG?), thus the only argument they expose
*nowadays* is: "SDP mandate was talked about and agreed two years ago
in a meeting full of telco engineers".

And then, the current spec is basically an opaque and unmanageable SDP
blob generated by the browser that must be sent by the JS to the peer.
The same "logic" within a phone. But here is the problem: a web
application is all but **fixed** code and **fixed** logic. Don't kill
the Web.

> circumstances),

What we have now is not a real API.

> nor am I sure whether it wouldn't just be possible to

An API should be good enough to not require an extra layer on top of
it to make it feasible for developers.

As developer in JsSIP project I must say that we have properly
implemented SIP pure protocol on top of JS and WebSocket, no problems
at all (regardless how complex SIP becomes sometimes). The only real
problem we have if related to WebRTC "API". Tons of hours dealing with
unexpected/wrong specifications and behaviors (and yes, SDP blob
hackery). We would be very happy if we could generate our *own* SDP
with JS (which means we need to retrieve *real* JS Objects from the
WebRTC stack rather than an opaque SDP blob). And telcos, ey!!!, we
are doing SIP even much more than you !!! believe us !!!

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 9 Jul 2013 12:18:00 +0200

> or less as is and so on).

Hi Stefan,

You insist that "there is consensus on keeping SDP O/A but providing a
better API". Given current discussions IMHO it is clear there is not
such a consensus (not at all). Or may be you are just talking about
two years ago in some IETF meeting (if so I'm sorry).

Please review the results in
https://docs.google.com/a/aliax.net/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=1

  Bad for advanced stuff: 94%
  OK for 1.0: 40%

IMHO such a result indicates all but "let's keep SDP O/A and improve a
bit the API" (I mean now, in July 2013).

Best regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 9 Jul 2013 11:26:37 +0000

On 2013-07-09 12:18, Iñaki Baz Castillo wrote:
> better API".

I must be expressing myself quite badly, because the message seems not 
to get through.

* I think we have consensus on adding API that allows most use-cases to 
be met without SDP mangling (given that SDP O/A is kept naturally)

* We discussed last year an alternative API that did not use SDP at all 
(and did not use PeerConnection). The decision at that time was to 
continue developing the API based on PeerConnection and SDP O/A.

Have not stated anything more than that.

Stefan

> Given current discussions IMHO it is clear there is not

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 12 Jul 2013 10:31:57 -0700

> Have not stated anything more than that.

Thank you for clarifying, Stefan.  It's often very difficult for those of
us who weren't there to understand what was consensus, and what wasn't, and
what was decided and what was decided and what wasn't.  It seems that if
you ask 10 people, you get 10 different answers.

In other words, it's hard to see much consensus on what we have consensus
on.

So thank you for your clarifications.  It's probably not a very fun job for
you :).   Along with that, I have two more questions for you:

1.  You said we have consensus on adding API that allows most use-cases to
be met without SDP mangling.  Since that point in time has there been in
any progress in adding such APIs?  Can you give me a rough feel for how
much time has passed, how many proposals have been made, how many have been
accepted, and how many have been implemented?  I think it's great that
we'll do this "someday", but I'd like to get a feel for how far away
"someday" is.  Thanks in advance.

2.  You said we have consensus against an alternative API.  Was that
consensus against any additions to the API that would allow JS to bypass
SDP, or was that a consensus against just that particular alternative API?
 I'd like to get a feel for how many people voted for "no; let's not go
down that specific road" vs. "no; we cannot go on any road but this one".
I think there's a big difference between the two.  Thanks again in advance.

By the way, Ted asked us to move discussions about the API to
public-webrtc, so should we do that now?

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sat, 13 Jul 2013 18:40:23 +0000

On 7/12/13 7:32 PM, Peter Thatcher wrote:
>
>
>
> On Tue, Jul 9, 2013 at 4:26 AM, Stefan Håkansson LK
>      > 2013/7/9 Stefan Håkansson LK <[email-masked]
>     <mailto:[email-masked]>>:
> Thank you for clarifying, Stefan.  It's often very difficult for those
> of us who weren't there to understand what was consensus, and what
> wasn't, and what was decided and what was decided and what wasn't.  It
> seems that if you ask 10 people, you get 10 different answers.
>
>
> In other words, it's hard to see much consensus on what we have
> consensus on.
>
>
> So thank you for your clarifications.  It's probably not a very fun job
> for you :).   Along with that, I have two more questions for you:
>
>
> 1.  You said we have consensus on adding API that allows most use-cases
> to be met without SDP mangling.  Since that point in time has there been
> in any progress in adding such APIs?  Can you give me a rough feel for
> how much time has passed, how many proposals have been made, how many
> have been accepted, and how many have been implemented?  I think it's
> great that we'll do this "someday", but I'd like to get a feel for how
> far away "someday" is.  Thanks in advance.
>
> SDP, or was that a consensus against just that particular alternative
> API?  I'd like to get a feel for how many people voted for "no; let's
> not go down that specific road" vs. "no; we cannot go on any road but
> this one".   I think there's a big difference between the two.  Thanks
> again in advance.
>
>

Yes. I will respond there (probably tomorrow).

>      > <[email-masked] <mailto:[email-masked]>>
>      >
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 16 Jul 2013 13:42:58 +0000

> This is really painful, really.

I've been doing:

- JS requests "A" to browser.
- Browser returns "A" (in the form of unmanageable blob).
- JS modifies "A" to send "A-bis" in the wire to a system not 
understanding "A" as is
- Remote end receives "A-bis" and replies "B-bis".
- JS modifies "B-bis" (using parts of "A" in the process) and applies 
"B" to browser

Not nice and clean for sure, but quite doable. JS is nice for text parsing.

But the big problems I experienced were:
* "A" was different between different browsers (in a way that the JS had 
to be different)
* "A" would change in ways breaking my code between versions
* What would accepted for "B" would also vary.

Most of this would presumable go away once we settle on exactly how SDP 
should be used (assuming SDP stays).

But all that said, I still think we need API surface that makes the need 
to mangle the SDP an exception (OTOH, perhaps interop with legacy - as I 
did - is an exception? Depends on where you come from I guess.).

> media signaling protocol can be implemented in future WebRTC apps.

I think Peter Thatcher had an idea of an API extension where you could 
do away with SDP if you want to.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Jul 2013 17:15:40 -0700

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. And creating APIs to avoid mangling isn't actually that much simpler. What knobs do you provide and which ones do you ignore? Browsers might not agree on those either.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Wed, 17 Jul 2013 10:26:45 +1000

The whole point of standardisation at the W3C is for browser to agree
on the knobs. So, I do think it's a valuable effort.
Cheers,
Silvia.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Jul 2013 17:30:28 -0700

I would agree. Just pointing out that this issue was raised in December 2012, and it is now 6+ months later with little progress and more disgruntlement. So if there is motivation to fix this it probably would have manifested itself by now.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 17 Jul 2013 21:58:37 +0000

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?
- Change the rtpmap associations before calling setLocal?
- Change a=sendrecv to a=recvonly before calling setLocal?
- What do you do when you see a=content:sl ?
- What if someone adds an r= or p= or e=?
- What is the RFC that describes a=group:BUNDLE (as seen in some browser implementations)?
- Can I remove a=group:BUNDLE (or add it) before calling setLocal?
- How about removing a=rtcp-mux?
- Should I do something special at my end if you set a=ice-options:google-ice ?
- If you put a=ssrc lines in there, can I change the ssrc before passing it back to setLocal?
- Can I delete the a=ssrc lines?
- Is a=rtcp:1 IN IP4 0.0.0.0 valid or not?
- What about 0.0.0.0 in the o= line?
- If I get a bunch of a=candidate lines, can I swap them around to change the priority before calling setLocal?
- What if someone claims SAVP instead of SAVPF but gives me rtcp info?
	
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.

Matthew Kaufman

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Jul 2013 06:47:30 +0200

Matthew, thanks for sending 12 messages in 3 hours to the mailing list.

Just one point on which I corrected you before, but since I see you're
repeating it:

> - What if someone adds an r= or p= or e=?

The code for handling an e= line has been in Chrome since a very early
release.
You claimed in Lyon that you'd tested it and failed to have it parse,
but I never saw the test case; you may have inserted it into the wrong
place, rendering the SDP invalid.

The SDP specification is quite strict about the order of these fields,
exactly to make it simpler to write parsers.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Jul 2013 10:23:08 +0200

Since Matthew was taking about API, this belongs on public-webrtc, not 
rtcweb. Please ignore.

           Harald

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 18 Jul 2013 08:01:22 -0700

> Matthew, thanks for sending 12 messages in 3 hours to the mailing list.
Given how many active threads and subthreads are going on at once, 12
messages doesn't seem like that many.  I've lost track of how many
centithreads there are now.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 18 Jul 2013 15:06:46 +0000

By waiting, I reduced what would have been 30 or 40 messages to "only" 12. Just pretend that I spaced them out over the course of the discussion and be happy.

Matthew Kaufman

________________________________
From: [email-masked] [[email-masked]] on behalf of Peter Thatcher [[email-masked]]
Sent: Thursday, July 18, 2013 8:01 AM
To: Harald Alvestrand
Cc: <[email-masked]>
Subject: Re: [rtcweb] e= lines (Re: Summary of Application Developers' opinions ..)

On Wed, Jul 17, 2013 at 9:47 PM, Harald Alvestrand <[email-masked]<mailto:[email-masked]>> wrote:
Matthew, thanks for sending 12 messages in 3 hours to the mailing list.

Given how many active threads and subthreads are going on at once, 12 messages doesn't seem like that many.  I've lost track of how many centithreads there are now.

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 18 Jul 2013 08:12:04 -0700

On Wed, Jul 17, 2013 at 2:58 PM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

> 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.
>

I believe I began paying attention to the mailing lists after you sent out
theses slides that you didn't present.  I'm interested in seeing them, and
while I could dig through archives to find them, if convenient, could you
please give me a link to the slides?  Thanks.

> 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.
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Jul 2013 09:53:47 -0700

> please give me a link to the slides?  Thanks.

It wasn't actually November, it was October, which made this harder to
find than I had expected.

http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/0148.html

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 18 Jul 2013 22:40:14 +0000

Thanks for digging this up... in the meantime of course there's been work ongoing in the MMUSIC IETF WG that adds even more questions than it answers. See messages from as recent as today about msid, bundle, "unified plan", etc. (All useful work that is needed for other types of SDP-using applications, like SIP-based videoconferencing systems, but work that will take some time and which as long as we stick with SDP as an API will be holding up the WEBRTC specification)

As long as it is allowed for the SDP to be modified between createOffer and setLocalDescription, there must be a W3C specification instructing browser vendors as to what changes are and are not allowed. That is *in addition* to knowing what SDP should be accepted (and what it means) when it comes from the other side. And the more "special" stuff ends up in SDP as a result of this WEBRTC-driven MMUSIC work, the longer it will be before such a specification can possibly be complete. (And note that it isn't sufficient to just wait for the MMUSIC work to be done and point to it... it will still be necessary to *write down what the browser must do* in a the W3C specification.)

Or, as I've pointed out before, we could define a browser API that is entirely independent of SDP, and allow enough control that JavaScript programmers can arrange objects and set their parameters such that useful SRTP media streams can be sent and received, and then they can write whatever JavaScript they want to create the SDP that is getting defined over in MMUSIC and other places, or not use those specs if they so desire.

Matthew Kaufman

________________________________________
From: Martin Thomson [[email-masked]]
Sent: Thursday, July 18, 2013 9:53 AM
To: Peter Thatcher
Cc: Matthew Kaufman (SKYPE); <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

---

From: Silvia Pfeiffer <[email-masked]>
Date: Fri, 19 Jul 2013 10:46:48 +1000

> http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/0148.html

This captures exactly the kind of questions and concerns I had. Excellent work!

However, I don't fully agree with the conclusion of the slide deck.
I'd prefer we extended the constraints and other browser APIs that set
the SDP parameters rather than (or: in preference to) fully specifying
what SDP the browser has to support. I do like the ability to get the
low-level access to mangle the SDP as a means of experimenting with
new functionality or as a means to try and connect to devices that
don't have a WebRTC API. But I see the full definition of the SDP
parameters that browsers have to support as less important and
potentially just a by product of creating the higher level APIs.

What does it take for us to get focused on defining such an API that
is independent of SDP for the JS developer, and for now requires
browsers to do the mapping to SDP for them? Is the extension of the
constraints that a JS dev can manipulate enough for this?

Silvia.

---

From: Justin Uberti <[email-masked]>
Date: Thu, 18 Jul 2013 22:40:20 -0400

Well, for the past 6+ months we haven't been able to agree on exactly how a
MediaStreamTrack should be represented in SDP, so it would have been
premature to try to write this stuff down.

That said, I agree this stuff needs to be fully defined, so that
applications can get predictable behavior. I also agree it will be a large
undertaking.

On Tue, Jul 16, 2013 at 8:30 PM, Bernard Aboba <[email-masked]>wrote:

> I would agree. Just pointing out that this issue was raised in December
> 2012, and it is now 6+ months later with little progress and more
> disgruntlement. So if there is motivation to fix this it probably would
> have manifested itself by now.
>
> support. Given all the SDP specs that is actually a huge work item. And
> creating APIs to avoid mangling isn't actually that much simpler. What
> knobs do you provide and which ones do you ignore? Browsers might not agree
> on those either.
> >>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Fri, 19 Jul 2013 10:32:09 +0000

On 7/19/13 12:40 AM, Matthew Kaufman (SKYPE) wrote:
> Thanks for digging this up... in the meantime of course there's been
> work ongoing in the MMUSIC IETF WG that adds even more questions than
> it answers. See messages from as recent as today about msid, bundle,
> "unified plan", etc. (All useful work that is needed for other types
> of SDP-using applications, like SIP-based videoconferencing systems,
> but work that will take some time and which as long as we stick with
> SDP as an API will be holding up the WEBRTC specification)
>
> As long as it is allowed for the SDP to be modified between
> createOffer and setLocalDescription, there must be a W3C
> specification instructing browser vendors as to what changes are and
> are not allowed.

Perhaps we should, at least initially, consider Martin's proposal: 
modifications are not allowed between createX and setLocal.

>
> Or, as I've pointed out before, we could define a browser API that is
> entirely independent of SDP, and allow enough control that JavaScript
> programmers can arrange objects and set their parameters such that
> useful SRTP media streams can be sent and received, and then they can
> write whatever JavaScript they want to create the SDP that is getting
> defined over in MMUSIC and other places, or not use those specs if
> they so desire.
>
> Matthew Kaufman
>
> ________________________________________ From: Martin Thomson
> [[email-masked]] Sent: Thursday, July 18, 2013 9:53 AM To:
> Peter Thatcher Cc: Matthew Kaufman (SKYPE); <[email-masked]>;
> [email-masked] Subject: Re: [rtcweb] Summary of Application
> Developers' opinions of the current WebRTC API and SDP as a control
> surface
>
>> I believe I began paying attention to the mailing lists after you
>> sent out theses slides that you didn't present.  I'm interested in
>> seeing them, and while I could dig through archives to find them,
>> if convenient, could you please give me a link to the slides?
>> Thanks.
>
> It wasn't actually November, it was October, which made this harder
> to find than I had expected.
>
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 06:56:52 -0700

Please tell us the use case you have that requires this and it will make it easier to figure out how to solve the pain.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 07:00:24 -0700

Can someone please email a full copy of the spreadsheet to the list so it is in the archives - thanks

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 07:04:01 -0700

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

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 19 Jul 2013 14:33:20 +0000

You say... "But I see the full definition of the SDP
parameters that browsers have to support as less important and
potentially just a by product of creating the higher level APIs."

But I'm afraid that as a browser vendor, I will need exactly such a specification in order to create an interoperable browser without looking at the other browser vendors' source code.... so even if your conclusion is correct, we can't avoid this step unless we also abandon SDP as one of the API surfaces.

Matthew Kaufman

________________________________________
From: [email-masked] [[email-masked]] on behalf of Silvia Pfeiffer [[email-masked]]
Sent: Thursday, July 18, 2013 5:46 PM
To: Martin Thomson
Cc: <[email-masked]>; [email-masked]
Subject: Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface

Silvia.

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 07:49:50 -0700

"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 <[email-masked]> 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
>
> > - If I get a bunch of a=candidate lines, can I swap them around to
> change the priority before calling setLocal?
> > - If not, how are violation handled? (Both when passed to another
> browser at the far end and when these modifications happen before calling
> setLocal)

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 07:51:34 -0700

Here you go:

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 19 Jul 2013 17:03:37 +0200

2013/7/19 Cullen Jennings <[email-masked]>:
> Folks wanted to sort out how mindless works fist before getting to theses smaller details

Hi Cullen,

All these "smaller details" are in fact issues and problems we don't
need. Issues not needed at all in WebRTC, issues that WebRTC
developers and vendors should NOT care about. If those "smaller
details" do exist is due the mandate of SDP. And all the time the WG
(or WGs) will spent "fixing/defining" them is just wasted time, since
nothing useful is being done for WebRTC by "defining" those "minor
details".

Regards.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 11:37:47 -0500

> nothing useful is being done for WebRTC by "defining" those "minor

I think this is a hopelessly naïve interpretation of the facts on the 
ground. Simply discarding SDP doesn't magically make the underlying 
issues go away. We would still need to settle a vast number of issues 
around things like simulcast, FEC, codec parameters, indication of 
supported codecs, correlation of RTP streams with MediaStreamTracks, 
attempts by both parties to operate on the same stream simultaneously 
[1], etc. Basically, with very rare exception, the same set of problems 
that we need to solve if we *don't* throw SDP out the window.

I understand the temptation to think that starting over makes all the 
problems go away. There's a mental trap in thinking that all you really 
need is to announce ports and codecs and get on with it. But then this 
person over here really needs simulcast. And that person over there 
insists that RTCP NACK feedback is critical for his application. And 
then I need to be able to tell you that your 1280x720 video stream is 
going to overwhelm my limited ability to decode and that you really need 
to turn it down to QCIF. And, before you know it, you've reinvented 
something approximately as complex as SDP that everyone is just going to 
shove into a JSON blob and send across the wire. As an added bonus, by 
deciding that legacy interop is of no value, you've limited the utility 
of the overall system by setting Metcalfe's law on fire and throwing it 
over the railing of the third-floor balcony.

Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not hard. 
Your pain point isn't offer/answer. Two unilaterally declared sessions 
that are simply blasted out onto the wire only satisfies the simplest of 
use cases; you need a negotiation, and any attempt to define how that 
negotiation looks is going to arrive at something with enough rules that 
it is substantially as complicated as offer/answer.

No, your pain point here is that non-master-slave networked 
communications are not easy to get right, and it is the height of hubris 
to think that you inherently know better than everyone else who has 
worked in this space before you. Consider that TCP has far fewer moving 
parts than even a simple one-stream-audio-only call setup and took 85 
pages to specify.

I understand comment 22 at its core [2], but it has a corollary: any 
system that replaces SDP O/A will end up being similar in complexity 
once all interested parties' use cases have been factored in.

/a

____
[1] What we call "glare" in telecom and SIP, but a phenomenon that 
arises whenever you have connections made between peers without a 
master/slave arrangement; see RFC 793, page 32, for example.

[2] For the uninitiated, "comment 22" was a shorthand developed at last 
year's TPAC for the sentiment "SDP offer/answer is hard".

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jul 2013 09:54:12 -0700

> year's TPAC for the sentiment "SDP offer/answer is hard".

No quite, it's shorthand for "there is a proposal that has been
submitted in which the problem in question does not need to be
solved", with one of two options: "either the problem has been
solved", or "the problem simply does not need to be solved (by us,
with a standard)".

I reject your thesis for one simple reason: scope.

As it turns out, "does not need to be solved" doesn't go to 100%.
Some problems are deferred to applications.  Intentionally.  Because
a) they are better at that than we are, clearly, and b) they don't
necessarily want our crappy solutions.

How long have we talked about BUNDLE?  How long do you think that it
would take someone with a functioning RTP library to build something
that multiplexes and demultiplexes RTP streams?

Negotiation is a hole.  A vast, soul-sucking, waste of time.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 19 Jul 2013 10:07:12 -0700

> Negotiation is a hole.  A vast, soul-sucking, waste of time.
Even if you have the same javascript application downloaded, you will have
disparate capabilities in the environments into which it is downloaded
(browser/os/codecs/media sources/available network capacity).  Getting set
intersection and preference order for those capabilities is something that
applications actually want.  You may be able to move the pain of that
around, but it isn't a waste of time.

My personal opinion, with no IETF hats or company swag,

Ted

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 12:09:32 -0500

> that multiplexes and demultiplexes RTP streams?

Are you proposing that Firefox come up with its own multiplexing 
mechanism for RTP; Chrome its own; Opera, yet a third; IE, a fourth; and 
Safari, a fifth?  And then we just kind of pray that five proprietary 
solutions developed in a vacuum miraculously work together? I mean, 
yeah, if we can rely on miracle interop for independently-developed 
proprietary solutions, I guess that works.

Or are you envisioning a WebRTC API that requires javascript 
applications to supply their own RTP stacks?

/a

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 10:18:09 -0700

On Fri, Jul 19, 2013 at 9:37 AM, Adam Roach <[email-masked]> wrote:

> ground. Simply discarding SDP doesn't magically make the underlying issues
> go away. We would still need to settle a vast number of issues around
> things like simulcast, FEC, codec parameters, indication of supported
> codecs, correlation of RTP streams with MediaStreamTracks, attempts by both
> parties to operate on the same stream simultaneously [1], etc. Basically,
> with very rare exception, the same set of problems that we need to solve if
> we *don't* throw SDP out the window.
>

It's interesting that most or your list of things that needed to be solved
without SDP (simulcast, FEC, correlation of RTP streams with
MediaStreamTracks, glare) still haven't been solved for WebRTC even with
SDP, despite many months (years?) of effort.

I don't think anyone is saying "without SDP, there would be issues".  I
think they're saying "without SDP, the issues are much easier/faster to
solve, and the API would be much more usable and implementable".   And I
don't think that's a naive opinion.

> person over here really needs simulcast. And that person over there insists
> that RTCP NACK feedback is critical for his application. And then I need to
> be able to tell you that your 1280x720 video stream is going to overwhelm
> my limited ability to decode and that you really need to turn it down to
> QCIF.  And, before you know it, you've reinvented something approximately
> as complex as SDP

I think you are conflating signalling with API surface.  If we focus on
making a good API rather than on signalling, we can make something much
more simple and leave signalling up to the application.

> that everyone is just going to shove into a JSON blob and send across the
> wire.  As an added bonus, by deciding that legacy interop is of no value,
> you've limited the utility of the overall system by setting Metcalfe's law
> on fire and throwing it over the railing of the third-floor balcony.

Again, you are conflating API surface and signalling.  An API that doesn't
have SDP in it doesn't preclude web apps from using SDP for signalling.
 There's no loss here for those app that choose to use SDP.  There is only
gain for web developers chooses not to use SDP for the signalling in their
web application.  And if they choose not to use SDP and use JSON instead,
why are you so opposed?  There is a world outside of legacy interop, you
know.

> Your pain point isn't SDP syntax. Yeah, it's ugly, but it's not hard. Your
> pain point isn't offer/answer. Two unilaterally declared sessions that are
> simply blasted out onto the wire only satisfies the simplest of use cases;
> you need a negotiation, and any attempt to define how that negotiation
> looks is going to arrive at something with enough rules that it is
> substantially as complicated as offer/answer.
>

You are underestimating how painful it is to deal with the current API,
both because you are very familiar with it (with many years of experience)
and because the use cases you care about are the ones the API was defined
for (legacy interop).  But as soon as you ask someone who is not familiar
with SDP (a lot of web devleopers), or someone who is doing more advanced
or different things than what you have thought of, they will give you a
different answer.   They feel pain, and it is because of the poor API
surface.

>
> No, your pain point here is that non-master-slave networked communications
> are not easy to get right, and it is the height of hubris to think that you
> inherently know better than everyone else who has worked in this space
> before you. Consider that TCP has far fewer moving parts than even a simple
> one-stream-audio-only call setup and took 85 pages to specify.
>

Please try to consider what you sound like to a web developer who is trying
to use WebRTC and finding SDP to be difficult API surface.  Maybe I'm
wrong, but I'm guessing what you're saying will sound like.  "my use case
(legacy interop) is the most important and my solution (SDP) is the best
solution for everyone and I know better because I've been working on it for
longer".  Hubris?

> system that replaces SDP O/A will end up being similar in complexity once
> all interested parties' use cases have been factored in.
>

There is a vast difference that you are not taking into account.  The SDP
O/A, if in JS, is a complexity cost only paid by those web applications
that need it.  But if baked into the API, every app must pay the cost of
the complexity.

In general, this emails seems to be arguing that  SDP is the optimal API
surface for expressing all these complex things, and  yet in other
occasions, I've heard you admit it's a terrible API surface.  So does that
mean the optimal API surface is terrible?  I don't think so.  It will be
work, but I think the work will be worth it in the end.

That said, the chairs have asked us to delay discussing a better API, so
we'll have to wait before we can discuss details of how an API could be
done without SDP.

>
> /a
>
> ____
> [1] What we call "glare" in telecom and SIP, but a phenomenon that arises
> whenever you have connections made between peers without a master/slave
> arrangement; see RFC 793, page 32, for example.
>

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jul 2013 10:20:15 -0700

> around, but it isn't a waste of time.

There's a vast difference between "it needs to be done" and "we need
to define a standard for it".

I have nothing against providing tools that make it easier, but it's a
real leap of logic to conclude that the one and only mechanism for
interaction *requires* negotiation and that SDP O/A is *the*
negotiation method.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jul 2013 10:23:05 -0700

On 19 July 2013 10:09, Adam Roach <[email-masked]> wrote:
> Are you proposing that Firefox come up with its own multiplexing mechanism
> for RTP; Chrome its own; Opera, yet a third; IE, a fourth; and Safari, a
> fifth?  And then we just kind of pray that five proprietary solutions
> developed in a vacuum miraculously work together? I mean, yeah, if we can
> rely on miracle interop for independently-developed proprietary solutions, I
> guess that works.

I'm saying nothing of the sort.  We definitely need to define what
multiplexing looks like when it happens, but there's a vast gulf
between that and defining how to negotiate it.  Discussions on RTP
shims or SSRC mux did consume some time, but I believe them to be
done.  For quite a while now.

The negotiation part looks like it's nearing completion, but only
after a fairly significant amount of wrangling and pain.

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 10:23:59 -0700

On Fri, Jul 19, 2013 at 10:09 AM, Adam Roach <[email-masked]> wrote:

> rely on miracle interop for independently-developed proprietary solutions,
> I guess that works.
>
>
Again, you are conflating signalling and API surface.  We could define a
simple API that leaves the control up the application, and different
applications can signal different multiplexing techniques in different
ways.

> Or are you envisioning a WebRTC API that requires javascript applications
> to supply their own RTP stacks?

SDP != RTP.   It is possible to have an RTP stack without an SDP stack.
 You realize this, right?

>
>
> /a
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 12:25:11 -0500

On 7/19/13 12:07, Ted Hardie wrote:
> On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
> Even if you have the same javascript application downloaded, you will 
> have disparate capabilities in the environments into which it is 
> downloaded (browser/os/codecs/media sources/available network 
> capacity).  Getting set intersection and preference order for those 
> capabilities is something that applications actually want. You may be 
> able to move the pain of that around, but it isn't a waste of time.

I can't +1 this hard enough. I certainly don't want every javascript 
application that makes use of the WebRTC API to independently discover 
that mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to 
unusable if you try to send it more than 320x200 video, and then try to 
solve that problem.

Again and again, for every permutation of phone and operating system 
version.

Yeah, someone has to do this kind of characterization, and some of it 
can be done real-time if you're interacting directly with the operating 
system. So... maybe we could add yet another API to WebRTC to allow 
applications to build this functionality themselves rather than counting 
on them characterizing the systems they care about and blowing up on the 
ones they don't.

But, honestly, any course of action that relegates this to the 
applications seems to have the dual properties of forcing it to be 
implemented hundreds of thousands of times while making the actual user 
experience worse.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 10:27:16 -0700

On Fri, Jul 19, 2013 at 10:25 AM, Adam Roach <[email-masked]> wrote:

> application that makes use of the WebRTC API to independently discover that
> mobile terminal Foocom A1 runnning MobileOS 3.1.7(a) bogs down to unusable
> if you try to send it more than 320x200 video, and then try to solve that
> problem.
>
> Yeah, someone has to do this kind of characterization, and some of it can
> be done real-time if you're interacting directly with the operating system.
> So... maybe we could add yet another API to WebRTC to allow applications to
> build this functionality themselves rather than counting on them
> characterizing the systems they care about and blowing up on the ones they
> don't.
>

Hundreds of thousands of times?

---

From: Roman Shpount <[email-masked]>
Date: Fri, 19 Jul 2013 13:29:30 -0400

> we *don't* throw SDP out the window.

I would argue that we are not as naïve as you think.

First of all, a lot of the issues you are talking about are not yet solved.
At the same time we have something already working and useful with current
browser implementation. So, what we want is to have these features released
as version 1.0. The problem that we face, that when you implement all the
above mentioned features, even though the API will stay the same, SDP that
it will produce will change, and that will require all, except the simplest
application, and all external components interfacing WebRTC clients to
change. And then when more features are implemented and more different
versions are in use more and more interop for applications and external
components will be required. What we want is an API that is not based on
blob with unpredictable data.

Second, offer/answer and SDP introduce a number of negotiation constraints
that really should not be there. They cause unrelated things to be
negotiated together. It should be possible to negotiate a data connection
and then add and remove media streams without renegotiating the underlying
data connection. To force selection of single codec you need to do two
offer/answer exchanges, which caused by no other reason then framework
limitations. Resolution of glare is restricted to offer back off.
Furthermore, even from the point of view of offer/answer the current API is
broken. It does not allow forking. It introduces a new PRANSWER which is
not a part of normal offer/answer specification. It does not allow change
send media parameters (ie change send codec or send codec parameters)
without doing an offer/answer exchange, which is not necessary with normal
offer/answer framework.

So, what we are proposing is to map exiting implemented browser
functionality to API and get rid of SDP. Ideally we should get rid of
offer/answer as well but if it is too much work we can leave with it for
version 1.0. This way we get predictable behavior based on predictable
input. If we miss some of the future capabilities and they would require
API modification to implement, we can deal with it in 2.0. In API, unlike
network protocols, predictability and testability counts more then ability
for future extension.
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 12:31:07 -0500

On 7/19/13 12:27, Peter Thatcher wrote:
>     implemented hundreds of thousands of times while making the actual
>     user experience worse.
>
>

How many web apps do you anticipate will use real time communications 
between now and the time that this work becomes obsolete?

It's not important to come to consensus on this number -- my key point 
here is that it's significantly more than the number of web browsers 
that will be developed in that time, and by several orders of magnitude.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 12:34:58 -0500

> First of all, a lot of the issues you are talking about are not yet 

That was my *point*.

/a

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jul 2013 10:37:20 -0700

>> First of all, a lot of the issues you are talking about are not yet

So what, the logical conclusion is to tell people that are working on
(or have proposed) solutions to go away because they don't fit with
your preconceptions about what a solution should look like?

---

From: Roman Shpount <[email-masked]>
Date: Fri, 19 Jul 2013 13:37:33 -0400

> implemented hundreds of thousands of times while making the actual user

You cannot be more wrong. Each application deals with predictable set of
scenarios (ones it produces) and interfaces with predictable set of non
webrtc devices. These external devices are under control of the application
developer. Application developer is responsible for interop with these
devices. What is needed is predictable media and signaling generated by
webrtc devices running the same application. With negotiation and SDP
backed into the webrtc device it is very hard to achieve. So, for me as
webrtc developer let me develop a negotiation scheme that works for me and
make sure it stay working regardless of the browser type or version. Right
now controlling webrtc application feels like driving the boat down the
river by tickling the captain.
_____________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 10:37:31 -0700

> between now and the time that this work becomes obsolete?

That's an excellent point.  Along with that, how many will only be using
the data channel?  And how many will be using something other than SDP for
signalling?  And how many will be doing lots of SDP munging?  And how many
libraries will be written to hide the ugliness of SDP?  Hundreds of
thousands?

> here is that it's significantly more than the number of web browsers that
> will be developed in that time, and by several orders of magnitude.
>

That's an excellent point.  If we spent a little bit of extra work making a
really good API, think of how many people will benefit.  It's several
orders of magnitude more than the number of web browser that will need to
do a little bit of extra work to implement a good API.

---

From: Roman Shpount <[email-masked]>
Date: Fri, 19 Jul 2013 13:38:50 -0400

>> First of all, a lot of the issues you are talking about are not yet
And my point is that each time you solve any of those issue you will break
all the applications working so far. Not a good API design.
_____________
Roman Shpount

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 10:39:43 -0700

>> First of all, a lot of the issues you are talking about are not yet
So, are you trying to say "Look how hard this is to do with SDP.  We're not
even done yet.  It will be even harder without SDP"?

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 12:49:53 -0500

On 7/19/13 12:18, Peter Thatcher wrote:
> Please try to consider what you sound like to a web developer who is 
> trying to use WebRTC and finding SDP to be difficult API surface.

I think any time someone says they've used the SDP directly as a control 
surface in a JavaScript application, it indicates a hole in the current 
WebRTC specification that we need to fix.

SDP is not supposed to be the WebRTC API surface.

I think we all pretty much agree that SDP is not supposed to be the 
WebRTC API surface.

I think we're pretty much all on the same page that we need to add stuff 
to the current API to handle these use cases.

> Maybe I'm wrong, but I'm guessing what you're saying will sound like. 
>  "my use case (legacy interop) is the most important and my solution 
> (SDP) is the best solution for everyone and I know better because I've 
> been working on it for longer".  Hubris?

No, you've misunderstood pretty much everything I said. I'll summarize 
in fewer words.

My point is that we need to solve these problems one way or another, and 
SDP isn't really the reason it's difficult.

But by incorrectly deciding that SDP (or offer/answer, depending on who 
you listen to) is the reason it's hard, we're trying to throw legacy 
interop out the window for very little gain. And, while not the only (or 
even main) consideration, legacy interop has significant value. It would 
be a shame to destroy that value based on a misconception.

These issues aren't hard because of SDP. These issues are hard because 
they're hard.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 12:51:02 -0500

On 7/19/13 12:39, Peter Thatcher wrote:
>
> So, are you trying to say "Look how hard this is to do with SDP. 
>  We're not even done yet.  It will be even harder without SDP"?
>

No. I'm not saying it would be harder. I'm saying it wouldn't be easier, 
and you would lose tangible benefits.

/a

---

From: Roman Shpount <[email-masked]>
Date: Fri, 19 Jul 2013 13:55:02 -0400

> These issues aren't hard because of SDP. These issues are hard because
I agree that those issues are hard but with SDP they are harder. SDP
requires to create solutions that are backwards compatible within a very
restrictive framework. API allows solutions that are backwards compatible
if they are coded specific way. This is a huge difference.
_____________
Roman Shpount

---

From: Martin Thomson <[email-masked]>
Date: Fri, 19 Jul 2013 10:57:54 -0700

> even done yet.  It will be even harder without SDP"?

In the Atlanta meeting (Nov 2012) I remember waiting for those damned
elevators with Justin.  He said something like: "So, if we'd chosen
comment 22 [CU-RTC-Web] do you think we'd be done by now?"  I was
quick to answer, "Of course not."  After all, we'd only made that
proposal 3-4 months earlier.  I know that nothing gets done in less
than a year, and this is not a small undertaking.

Since then, I've gained a more nuanced view.  We've set an impossibly
high bar for this specification, including all sorts of crazy
features: FEC, simulcast, layered codecs, congestion control,
undeployed codecs, multiplexing, and not to mention a new data
channel.

In reality, SDP never negotiated all that crap before.  Worse, despite
the existence of RFCs for most of these features, it turns out that
most implementations were proprietary.  We couldn't even agree on what
an m-line represents.

So, if asked the same question today, I'd probably have to say: "We'd
at least have had basic scenarios shipped.  We might not have sorted
out the hard cases like layered codecs, but we do have basic
functionality."

What we have this the complete antithesis of any project I've been
involved in over the past 10 years.  It's gold-plating the pink
squirrel.

If we want to ship this thing, then we should be managing scope, not
protecting it.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 19 Jul 2013 18:25:13 +0000

Adam Roach [mailto:[email-masked]]
> surface in a JavaScript application, it indicates a hole in the current WebRTC
> specification that we need to fix.
> 

But it is, at least in some sense, even if we come up with lots of constraint APIs.

> 
> I think we all pretty much agree that SDP is not supposed to be the WebRTC
> API surface.

Not sure about that, but suppose that's true for a moment...

> 
> I think we're pretty much all on the same page that we need to add stuff to
> the current API to handle these use cases.

But how can we possibly add stuff to the current API that runs directly counter to the fact that 1) the two browsers are attempting to negotiate things with one another over an SDP-based channel instead of doing what the application developer tells them to do and 2) because that negotiation is based on offer-answer, there is a state machine that will prohibit or allow certain state transitions at various times in the process?

This is a serious problem. As long as we assume that there is an API that emits SDP that is intended to be heard by the "far" browser and answered with more SDP from the "far" browser, any API that we specify will be akin to poking the browsers with a stick rather than directly grabbing the controls. Which is crazy, if you think about how the web server + the HTML and JavaScript that it emits is otherwise *completely* in control of what a browser does. (Short of the user closing the window, and even that can be intercepted!)

> SDP isn't really the reason it's difficult.

Some, but not all, of these "problems" need solving now. A whole lot can be deferred and certainly don't need a trip to MMUSIC *now* to sort out. An API that lets you send an audio and a video stream on the same RTP session could ship *today*, without any agreement as to what SDP represents that.

> interop out the window for very little gain.

Legacy interop has been out the window for over a year now. We have ICE required, we have DTLS-SRTP required, and sort of by definition *anything* that WEBRTC has had to go to MMUSIC for more SDP parameters for isn't compatible with "legacy" gear.

> And, while not the only (or

The API we proposed can, and already has, achieved a greater level of legacy interop, simply by telling the browser what to do from the JavaScript app, and then in the same JavaScript app creating information that can be sent by the server to the legacy equipment in whatever way is compatible. Great thing about that is that when we find bugs with the legacy gear, we just change a little server code or JavaScript code that gets sent down from the server,... rather than hoping that some day the browser vendor will show up with an SDP tweak that fixes the issue.

> These issues aren't hard because of SDP. These issues are hard because

But 80% of the "how do I represent this for others" doesn't need to be solved before the spec is final with a spec like ours. When the spec says "SDP comes out this hole here and goes in that hole there", it does... and 100% done, too, otherwise browser vendors are going to be forced to object to that spec.

Matthew Kaufman

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Jul 2013 11:26:40 -0700

Peter Thatcher said: 

"It's interesting that most of your list of things that needed to be solved without SDP (simulcast, FEC, correlation of RTP streams with MediaStreamTracks, glare) still haven't been solved for WebRTC even with SDP, despite many months (years?) of effort.  

I don't think anyone is saying "without SDP, there would be issues".  I think they're saying "without SDP, the issues are much easier/faster to solve, and the API would be much more usable and implementable".   And I don't think that's a naive opinion."

[BA] I would even go further - I'd claim that several of these issues are best solved without SDP, either in the API or on the wire.  RTP stacks used in WebRTC need to be able to adapt quickly, which implies that the adaptations cannot be signaled.  Also, if you want to scale, then it's important to strip out unnecessary operations that create performance bottlenecks in media-aware network elements (e.g. decrypt/encrypt operations , parsing of codec-specific parameter sets, transcoding, etc.). All this points to moving functionality out of signaling (and codecs) and into RTP.  If you take this perspective, then removing SDP dependencies isn't just a better plan for getting to "done" - it's an essential part of delivering the next generation realtime architecture.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 19 Jul 2013 18:27:48 +0000

+1 to Roman's comment below. No matter what additional API is produced, as long as the offer/answer state machine is there and there is SDP going between the browsers the JavaScript is either A) not actually in control of what's happening or B) manipulating a bunch of SDP and running the other side of that state machine so as to achieve that control.

There's another way, we wrote it down and published it almost a year ago, and I still believe that starting with that would get us to a full spec sooner than the current path... even more so, now that the last 9 months has achieved approximately nothing.

Matthew Kaufman

From: Roman Shpount [mailto:[email-masked]]

You cannot be more wrong. Each application deals with predictable set of scenarios (ones it produces) and interfaces with predictable set of non webrtc devices. These external devices are under control of the application developer. Application developer is responsible for interop with these devices. What is needed is predictable media and signaling generated by webrtc devices running the same application. With negotiation and SDP backed into the webrtc device it is very hard to achieve. So, for me as webrtc developer let me develop a negotiation scheme that works for me and make sure it stay working regardless of the browser type or version. Right now controlling webrtc application feels like driving the boat down the river by tickling the captain.
_____________
Roman Shpount

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 19 Jul 2013 18:38:09 +0000

From: Adam Roach [mailto:[email-masked]]:
> 
> I think this is a hopelessly naïve interpretation of the facts on the ground.
> Simply discarding SDP doesn't magically make the underlying issues go away.
> We would still need to settle a vast number of issues around things like
> simulcast, FEC, codec parameters, indication of supported codecs, correlation
> of RTP streams with MediaStreamTracks, attempts by both parties to
> operate on the same stream simultaneously [1], etc. Basically, with very rare
> exception, the same set of problems that we need to solve if we *don't*
> throw SDP out the window.

Not today we wouldn't. We'd need a handful on knobs that let the most common use cases be implemented under JavaScript control, and then we could look at what other APIs need to be added later. None of simulcast, FED, or any of those things (with the exception of the "a=fmt" section for codec parameters or an equivalent) needs to be done to get WebRTC out the door.

> ...
> Your pain point isn't offer/answer.

Yes it is. It immediately limits the possible operations that *any* API would be able to achieve.

> Two unilaterally declared sessions that are
> simply blasted out onto the wire only satisfies the simplest of use cases; you
> need a negotiation, and any attempt to define how that negotiation looks is
> going to arrive at something with enough rules that it is substantially as
> complicated as offer/answer.

Simply not true. Offer/answer is only one way to get two things to talk to each other, and it is a "trunk side" "peer to peer" negotiation that assumes no intelligence in the middle.

> communications are not easy to get right

Aha! I think I see your problem here.

If we give the web developer some JavaScript APIs, then it isn't "non-maser-slave networked communications". In fact it is exactly the opposite. 

Just like all other "HTML5" technologies we should be assuming that the web server and the HTML+JS it sends down *is the master*, telling the browser exactly what it should do. In this scenario, there are a multitude of ways, from simple to complex, to ensuring that both (or more, for any non 1-1 use case) ends are sending data over their network connection that the other end can use and render.

> I understand comment 22 at its core [2], but it has a corollary: any system
> that replaces SDP O/A will end up being similar in complexity once all
> interested parties' use cases have been factored in.

I doubt it. But even if that's true, it will give the JavaScript developer direct control over what is happening, and that's a win. And likely, much of the "extra complexity" you are thinking of will end up in shared JS libraries, not baked into a browser. And the legacy interop you're concerned about? Any compatibility issues will get fixed right in that same place, long before any browser vendor works out exactly what is necessary to work with a particular device that a web site operator cares for their users to connect to.

Matthew Kaufman

ps. Comment 22 isn't "SDP is hard"... rather it is "if you were using our API, you wouldn't be encountering this issue at all"

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 19 Jul 2013 18:40:38 +0000

From: Martin Thomson [mailto:[email-masked]]
> Negotiation is a hole.  A vast, soul-sucking, waste of time.

And negotiation over SDP requires a trip to MMUSIC every time you think of something new, too. That's a soul-sucking waste of time *itself*.

Matthew Kaufman

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 19 Jul 2013 18:42:12 +0000

So we should have APIs that let JavaScript applications adapt to these different environments (like we do for everything else in "HTML5"), *not* try to solve this by making the API be "tickling the ship captain" and attempting to do everything else in a pairwise negotiation between two elements, one of which might not even be a browser.

Matthew Kaufman

From: Ted Hardie [mailto:[email-masked]]
Sent: Friday, July 19, 2013 10:07 AM
To: Martin Thomson
Cc: Adam Roach; Iñaki Baz Castillo; Cullen Jennings; Matthew Kaufman (SKYPE); <[email-masked]>; [email-masked]
Subject: Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

On Fri, Jul 19, 2013 at 9:54 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:

Even if you have the same javascript application downloaded, you will have disparate capabilities in the environments into which it is downloaded (browser/os/codecs/media sources/available network capacity).  Getting set intersection and preference order for those capabilities is something that applications actually want.  You may be able to move the pain of that around, but it isn't a waste of time.

Ted

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 11:47:10 -0700

> to the current API to handle these use cases.

If SDP isn't the control surface, than what is the API surface?  The only
way to tell the browser to setup an ICE connection is to give it SDP.  The
only way to tell it to send and receive RTP packets is to give it SDP.  The
browser might produce the SDP for you, and you might be told not to change
it, but at the end of the day, the commands that make the browser setup ICE
connections and send and receive RTP is the SDP.   Therefore, SDP is the
API control surface.  Until JS can setup an ICE connection and send and
receive RTP packets without giving the browser SDP, then SDP is the control
surface.

This might not be so bad for applications that use SDP for signalling, but
any app that uses something other than SDP for signalling necessarily views
SDP as the API surface, since there is no other way to tell the browser
what to do.

>>  "my use case (legacy interop) is the most important and my solution (SDP)
>> is the best solution for everyone and I know better because I've been
>> working on it for longer".  Hubris?
>>
>
> No, you've misunderstood pretty much everything I said. I'll summarize in
> fewer words.
>
>
You called everyone who doubts the SDP API naive and full of hubris, and
now you're telling me I'm misunderstanding pretty much everything.

> SDP isn't really the reason it's difficult.

One problem is that this is a very difficult to use API for web developers.
 And SDP is at the heart of that problem.  Lots of people have said so, and
why, in great detail.  Do you really believe all of them are naive and full
of hubris?

> interop out the window for very little gain.

I think this is the real issue at hand:  You value legacy interop more than
a usable API.  Other value a usable API more than legacy interop.  You're
willing to sacrifice API usability for legacy interop, and they're willing
to sacrifice legacy interop for a usable API.  There are different groups
with different needs and different perspectives.

I think we can have both legacy interop and a usable API, and there are
many ways we can achieve that.  But we've been asked to delay talking about
it until "1.0" is done.  So, we'll have to wait for further discussion.

> And, while not the only (or even main) consideration, legacy interop has
> significant value. It would be a shame to destroy that value based on a
> misconception.
>

SDP as an API surface makes the API worse.  And API surface that didn't
require SDP would be a better API surface.  It's a fallacy to assume that
because we need legacy interop, we have to support it to the detriment of
of non-legacy interop use cases.  We could have both, if we wanted to
design an API for both.

Please try to realize that there are worlds of use cases beyond yours, and
there are lots of people with different needs than yours.  And please try
to listen to them rather than just calling them naive and full of hubris.

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 13:51:33 -0500

On 7/19/13 13:47, Peter Thatcher wrote:
>  Do you really believe all of them are naive and full of hubris?

No, I think they're using an API that is nowhere near finished yet, 
which is necessarily going to be painful. The complaints are legitimate.

The scapegoating of SDP is what's misguided.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 11:56:48 -0700

On Fri, Jul 19, 2013 at 10:51 AM, Adam Roach <[email-masked]> wrote:

>> So, are you trying to say "Look how hard this is to do with SDP.  We're
>> not even done yet.  It will be even harder without SDP"?
>>
>>

It wouldn't be harder, and it wouldn't be easier.  So, it would be about
the same amount of work for either?

> and you would lose tangible benefits.

I still don't understand how this could be true.  If we define an API that
allows JS to use either SDP or not, at its choice, how is that a loss?  It
seems like only a gain.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 19 Jul 2013 18:59:22 +0000

From: Adam Roach [mailto:[email-masked]]:
>
> No, I think they're using an API that is nowhere near finished yet, which is
> necessarily going to be painful. The complaints are legitimate.
> 

I could actually live with SDP, though it is pretty clunky. What I can't live with is having an offer/answer state machine in the browser. And I have enough experience with such things that I think there's a better word than "misguided" to describe my feelings.

Matthew Kaufman

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 12:04:35 -0700

On Fri, Jul 19, 2013 at 10:57 AM, Martin Thomson
<[email-masked]>wrote:

> not

> If we want to ship this thing, then we should be managing scope, not

Slight aside, but is this a correct model of what has happened with regards
to scope?

The W3C is waiting for the IETF RTCWEB WG.  The RTCWEB WG is waiting for
the MMUSIC WG.   The MMUSIC WG has years worth of things that aren't well
defined in SDP that it's now taking the opportunity to define (a sort of
"RAI 2.0").  And everything back to the W3C is blocked by these things that
aren't well defined in SDP, meaning WebRTC isn't done until MMUSIC defines
all these things in SDP that have been piling up for years.

Is that accurate?  If so, I agree that "scope management" would be a good
thing to consider.

---

From: Adam Roach <[email-masked]>
Date: Fri, 19 Jul 2013 14:06:28 -0500

On 7/19/13 13:47, Peter Thatcher wrote:
> I think this is the real issue at hand:  You value legacy interop more 
> than a usable API.

This. *This* is why I've told you that you're misunderstanding 
everything. Don't take offense, just go back and read more carefully. I 
never said anything that implied that legacy interop is more valuable 
than a usable API. It's a nice strawman for you to build up and tear 
down, but you are arguing with a fictional character who is not me when 
you do so.

What I'm trying to point out is that these goals are not at odds with 
each other. Your statement above implies that you have taken it as given 
that we can't do both -- that there is a tradeoff here to be made. If 
you take that as a fundamental principle, then I can see how nothing I 
say makes any sense.

But they're not mutually exclusive goals. Keep that in mind, and go back 
to re-read what I've written.

/a

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 12:13:29 -0700

On Fri, Jul 19, 2013 at 11:51 AM, Adam Roach <[email-masked]> wrote:

> No, I think they're using an API that is nowhere near finished yet, which
> is necessarily going to be painful. The complaints are legitimate.
>
>
"nowhere near finished yet"?  Yikes.  We just spent almost a year arguing
about what an m-line is.  What's your timeline for finishing?

Well, I guess we're going to have to agree to disagree, because from my
perspective as a web developer and a browser implementer, the API being
based on SDP Offer/Answer is the heart of the problem, and not just a
scapegoat.  I hope that we can do much better in a 2.0 API while
maintaining legacy interop (make everyone happy), but of course I'll
refrain from talking about that further until the right time has come.

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 12:42:38 -0700

On Fri, Jul 19, 2013 at 12:06 PM, Adam Roach <[email-masked]> wrote:

> This. *This* is why I've told you that you're misunderstanding everything.
> Don't take offense, just go back and read more carefully. I never said
> anything that implied that legacy interop is more valuable than a usable
> API. It's a nice strawman for you to build up and tear down, but you are
> arguing with a fictional character who is not me when you do so.
>
> What I'm trying to point out is that these goals are not at odds with each
> other. Your statement above implies that you have taken it as given that we
> can't do both -- that there is a tradeoff here to be made.

If you take that as a fundamental principle, then I can see how nothing I
> to re-read what I've written.
You are claiming that there is no tradeoff between API usability and legacy
interop.  If that is the case, then why have we designed such a terribly
unusable API?  If we can have an API with both legacy interop and
usability, then why didn't we create that API?  If we can make an API that
serves both sides (roughly, "web developers" and "legacy interop") well,
why have we picked an API that only serves one well?

I do believe that we can have an API that provides both good usability and
legacy interop, and that can server both sides (and even more sides) well.
 But is most assuredly not the API we've designed so far, and it's not the
API we're headed toward (at least not with "1.0").  I have hope for the 2.0
API, but let's not kid ourselves.  The 1.0 API picked a side and ran with
it.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 17:52:22 -0700

> Negotiation is a hole.  A vast, soul-sucking, waste of time.

That's might be closer to true when you control both ends, like Skype.

It's not true when a browser from one vendor running an application from a scone vendor needs to talk to video conferencing system from a third vendor.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 17:54:04 -0700

On Jul 19, 2013, at 10:18 AM, Peter Thatcher <[email-masked]> wrote:

> 
> It's interesting that most or your list of things that needed to be solved without SDP (simulcast, FEC, correlation of RTP streams with MediaStreamTracks, glare) still haven't been solved for WebRTC even with SDP, despite many months (years?) of effort.  
> 

Peter, with the exception of Simulcast, which of these do you think has not been solved in SDP when not using bundle?

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 17:56:45 -0700

On Fri, Jul 19, 2013 at 5:54 PM, Cullen Jennings <[email-masked]> wrote:

> > It's interesting that most or your list of things that needed to be
> solved without SDP (simulcast, FEC, correlation of RTP streams with
> Peter, with the exception of Simulcast, which of these do you think has
> not been solved in SDP when not using bundle?
>
>
>
Has FEC been defined for WebRTC?
Has glare been solved?
Has mapping of RTP streams with MediaStreamTracks been resolved (with the
exception of the "unity plan" which has not yet been approved)?

I think the whole list I gave is still unsolved/unresolved.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 17:57:28 -0700

> And negotiation over SDP requires a trip to MMUSIC every time you think of something new, too. That's a soul-sucking waste of time *itself*.

Better than a trip to W3C, IETF, and XSF

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 18:00:49 -0700

The logic of how to talk to the video conferencing system doesn't need to
be backed into the browser.  If the API provides enough control the JS, the
web app can contain the logic to talk to the video conferencing system.

I know I'm going to start sounding like a broken record, but you brought up
video conferencing systems as an example, so I will say it again: there are
are video conferencing systems that don't use SDP for signalling.  For
example, there are video conferencing systems that use Jingle for
signalling.  Would I expect the logic of how to speak to that video
conferencing system to be baked into the browser?  No, I think I'd prefer
it to be built into a web app built on top of a good API.  Why should
SDP-based video conferencing systems be treated special?

On Fri, Jul 19, 2013 at 5:52 PM, Cullen Jennings <[email-masked]> wrote:

> It's not true when a browser from one vendor running an application from a
> scone vendor needs to talk to video conferencing system from a third vendor.
>
>
>
>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 18:01:24 -0700

On Fri, Jul 19, 2013 at 5:57 PM, Cullen Jennings <[email-masked]> wrote:

> > And negotiation over SDP requires a trip to MMUSIC every time you think
> of something new, too. That's a soul-sucking waste of time *itself*.
> >
> > Matthew Kaufman
>

That's definitely a matter of opinion.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 18:10:59 -0700

> Peter, with the exception of Simulcast, which of these do you think has not been solved in SDP when not using bundle?
I asked about SDP, not WebRTC. The thing that is making this take a long time is you don't want to use SDP. 

> Has FEC been defined for WebRTC?  
yes, that is defined for SDP O/A

> Has glare been solved?
yes

> Has mapping of RTP streams with MediaStreamTracks been resolved (with the exception of the "unity plan" which has not yet been approved)?
This is obviously trivial if not using bundle. Any version of MSID would work. It's only complicated by bundle

> I think the whole list I gave is still unsolved/unresolved. 
I disagree. They are only unresolved because we want to add bundle and that was a major change to RTP resulting in a bunch of work needing to be done to see how that impacted SDP.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 18:20:07 -0700

Thanks, 

I will note that over half of that very small sample set is folks that have been long termed involved in SIP and VoIP so, uh, might not be a representative sample of type of people you are portraying it as. 

On Jul 19, 2013, at 7:51 AM, Peter Thatcher <[email-masked]> wrote:

> <Input from JS Developers on their experience with the WebRTC API - Inputs.csv>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 18:20:40 -0700

> time is you don't want to use SDP.
I'm not asking about SDP.  I'm asking about WebRTC.   It's the WebRTC API
I'm concerned with.

> yes, that is defined for SDP O/A

FEC still isn't defined for use with the WebRTC API.  I believe it's still
in the long list of things that can't be resolved until Plan A vs. Plan B
is resolved.

> yes
In the context of WebRTC, it wasn't at the last IETF.  What has changed
since then?

>  > Has mapping of RTP streams with MediaStreamTracks been resolved (with
> the exception of the "unity plan" which has not yet been approved)?
Even without BUNDLE, it's still not clear what kind of SDP createOffer
should generate for multiple tracks.  (with the exception of the "unity
plan" which has not yet been approved).

> I disagree. They are only unresolved because we want to add bundle and
> that was a major change to RTP resulting in a bunch of work needing to be
> done to see how that impacted SDP.
>
>
It thinks there's more than just BUNDLE, but you make a good point:
 finishing the WebRTC API currently requires lots of major changes to SDP,
which creates big delays.  In fact, it's the number one things holding back
the API from being done, because major changes to SDP take a really, really
long time.

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 18:24:11 -0700

You're surprised that the first web developers that try out WebRTC and have
feedback have experience with SIP and VoIP?  We shouldn't find that
surprising, nor should we discount their feedback because of it.

In any case, it's the best data we've got so far.  I made an effort to some
data because no one else had.  If you would like to make an effort to get
better feedback, I'd more than welcome it.  In fact, I'd say you ought not
to have waited for me to do it.

On Fri, Jul 19, 2013 at 6:20 PM, Cullen Jennings <[email-masked]> wrote:

>
> Thanks,
>
> I will note that over half of that very small sample set is folks that
> have been long termed involved in SIP and VoIP so, uh, might not be a
> representative sample of type of people you are portraying it as.
>
>

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 18:24:55 -0700

> nothing useful is being done for WebRTC by "defining" those "minor

Well lets prioritize fixing them. Which ones are causing interoperability problems between browsers?

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 18:47:45 -0700

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 <[email-masked]> wrote:

> "mindless works fist"?  There's a deep meaning there, but I'm still trying to figure it out...
> 
> 

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

> > 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.

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 19 Jul 2013 18:52:54 -0700

On Jul 19, 2013, at 6:24 PM, Peter Thatcher <[email-masked]> wrote:

> You're surprised that the first web developers that try out WebRTC and have feedback have experience with SIP and VoIP?  We shouldn't find that surprising, nor should we discount their feedback because of it.

I was not saying that feedback from folks like Bernard Aboba was not useful, of course it can be. I was just noting the sample set.

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 18:56:50 -0700

On Jul 19, 2013 6:47 PM, "Cullen Jennings" <[email-masked]> wrote:
> 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.
> > 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
> > > At the *very least* for each and every line that comes from
>
> 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".

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 19:10:26 -0700

Like I said when I first sent the summary, anyone is welcome to make a
different summary from the raw data, or collect their own data.  I haven't
been around long enough to know how to categorize people and whose input is
considered valuable and whose isn't, so I ignorantly gave everyone equal
weight.  So if you'd like, you can filter out  Bernard and recalculate.

On Jul 19, 2013 6:52 PM, "Cullen Jennings" <[email-masked]> wrote:

> > You're surprised that the first web developers that try out WebRTC and
> have feedback have experience with SIP and VoIP?  We shouldn't find that
> I was not saying that feedback from folks like Bernard Aboba was not
> useful, of course it can be. I was just noting the sample set.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Sat, 20 Jul 2013 03:15:42 +0000

> scone vendor needs to talk to video conferencing system from a third

If you think that the second vendor's web server + signaling gateway should be doing negotiation between itself and the third vendor's videoconferencing system, then that's fine.

If you think that the second vendor is going to get the first vendor to ship an updated browser to make its SDP O/A 100% compliant with what the third vendor's system is expecting, then you're crazy. It simply isn't going to happen, and what's more, given that the browser from the first vendor contains a complete JavaScript implementation, there's no reason why it should be. The first vendor should provide the JS APIs that are necessary for the second vendor to build the system they want to build. Done. And without the endless pain that trying to make browser SDP O/A compatible with anything else is going to be.

Matthew Kaufman

---

From: Robin Raymond <[email-masked]>
Date: Fri, 19 Jul 2013 23:17:47 -0400

Is WebRTC exclusively targeting browser interoperability ? I'm not 
trying to nitpick, but this is a vital point of issue.

If yes, then why do we need to carry so much legacy SDP stuff to achieve 
basic sending of media between browsers? Seems like an incredible 
designoverkill to me. It's much easier to define a minimal feature set 
with a wire protocol that can achieve basic media between browsers. You 
could define "SDP-light" and that would be sufficient.

If no, then why isn't JavaScript the entity generating the SDPs rather 
than the browser binaries?

If the browsers aren't the end-all-be-all for interoperability, then all 
those SDPs have work not just between browsers, but untold numbers of 
SIP devices, servers, gateways, relays, desktop applications and mobile 
devices. Either all of those devices have to become equally capable of 
handling every WebRTC SDP produced from every browser, every version, 
working around every format difference, as every other device on the 
planet -- or -- we'll have to extract the SDP information using JS 
libraries and signal a format strictly compatible to our network 
environment. Personally, I think most will choose the latter in 
practice. Even SIP people using SDP will end up extracting the browser's 
SDP and recreate their own SDP instead.

Given how tough it is for two browser vendors (who even have access to 
each other's source code) to get this SDP negotiation right, I'm 
extremely concerned about an entire planet of devices getting this stuff 
right.

The trouble isn't that SDP isn't expressive enough or it's too ugly a 
format, it's that it's too expressive (okay, and it's ugly too). The 
trouble isn't that it's easy to negotiate O/A only for simple cases, 
it's that when we end up having to signal this stuff in "our own way", 
we'll be fighting with an O/A state negotiation machine instead of 
controlling the RTP engine directly with knobs and dials.

As a developer, I want:
1) to control what the RTP engine does on the wire (to ensure 
compatibility between devices);
2) strict, well defined, easy-to-understand API contracts that do not 
change, and are only extended in well defined ways;
3) knobs and dials to control the exposed capabilities, and _not_ a 
negotiation machine to not fight where I can only indirectly "do what I 
want";
4) predictable outputs, i.e. not having random extensions or odd 
differences in the middle some blob format show up from 
version-to-version, and from browser-to-browser;

I do not believe we can address these by tweaking the SDP format, or 
defining SDP better, or making wrappers for SDP.

The problem is fundamentally SDP O/A as the mandated.

-Robin

> Cullen Jennings <mailto:[email-masked]>
> 19 July, 2013 9:24 PM
>
>
> Well lets prioritize fixing them. Which ones are causing 
> interoperability problems between browsers?

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 19 Jul 2013 20:20:25 -0700

You can remove my line in the spreadsheet, but the residue of my bit presence may remain, polluting nearby cells. I recommend use of bit bleach. 

On Jul 19, 2013, at 7:10 PM, "Peter Thatcher" <[email-masked]> wrote:

> Like I said when I first sent the summary, anyone is welcome to make a different summary from the raw data, or collect their own data.  I haven't been around long enough to know how to categorize people and whose input is considered valuable and whose isn't, so I ignorantly gave everyone equal weight.  So if you'd like, you can filter out  Bernard and recalculate.
> 
>

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 19 Jul 2013 20:28:31 -0700

Best to nuke the spreadsheet from orbit.  It's the only way to be sure.
On Jul 19, 2013 8:20 PM, "Bernard Aboba" <[email-masked]> wrote:

> You can remove my line in the spreadsheet, but the residue of my bit
> presence may remain, polluting nearby cells. I recommend use of bit bleach.
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Sat, 20 Jul 2013 03:37:20 +0000

From: Cullen Jennings [mailto:[email-masked]]:
> 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.

> Current JSEP draft says the browser does not need to allow that to be

Where? Don't see that at all.

> you can remove or reorder

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

> 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"

> not in current spec but you can find dissection on list about making sure that

Agreed, not specified.

> 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.

> Uh, I'll leave that as an exercise to the readers. Try hard and see if you can

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?

> Current JSEP draft says that is done with constraints

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

> Current JSEP draft says that is done with constraints

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

> 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.

> Current JSEP draft says the browser does not need to allow that to be

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.

> Current JSEP draft says the browser does not need to allow that to be

Disagree. See above.

> 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?

> Why would a browser want to generate that?

(Same as previous comment)

> Current JSEP draft says the browser does not need to allow that to be

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.

> draft-jennings-rtcweb-plan-01

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

> > > 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.

> 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

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Sat, 20 Jul 2013 03:41:16 +0000

Completely agree with Peter here. SDP-based systems shouldn’t be any more important than H.323 or Jingle based systems, or whatever else might be out there.

What I don’t understand is why, with such strong and valid feedback from so many people trying to use the API that exists at present, any WG member or chair would be suggesting to Peter that the resolution of this class of problems must be deferred until “after 1.0”.

If the chairs actually said that (and I can’t find it in any searches I’ve done of public lists), then I think we have a problem. If the developers feel like no matter what they say, they can’t make a positive impact on the specification that is produced by the WG, then we *definitely* have a problem.

Don’t we?

Matthew Kaufman

From: Peter Thatcher [mailto:[email-masked]]
Sent: Friday, July 19, 2013 6:01 PM
To: Cullen Jennings
Cc: Martin Thomson; Adam Roach; Iñaki Baz Castillo; Matthew Kaufman (SKYPE); <[email-masked]>; [email-masked]
Subject: Re: On babies and bathwater (was Re: [rtcweb] Summary of Application Developers' opinions of the current WebRTC API and SDP as a control surface)

The logic of how to talk to the video conferencing system doesn't need to be backed into the browser.  If the API provides enough control the JS, the web app can contain the logic to talk to the video conferencing system.

I know I'm going to start sounding like a broken record, but you brought up video conferencing systems as an example, so I will say it again: there are are video conferencing systems that don't use SDP for signalling.  For example, there are video conferencing systems that use Jingle for signalling.  Would I expect the logic of how to speak to that video conferencing system to be baked into the browser?  No, I think I'd prefer it to be built into a web app built on top of a good API.  Why should SDP-based video conferencing systems be treated special?

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Sat, 20 Jul 2013 03:42:51 +0000

> Better than a trip to W3C, IETF, and XSF

One successfully early trip to the W3C to get some JS APIs that let me build anything I want later is a hell of a lot better than one trip to MMUSIC (when I'm already on a deadline, no doubt) every time I come up with an idea in the future.

I know you know this, so I don't know why you would say what you said.

Matthew Kaufman

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 20 Jul 2013 16:03:56 +0200

> It's not true when a browser from one vendor running an application from a scone vendor needs to talk to video conferencing system from a third vendor.

In the WWW, the servide provider provides both the server side (in
this case the Web and the video conference server) and the client side
(the JS). Your concern is good for a SIP phone but not for a browser
nor for a JS custom application controlled and designed by the
provider.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 20 Jul 2013 16:12:03 +0200

> nor for a JS custom application controlled and designed by the

Cullen, could you please give your opinion about what I've said above?
I also would like to know what happens if the video conference server
uses Jingle or any future RTC protocol (which uses RTP but no SDP for
media sig).

Thanks a lot.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 20 Jul 2013 16:26:05 +0200

> I will note that over half of that very small sample set is folks that have been long termed involved in SIP and VoIP so, uh, might not be a representative sample of type of people you are portrayi…

It is even worse if people interested and expert in SIP tells you that
the current SDP-blob-based API is really wrong for using SIP in
WebRTC, don't you think?

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 20 Jul 2013 16:27:42 +0200

> Well lets prioritize fixing them. Which ones are causing interoperability problems between browsers?

This means wasting time fixing SDP related issues that, once are
fixed, provides *nothing* useful to WebRTC.

--
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 23 Jul 2013 15:37:09 -0400

> the current SDP-blob-based API is really wrong for using SIP in

No, not at all - we're all jaded from past experience and we know how bad it is already, so Cullen's right we're all tainted.  Hopefully if we ask new people, they won't know the truth and give us much more positive results instead.  Or new people might even see the SDP-based "API" and think: "Oh cool, the API is a string blob of stuff in some archaic inconsistent syntax format with hidden state-based dependencies and rules... awesome!  I always wanted to party like it's 1999, and here's my chance!"

-hadriel

---

From: "Timothy B. Terriberry" <[email-masked]>
Date: Mon, 29 Jul 2013 02:16:35 -0700

> shows a limited and wrong WWW vision.

I recall EKR proposing an audit log for camera access. But the reasons 
for this were entirely related to security (an app with persistent 
permissions won't be as ready to abuse them if it knows it will leave a 
trail in logs not under its control).

I thought it was a really good idea. I still do.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 29 Jul 2013 11:37:18 +0200

2013/7/29 Timothy B. Terriberry <[email-masked]>:
> I recall EKR proposing an audit log for camera access. But the reasons for
> this were entirely related to security (an app with persistent permissions
> won't be as ready to abuse them if it knows it will leave a trail in logs
> not under its control).
>

What I meant was somebody requesting a "Call history panel" in the
browser (similar to the "Favorites panel" or the "Navigation History
panel"). ;)

-- 
Iñaki Baz Castillo
<[email-masked]>