Subject: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Jun 2013 18:36:21 +0200

Hi all, I re-send this mail in a new thread.

Dear WG Chairs,

With all due respect, IMHO there is too much controversy about SDP
usage in WebRTC so I would like to request the WG to reopen the "SDP
or not SDP" debate.

I would also appreciate that those in favour of mandating SDP as the
core communication for WebRTC explain their rationale again (given the
number of arguments against SDP and the frustration SDP is causing),
and also that they give arguments and responses to all the SDP related
issues nicely summarized in this mail:

  http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

Thanks a lot.

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

---

From: Erik Lagerway <[email-masked]>
Date: Tue, 18 Jun 2013 10:19:14 -0700

+1 to re-open the debate re: SDP

Although, as MK and RR have commented, it's not just SDP that is the issue.
We need to take a hard look at O/A as well.

/Erik

*Erik Lagerway <http://ca.linkedin.com/in/lagerway> |
*Hookflash<http://hookflash.com>
* | Twitter <http://twitter.com/elagerway> | WebRTC.is Blog<http://webrtc.is>
*
****

On Tue, Jun 18, 2013 at 9:36 AM, Iñaki Baz Castillo <[email-masked]> wrote:

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

---

From: Robin Raymond <[email-masked]>
Date: Tue, 18 Jun 2013 13:20:40 -0400

+1

... and to be clear it's SDP with offer/answer that really makes it 
horrible. Replacing with nicer JSON or a wrapper API solves nothing IMHO.

-Robin

> Iñaki Baz Castillo <mailto:[email-masked]>
> 18 June, 2013 12:36 PM
>

---

From: Roman Shpount <[email-masked]>
Date: Tue, 18 Jun 2013 13:25:20 -0400

I am also strongly for removing O/A and SDP from the API. This is a wrong
API surface that does not provide the necessary degree of control for
building WebRTC apps.
_____________
Roman Shpount

On Tue, Jun 18, 2013 at 1:20 PM, Robin Raymond <[email-masked]> wrote:

>   Iñaki Baz Castillo <[email-masked]>
>  18 June, 2013 12:36 PM
>

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Tue, 18 Jun 2013 13:40:40 -0400

+1 to reopening the discussion.

On Tue, Jun 18, 2013 at 1:25 PM, Roman Shpount <[email-masked]> wrote:

> On Tue, Jun 18, 2013 at 1:20 PM, Robin Raymond <[email-masked]>wrote:
>
>>
>> +1
>>

---

From: Ted Hardie <[email-masked]>
Date: Tue, 18 Jun 2013 13:15:12 -0700

I've read the messages on this thread up to lunchtime in California on June
18th.  I have not consulted with the other chairs, because we are still
somewhat out of synch, so this is my personal response, rather than a chair
response.

SDP occurs as an API control surface in this protocol, and it may also be
used in O/A semantics between endpoints.  The request does not clearly
state which aspect is asking for reconsideration.  Since one is handled in
a different group, that is critical.  Secondly, the requirement the group
has is that the solution *provides support sufficient to allow O/A
semantics*, not that these must be used between two parties using the same
signalling.   Being clear on what you would like to see by writing a draft
proposal, rather than simply asking to re-open concluded discussions would
be helpful.

Speaking very personally, I would like to see the group close having
completed its milestones.  While I am very aware that re-using a syntax
like SDP makes for some unpleasant moments, I'm not sure that any system
that actual has any level of interoperability with existing SIP deployments
as a goal will avoid that unpleasantness--at best, you have a mechanism on
one end that looks different *but must be mapped to SDP* in the
interoperability case.   Creating something new that accomplishes that and
is substantially better than SDP seems like a long task to me.

Again, not as a chair decision or statement, but to give some response to
the points made.

regards,

Ted Hardie

---

From: Adam Roach <[email-masked]>
Date: Tue, 18 Jun 2013 15:22:56 -0500

On 6/18/13 15:15, Ted Hardie wrote:
> Creating something new that accomplishes that and is substantially 
> better than SDP seems like a long task to me. 

Many men have died on that hill. I'm still sad about the colossal time 
and talent sink represented by these 61 pages:

http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt

I have no reason to think that burning WebRTC down the the ground and 
starting over would produce a different result. If anything, the issues 
are more contentious now than they were in 2005.

/a

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 18 Jun 2013 20:56:08 +0000

The good news is that I co-authored and Microsoft published a nice starting point for discussing a specification that doesn't have SDP O/A.

The bad news is that it was voted down for future consideration at W3C.

The good news is that W3C has apparently abdicated the entire responsibility for producing a browser API to IETF, where it has not yet been voted down.

More good news is that if and when the W3C considers the current specification that the IETF produces, if it is not complete enough to independently replicate without looking at other browser's source code (in other words, if the SDP that is produced is not fully specified in an interoperable way in either the W3C specification itself or, worst case, in the entire stack of normative references), I will also have the pleasure of co-authoring a formal objection to publishing that specification.

One might consider that since the current SDP-based path we are on does not have anywhere near a complete set of implementable normative references, and that producing such might actually be harder than using something that doesn't rely on SDP as the API surface, you might be a lot farther from something that finishes the entire W3C process than you think.

Matthew Kaufman

________________________________
From: [email-masked] [[email-masked]] on behalf of Ted Hardie [[email-masked]]
Sent: Tuesday, June 18, 2013 1:15 PM
To: Iñaki Baz Castillo
Cc: [email-masked]
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

I've read the messages on this thread up to lunchtime in California on June 18th.  I have not consulted with the other chairs, because we are still somewhat out of synch, so this is my personal response, rather than a chair response.

SDP occurs as an API control surface in this protocol, and it may also be used in O/A semantics between endpoints.  The request does not clearly state which aspect is asking for reconsideration.  Since one is handled in a different group, that is critical.  Secondly, the requirement the group has is that the solution *provides support sufficient to allow O/A semantics*, not that these must be used between two parties using the same signalling.   Being clear on what you would like to see by writing a draft proposal, rather than simply asking to re-open concluded discussions would be helpful.

Speaking very personally, I would like to see the group close having completed its milestones.  While I am very aware that re-using a syntax like SDP makes for some unpleasant moments, I'm not sure that any system that actual has any level of interoperability with existing SIP deployments as a goal will avoid that unpleasantness--at best, you have a mechanism on one end that looks different *but must be mapped to SDP* in the interoperability case.   Creating something new that accomplishes that and is substantially better than SDP seems like a long task to me.

Again, not as a chair decision or statement, but to give some response to the points made.

regards,

Ted Hardie

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Tue, 18 Jun 2013 23:28:52 +0200

Hi, in reply to concers from Adam and Ted:

AFAIK nobody voting for dropping SDP is requesting a "new format to
replace SDP" (if I am wrong, then please correct me). What we all ask
for is:

- A JS API to ask the browser's WebRTC stack for media resources (this
is accomplished with getUserMedia).

- A JS API to provide the local PeerConnection with media data from a
remote peer we want to establish a multimedia session with, but such
an API must not be based on passing a blob SDP, but based on passing
some kind of JS Object with detailed media attributes, including
transport params (ICE fields, remote media types, remote codecs, other
media features, and so on).

- A JS API to request to our local PeerConnection media data that we
can send to the remote peer, in the way we want, in one step or in
multiple steps, and such an API call must not return a blob SDP but a
JS Object with detailed media attributes (same as above).

- Period.

We don't want to be forced to O/A model (although I know of no other,
but I do know there are other models that don't rely on O/A
semantics).

We don't want to deal with blob strings that must be retrieved from
our local PC and sent to the remote PC as they are, untouched. Instead
we want to pass and receive the media information in any custom way
(which can be serialized in JSON, represented as SDP, etc) in a single
step or in multiple steps (so those cared about ICE gathering delay
can optimize their cuscom logic and code).

And that's all (may be I miss something or I am wrong in some aspect).
And once we have that:

- There will appear cool JS libraries coded by SIP experts that will
take the above "JS Object with media information" retrieved from our
local PerrConnection and "export" it into a SDP string that will allow
interoperability with SIP devices (those supporting WebRTC media
requirements). For this, probably the IETF SIP WG may start a new item
for specifying how such a SDP must look. The JS library will be hosted
in some public server and will provide updates frequently ("press
F5").

- Some SIP vendors could also provide their own JS library that offers
more media features to interop with their gateways.

- Some others will code JS libraries defining a new media signaling
protocol in the wire.

- And some others will code their own media signaling library for
their websites in which they don't need interoperability with devices
other than pure WebRTC browsers.

- And some of them will use O/A and some others won't.

So, regardingyour concerns about how hard is replacing SDP with "a new
and better format", IMHO nobody is requesting that.

Best regards.

2013/6/18 Matthew Kaufman (SKYPE) <[email-masked]>:
> The good news is that I co-authored and Microsoft published a nice starting
> point for discussing a specification that doesn't have SDP O/A.
>
> The good news is that W3C has apparently abdicated the entire responsibility
> for producing a browser API to IETF, where it has not yet been voted down.
>
> More good news is that if and when the W3C considers the current
> specification that the IETF produces, if it is not complete enough to
> independently replicate without looking at other browser's source code (in
> other words, if the SDP that is produced is not fully specified in an
> interoperable way in either the W3C specification itself or, worst case, in
> the entire stack of normative references), I will also have the pleasure of
> co-authoring a formal objection to publishing that specification.
>
> One might consider that since the current SDP-based path we are on does not
> have anywhere near a complete set of implementable normative references, and
> that producing such might actually be harder than using something that
> doesn't rely on SDP as the API surface, you might be a lot farther from
> something that finishes the entire W3C process than you think.
>
> Matthew Kaufman
>
> used in O/A semantics between endpoints.  The request does not clearly state
> which aspect is asking for reconsideration.  Since one is handled in a
> different group, that is critical.  Secondly, the requirement the group has
> is that the solution *provides support sufficient to allow O/A semantics*,
> not that these must be used between two parties using the same signalling.
> Being clear on what you would like to see by writing a draft proposal,
> rather than simply asking to re-open concluded discussions would be helpful.
>
> completed its milestones.  While I am very aware that re-using a syntax like
> SDP makes for some unpleasant moments, I'm not sure that any system that
> actual has any level of interoperability with existing SIP deployments as a
> goal will avoid that unpleasantness--at best, you have a mechanism on one
> end that looks different *but must be mapped to SDP* in the interoperability
> case.   Creating something new that accomplishes that and is substantially

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

---

From: Robin Raymond <[email-masked]>
Date: Tue, 18 Jun 2013 18:11:21 -0400

That's exactly part of the trouble. People thinking we need a 
signaling/negotiation framework at all for media. We don't. We don't 
need to replace SDP with anything. It's just not necessary at all. Yes, 
SIP guys will need to create and parse SDP compatible with their 
networks, but it's still better to do that from a dynamic updatable 
language like JavaScript than hard coding all that inside the browser. 
They don't need the browser to generate something as pre-built into the 
hardcoded binary that generates serialized formats for the interface to 
the mechanics underneath. Likewise, we don't need a JSON version nor an 
XML version of SDP.

Start treating the media and RTC like an OS API and not like a signaling 
layer. Sure, restrictions for security reasons must exist (like 
requiring ICE agreement on the wire) but beyond that the sky should be 
the limit. If we have a programmatic interface to the lower layer 
components, we can wrap it up with our own JavaScript in any method at a 
higher level someone might want. JavaScript is a powerful language, so 
there's no reason we couldn't do some really cool stuff. JSEP? No 
problem. Traditional SIP/SDP? Check. XMPP? Yup. However Skype 
negotiates? Yup. Open Peer (and other future protocols) with stateless 
negotiation? Check. Custom silo protocol? Yup.

You have sources, like camera's / microphones. You need to be able to to 
get information about the formats available to be opened.

You have outputs like screens and speakers.

You have a mixer where you can pin in/out the various sources.

You have codecs.

You have media streams going in and coming out from a mixer where you 
can map media to RTP streams.

You have DTLS connections for arbitrary data.

I'm sure I'm missing something in the 5 minutes it took to write that 
but the point is that this isn't rocket science and it's not difficult 
to wrap the basic constructs like those with a decent API (even if the 
details can, should and will be argued but have little impact on the 
global scheme of things [unlike SDP]) and much easier to come to 
decisions because they are well known constructs with limited scopes. 
With JavaScript shims as needed, we can build out anything out of those 
building blocks we might dream up. Stick to the core of what each part 
is supposed to do and leave the rest to the higher level. Let's define 
those APIs and let's stick to the RTC layer consisting of only: 
STUN/ICE/TURN, DTLS, RTP/RTCP and security/encryption requirements (and 
any other low-level data/media level requirements). Get rid of this 
inane requirement for SDP and offer/answer negotiation which is just a 
road block and hinderance and doesn't add much value but whose long term 
costs/consequences are huge!

Those are all lower level APIs that can entirely be done without a 
signaling protocol like SDP with offer/answer at all. Not everyone does 
SDP. Nor does everyone want to SDP, and future signaling protocols 
likely won't want to do SDP.

The trouble currently with WebRTC is we have virtual no low level API 
control and only way to interface to those components is frequently 
exclusively via SDP and it forces everyone to use this horrifically 
monolithic do-everything serialized format and offer/answer round trip 
to boot to affect change instead of allowing lower level control over 
what's going on in each component; and control over the media mapping 
without requiring a round trip like offer/answer requires...

This decision was made primarily by the industry SIP folks (some of 
which have changed their minds since), many of whom still mistakenly 
believe that without SDP there is no compatibility with WebRTC, or 
believe that it produces greater compatibility, or believe we must have 
"something" common to signal media information; all of which is 
completely untrue. I really do want to hear the rational in requiring 
SDP and offer/answer. I don't see it as another other than a major 
hinderance towards compatibility and innovation rather than in favour of 
it (including for the SIP guys).

As I understand it, the resistance to opening the discussion again comes 
down to fear. Because we are afraid that if we decide to reopen this can 
o' worms that we won't be able to have consensus again and WebRTC will 
never happen. The fear comes from knowing people would never agree to 
another media related signaling format (correctly, as it's not even 
needed and counter productive to have one). I mean no disrespect when I 
ask this but is the argument against talking about it: "Let's all stick 
to something really bad because it's better than nothing at all, since 
we won't be able to come to a new agreement on a replacement to SDP 
(when we don't really need a replacement)?"

I'm really trying (hard) to understand the resistance to removing SDP or 
even discussing about something so fundamentally bad and flawed as SDP 
with offer/answer! What are the vested interests and rational in keeping 
something this bad as this intact?

I want WebRTC to succeed, but, sorry, SDP (in my opinion) has got to go.

-Robin

> Adam Roach <mailto:[email-masked]>
> 18 June, 2013 4:22 PM
>
>
> starting over would produce a different result. If anything, the 
> issues are more contentious now than they were in 2005.
>
> /a

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 18 Jun 2013 15:16:09 -0700

Adam, I think you're confused.  As Ted pointed out, there are two different
uses of SDP: 1.  as a control surface, 2. as a message format for
signalling.  SDPNG was trying to replace SDP for #2.  While I believe this
thread was started entirely focused on #1.  So you're talking about
different things.

So far the only time spent on trying to replace or avoid SDP for #1 has
been "comment 22", and to a lesser extent the proposal I just made for
adding 2 methods to PeerConnection (createLocalStream and
createRemoteStream).   I think it's incorrect to conclude that we should
never try to improve #1 just because other in the past failed to replace
#2.  They're very different.

I also don't think we should burn down WebRTC and start over, but despite
what some seem to think, we don't have to choose between "burn it down" and
"never improve it".  There are many options other than the two extremes.

By the way, a gentle reminder: SDP is not the only way to do #2.  I work on
a rather large system almost entirely build around Jingle, without a hint
of SDP, and it works just fine.  Much better than SDP would have, I think.
 Just because SDPNG didn't work out doesn't mean there will never be any
way other to do signalling than SDP.

On Tue, Jun 18, 2013 at 1:22 PM, Adam Roach <[email-masked]> wrote:

>> Creating something new that accomplishes that and is substantially better
>> than SDP seems like a long task to me.
>>
>
> Many men have died on that hill. I'm still sad about the colossal time and
> talent sink represented by these 61 pages:
>
> http://tools.ietf.org/id/**draft-ietf-mmusic-sdpng-08.txt<http://tools.ietf.org/id/draft-ietf-mmusic-sdpng-08.txt>
>
> starting over would produce a different result. If anything, the issues are
> more contentious now than they were in 2005.
>
> /a
>
> ______________________________**_________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/rtcweb<https://www.ietf.org/mailman/listinfo/rtcweb>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 18 Jun 2013 15:25:24 -0700

I agree with Peter, except for this bit:

On 18 June 2013 15:16, Peter Thatcher <[email-masked]> wrote:
> Adam, I think you're confused.

Adam is much harder to confuse than you think, or than he professes.

Speaking of burning it all down and starting over.  If you want a
house-related analogy, that's not quite correct.  It's refusing to
build an extension because the old house, while legally fit for
habitation, is falling down around your ears.  Since you only need
foundations, it's not that big a job (though I'll grant you that it's
bigger than many people realize, even with that smaller scope).

---

From: Roman Shpount <[email-masked]>
Date: Tue, 18 Jun 2013 18:40:32 -0400

One thing I got to mention is that there is already an API used internally
in current WebRTC implementations: Voice and Video Engines. Both of those
take external network transports (which also have their interfaces defined
and abstract ICE/SRTP/DTLS-SRTP) and allow to specify what codecs to be
used to receive/end media and how this media is encoded. The APIs provided
by these components are fairly typical for the media library APIs that are
used to build SIP and other real time communications clients. In fact these
very APIs were used by (at least at some point in the past) Skype, Google
Talk, Yahoo Messenger and number of other real time clients. I think the
best way to build a usable API is to try to wrap this in JavaScript as
closely as possible instead of building something extremely complicated on
top of them. If we do this, we can create something that will make the job
easier for both browser developers (no complex, hard to test, code which
implements O/A) and for application developers (clear API level contract
with clear mechanisms to control things happening with the media). We
already know that these APIs work for what we need. Let's stop trying to
hide them behind O/A complexity, and then try to invent multiple creative
ways to implement exactly the same functions through all the layers we
built on top.

_____________
Roman Shpount

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 00:51:55 +0200

2013/6/19 Roman Shpount <[email-masked]>:
> and abstract ICE/SRTP/DTLS-SRTP) and allow to specify what codecs to be used
> to receive/end media and how this media is encoded. The APIs provided by
> these components are fairly typical for the media library APIs that are used
> to build SIP and other real time communications clients. In fact these very
> APIs were used by (at least at some point in the past) Skype, Google Talk,
> Yahoo Messenger and number of other real time clients. I think the best way
> to build a usable API is to try to wrap this in JavaScript as closely as
> possible instead of building something extremely complicated on top of them.
> If we do this, we can create something that will make the job easier for
> both browser developers (no complex, hard to test, code which implements
> O/A) and for application developers (clear API level contract with clear
> mechanisms to control things happening with the media). We already know that
> these APIs work for what we need. Let's stop trying to hide them behind O/A
> complexity, and then try to invent multiple creative ways to implement
> exactly the same functions through all the layers we built on top.

Very good point. That exactly what we need: something like a JS
wrapper of the native internal media API.

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

---

From: Robin Raymond <[email-masked]>
Date: Tue, 18 Jun 2013 18:57:51 -0400

+1

Exactly. Spot on.

-Robin

> 18 June, 2013 6:51 PM
> Roman Shpount <mailto:[email-masked]>
> 18 June, 2013 6:40 PM
> One thing I got to mention is that there is already an API used 
> internally in current WebRTC implementations: Voice and Video Engines. 
> Both of those take external network transports (which also have their 
> interfaces defined and abstract ICE/SRTP/DTLS-SRTP) and allow to 
> specify what codecs to be used to receive/end media and how this media 
> is encoded. The APIs provided by these components are fairly typical 
> for the media library APIs that are used to build SIP and other real 
> time communications clients. In fact these very APIs were used by (at 
> least at some point in the past) Skype, Google Talk, Yahoo Messenger 
> and number of other real time clients. I think the best way to build a 
> usable API is to try to wrap this in JavaScript as closely as possible 
> instead of building something extremely complicated on top of them. If 
> we do this, we can create something that will make the job easier for 
> both browser developers (no complex, hard to test, code which 
> implements O/A) and for application developers (clear API level 
> contract with clear mechanisms to control things happening with the 
> media). We already know that these APIs work for what we need. Let's 
> stop trying to hide them behind O/A complexity, and then try to invent 
> multiple creative ways to implement exactly the same functions through 
> all the layers we built on top.
>
> _____________
> Roman Shpount
>
> Martin Thomson <mailto:[email-masked]>
> 18 June, 2013 6:25 PM
> Peter Thatcher <mailto:[email-masked]>
> 18 June, 2013 6:16 PM
> Adam, I think you're confused.  As Ted pointed out, there are two 
> different uses of SDP: 1.  as a control surface, 2. as a message 
> format for signalling.  SDPNG was trying to replace SDP for #2.  While 
> I believe this thread was started entirely focused on #1.  So you're 
> talking about different things.
>
> So far the only time spent on trying to replace or avoid SDP for #1 
> has been "comment 22", and to a lesser extent the proposal I just made 
> for adding 2 methods to PeerConnection (createLocalStream and 
> createRemoteStream).   I think it's incorrect to conclude that we 
> should never try to improve #1 just because other in the past failed 
> to replace #2.  They're very different.
>
> I also don't think we should burn down WebRTC and start over, but 
> despite what some seem to think, we don't have to choose between "burn 
> it down" and "never improve it".  There are many options other than 
> the two extremes.
>
>
>
> By the way, a gentle reminder: SDP is not the only way to do #2.  I 
> work on a rather large system almost entirely build around Jingle, 
> without a hint of SDP, and it works just fine.  Much better than SDP 
> would have, I think.  Just because SDPNG didn't work out doesn't mean 
> there will never be any way other to do signalling than SDP.
>
>
>
>

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 18 Jun 2013 22:36:19 -0700

Martin, you're right; that was overly harsh of me.  Adam, I apologize.
 I'll be civil in the future.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 06:34:43 +0000

Hi,

We need to be very clear what we talk about, or some people are always going to be confused :)

So, AFAIK, the discussion is about SDP O/A usage in the API, only in the API, and nowhere but the API.

Whatever people us on the wire is outside the scope.

Right?

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com)

-----Original Message-----
From: Peter Thatcher [[email-masked]]
To: Martin Thomson [[email-masked]]
CC: [email-masked] [[email-masked]]
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.

On Tue, Jun 18, 2013 at 3:25 PM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
I agree with Peter, except for this bit:

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 18 Jun 2013 23:49:09 -0700

Correct my if I'm wrong, but the API already leaves what goes over the wire
completely up to the JS app.  So we couldn't re-open a debate of "SDP or
not SDP" for the wire format, because there's nothing to debate.  We
already decided it would be left to the JS to decide.  The only thing left
to debate is the API.

Or am I wrong?

On Tue, Jun 18, 2013 at 11:34 PM, Christer Holmberg <
[email-masked]> wrote:

> Sent from *Windows* using *TouchDown* (www.nitrodesk.com)
>
> *From:* Peter Thatcher [[email-masked]]
> *To:* Martin Thomson [[email-masked]]
> *CC:* [email-masked] [[email-masked]]
> *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 06:59:36 +0000

Hi,

I have the same understanding as you. But, just to make sure everyone know what is discussed :)

Regards,

Christer

-----Original Message-----
From: Peter Thatcher [[email-masked]]
To: Christer Holmberg [[email-masked]]
CC: Martin Thomson [[email-masked]]; rtcweb_ietf.org [[email-masked]]
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
Correct my if I'm wrong, but the API already leaves what goes over the wire completely up to the JS app.  So we couldn't re-open a debate of "SDP or not SDP" for the wire format, because there's nothing to debate.  We already decided it would be left to the JS to decide.  The only thing left to debate is the API.

Or am I wrong?

On Tue, Jun 18, 2013 at 11:34 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Right?

Regards,

Christer

Sent from Windows using TouchDown (www.nitrodesk.com<http://www.nitrodesk.com>)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 10:38:35 +0200

> Whatever people us on the wire is outside the scope.

Hi Christer,

I do not dare to summarize what we request in a single response, and I
don't want to say something that "I didn't want to say" ;)

IMHO this thread clearly describes what we request, i.e. in these exact mails:

- http://www.ietf.org/mail-archive/web/rtcweb/current/msg07895.html
- http://www.ietf.org/mail-archive/web/rtcweb/current/msg07896.html
- http://www.ietf.org/mail-archive/web/rtcweb/current/msg07899.html

My "non-normative" summary:

I don't think that the discussion is just about "SDP O/A usage in the
API". We don't want a replacement for SDP, nor a new representation of
SDP, nor to deal with blob strings between the JS layer and the WebRTC
layer. In short we want something like a JS wrapper of the native
WebRTC API, to directly manage media/transport parameters and media
streams without having to pass a monolithic and unmanageable SDP blob
between the JS and the WebRTC layer. And once the JS makes all the API
calls to get the required media parameters, the JS can send them to
the remote peer in the way it prefers (which may be via a SDP created
by the JS app, or via an AJAX request for sending codecs/media-types
info followed by a WebSocket connection for sending ICE candidates one
by one, or serialized in JSON via a previously open DataChannel
session... or whatever mechanism available in the Web and browsers).

For sure, other participants in this thread can improve/fix my "summary".

Please. re-read the 3 links above, IMHO they should clearly describe
what we are requesting for :)

Best regards.

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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 08:42:02 +0000

Iñaki,

You are the one who requested the debate to be re-opened. Are you saying that I need to go through previous discussions to figure out what you want to debate - or to figure out what you THINK you want to debate? :)

Regards,

Christer

-----Original Message-----
From: Iñaki Baz Castillo [mailto:[email-masked]] 
Sent: 19. kesäkuuta 2013 11:39
To: Christer Holmberg
Cc: rtcweb_ietf.org
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Hi Christer,

I do not dare to summarize what we request in a single response, and I don't want to say something that "I didn't want to say" ;)

I don't think that the discussion is just about "SDP O/A usage in the API". We don't want a replacement for SDP, nor a new representation of SDP, nor to deal with blob strings between the JS layer and the WebRTC layer. In short we want something like a JS wrapper of the native WebRTC API, to directly manage media/transport parameters and media streams without having to pass a monolithic and unmanageable SDP blob between the JS and the WebRTC layer. And once the JS makes all the API calls to get the required media parameters, the JS can send them to the remote peer in the way it prefers (which may be via a SDP created by the JS app, or via an AJAX request for sending codecs/media-types info followed by a WebSocket connection for sending ICE candidates one by one, or serialized in JSON via a previously open DataChannel session... or whatever mechanism available in the Web and browsers).

Please. re-read the 3 links above, IMHO they should clearly describe what we are requesting for :)

Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 10:54:49 +0200

Hi Christer,

As far as I see I not alone in this venture :)

Anyhow, if others agree, take the paragraph in my previous mail (My
"non-normative" summary) as a small summary of what we want to debate
and propose.

Regards.

P.S: But IMHO the complete rationale for this request is better
described in the 3 links I told you ;)

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

---

From: Robin Raymond <[email-masked]>
Date: Wed, 19 Jun 2013 09:58:31 -0400

The trouble is not that we can choose to send whatever we want over the 
wire. I know we can. If the WebRTC API is left with SDP as it stands, 
I'll dissect the SDP from the browser, reinterpret and reconstruct on 
the SDP on the remote side. That is NOT the issue.

The summary of what I want/believe:
1) I want as close to raw access to RTP/ICE streams, media, sources, 
outputs, codecs as viable. Obviously doing the actual transmission, 
encoding/decoding from JS is not feasible (yet), nor is secure [ICE must 
occur for mutual agreement to exchange data between peers], but having 
controls for how these components are wired together is extremely 
feasible from JS and would allow immensely powerful apps to be produced 
from JS.
2) I don't want my primary interface to control media/RTP engines to be 
via obtaining or providing SDPs to the browser (or any alternative 
serialized format); especially given that SDP requires a round trip 
offer/answer to the remote party to affect change (e.g. it's entirely 
possible to do that stateless and one-sided). The SPD interface API is a 
monolithic do-everything serialized format to control an engine but 
extremely badly/poorly/short sighted (regardless if it is SDP or 
whatever instead), and it's wholly unneeded.
3) I don't want a replacement for SDP with another more "pretty" format 
like JSON.
4) I want no specified requirement from the browser to have any 
particular form of media negotiation API requirement what-so-ever 
(regardless if I can opt to substitute with my own format on the wire or 
not)
5) Using SDP with offer/answer build into the browser binary is a 
horribly BAD technical choice (even for SIP folks) and must be stopped, 
see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html

I too want to understand the rational for keeping something as bad as 
SDP with offer/answer as the primary mechanism for controlling the media 
components and interaction to those component and more importantly, I'd 
too would like to open debate to agreeing or not to provide a lower 
layer API rather than a media negotiation API as a complete substitute 
alternative to SDP with offer/answer.

If we can agree that it's far superior to have a lower level media/RTC 
component API rather than a media negotiation API, then we can propose 
what that API could look like (and there are people who have already 
have starting proposals). I'd throw my hat in the ring to propose such 
and API if necessary as I've written such engines from scratch before. 
But I don't want to waste time proposing ore reviewing such an API which 
will be summarily dismissed because people are so stuck on requiring a 
media negotiation API built into the browser binary, and specifically 
SDP with offer/answer in this case.

Anyone who argues that they need/want that simple SDP media negotiation 
API must understand that a lower level API would allow a wrapper API to 
produce the same WebRTC API the have today but be built entirely from 
JavaScript upon a lower level API. Thus they can have their "just 
add-milk" baking API. But those of us who need control of the raw 
ingredients beyond the "just add milk" can still innovate.

-Robin

> 19 June, 2013 2:49 AM
> Correct my if I'm wrong, but the API already leaves what goes over the 
> wire completely up to the JS app.  So we couldn't re-open a debate of 
> "SDP or not SDP" for the wire format, because there's nothing to 
> debate.  We already decided it would be left to the JS to decide.  The 
> only thing left to debate is the API.
>
> Or am I wrong?
>
>
>
>
> Christer Holmberg <mailto:[email-masked]>
> 19 June, 2013 2:34 AM
> Hi,
> Sent from */Windows/* using *TouchDown* (www.nitrodesk.com)
>
> 19 June, 2013 1:36 AM

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 08:46:36 -0700

I put some comments inline, but I'd like to offer a few suggestinos to all
of those in the "SDP Rebellion" fighting the "SDP Empire":

- A clear, succinct description of what you need and why is a lot more
useful and will lead to more progress than long rants about what you hate
an why.

- The WG usually likes use cases.  Do you have any real world uses cases
that the current API doesn't provider, or that makes painful?

- It would be helpful to minimize the diff to the current API that you
need.  Saying "blow up everything and do it how I want" is hard do swallow
(witness comment 22).  Saying "here's a small change that would relieve a
lot of pain" might make more progress (although even not's clear if even
that's possible).

On Wed, Jun 19, 2013 at 1:38 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> > We need to be very clear what we talk about, or some people are always
> going
> > to be confused :)
> >
> layer.

Please at least agree with Christer that this is about the API, not about
the signalling wire format.  The API already allows whatever signalling
wire format you want, and everything you mention from here on out is just
the API.  So please just say to Christer "yes, this is all about the API".
 It will make the rest of the discussion much more clear.

> In short we want something like a JS wrapper of the native
> WebRTC API,

I work on the WebRTC implementation in Chrome, and I don't know what you
mean by "native WebRTC API".  Such a thing does not really exist.  The
implementation has three different layers of abstraction, each of which you
might be referring to, but none of them which will give you what you want.
 The highest level uses SDP.  The lowest level gives you media bits, but no
ICE, SRTP, DTLS, or SCTP.  The middle layer gives you all those things
without SDP, but it still uses an abstract offer/answer for transport and
RTP setup (and even has a Jingle implementation on top of that).  None of
those give you what you want.  The "native WebRTC API" that you want to
wrap doesn't exist.

to directly manage media/transport parameters and media
> between the JS and the WebRTC layer.

That boils down to "the same power of the current API, without going
through SDP".  I think that's a clear requirement.  So why don't you just
say that?  Would save everyone a lot of reading and misunderstanding.

> session... or whatever mechanism available in the Web and browsers).
You already have that.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 18:10:07 +0200

Hi Peter, for now just some comments (I agree that more use cases and
other considerations must be provided):

> the signalling wire format.  The API already allows whatever signalling wire
> format you want,

IMHO that is not entirely true.

First of all, whichever the signaling protocol is, it must accomplish
with SDP O/A semantics (since it must carry a SDP and receive a SDP to
establish the communication).

Second: Indeed the current spec does not mandate what should be sent
in the wire. In practice that means we can use SIP over WebSocket,
XMPP/Jingle over HTTP, or whatever. But in practice it also means that
we must send a SDP in the wire. The SDP blob string can be
hex-encoded/escaped/mangled/whatever by the JS app, but the SDP blob
string generated by PeerConnection-A should arrive to
PeerConnection-B. And since such a SDP is generated by the WebRTC
stack and passed to the JS as an unmanageable blob string, the JS app
cannot properly deal with it.
So, currently WebRTC does not mandate the signaling protocol
in-the-wire, but it does mandate the media signaling protocol
in-the-wire (you need to pass a working SDP to the remote, sure),
something that constrains the signaling protocol itself.

> and everything you mention from here on out is just the
> API.  So please just say to Christer "yes, this is all about the API".  It
> will make the rest of the discussion much more clear.

Ok, this is all about the API :)

> those give you what you want.  The "native WebRTC API" that you want to wrap
> doesn't exist.

Ok, IMHO nobody is still requesting a specific JS API but just
describing the features and capabilities such an API must provide. The
"similar to native WebRTC API" is just a comment to help understanding
what we mean, but of course each browser is free to implement its
native API(s) as it prefers so the "JS wrapper" concept does not make
sense.

> That boils down to "the same power of the current API, without going through
> SDP".  I think that's a clear requirement.  So why don't you just say that?
> Would save everyone a lot of reading and misunderstanding.

You are right.

>> session... or whatever mechanism available in the Web and browsers).

Can I first send my codecs list, then (once the peer notifies me
codecs compatibility) send the codecs preference order, then my ICE
candidates and later (not just when ICE process terminates) signal the
peer a "OK" message so we both start the multimedia audio/video/data
communication, all of this with the current API?

(I mean without parsing the SDP blob and splitting it into blob fragments).

Best regards.

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 09:28:31 -0700

I might be wrong, but I tried reading and understanding your whole email,
and it seems to come down to "I don't want to use SDP or a different (JSON)
form of SDP".  That's a fine thing to request, but why don't you just say
that?  It would save everyone a lot of reading and confusion to be more
concise.

Or, if you have specific things you'd like to do but can't, what are they?
 I think that would help me, and others, understand more easily.  Use cases
would be helpful.

On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <[email-masked]> wrote:

> wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll
> dissect the SDP from the browser, reinterpret and reconstruct on the SDP on
> the remote side. That is NOT the issue.
>
> controls for how these components are wired together is extremely feasible
> from JS and would allow immensely powerful apps to be produced from JS.
>

What would you like to do that you can't do via SDP right now?  You said
this isn't just about working through SDP.  But I don't see anything
concrete you can't do right now with sufficient SDP
parsing/building/munging/hackery.

> extremely badly/poorly/short sighted (regardless if it is SDP or whatever
> instead), and it's wholly unneeded.
>

Short summary: "I don't want to use SDP".  Right?

> like JSON.

Short summary: "I don't want to use SDP or a different syntax for SDP".
 Right?

 4) I want no specified requirement from the browser to have any particular
> form of media negotiation API requirement what-so-ever (regardless if I can
> opt to substitute with my own format on the wire or not)
>

Short summary: "I don't want to use SDP or a different syntax for SDP".
 Right?

> 5) Using SDP with offer/answer build into the browser binary is a horribly
> BAD technical choice (even for SIP folks) and must be stopped, see:

Short summary: "I don't want to use SDP".  Right?

>
>
> I too want to understand the rational for keeping something as bad as SDP
> with offer/answer as the primary mechanism for controlling the media
> components and interaction to those component and more importantly, I'd too
> would like to open debate to agreeing or not to provide a lower layer API
> rather than a media negotiation API as a complete substitute alternative to
> SDP with offer/answer.
>
> component API rather than a media negotiation API, then we can propose what
> that API could look like (and there are people who have already have
> starting proposals). I'd throw my hat in the ring to propose such and API
> if necessary as I've written such engines from scratch before. But I don't
> want to waste time proposing ore reviewing such an API which will be
> summarily dismissed because people are so stuck on requiring a media
> negotiation API built into the browser binary, and specifically SDP with
> offer/answer in this case.
>

The WG may dislike and reject your proposal, but there's a bit of truth to
the old mathematically incorrect sports adage "you miss 100% of the shots
you don't take".

Anyone who argues that they need/want that simple SDP media negotiation API
> must understand that a lower level API would allow a wrapper API to produce
> the same WebRTC API the have today but be built entirely from JavaScript
>

That depends on how low-level you go.  If you go too low-level, it becomes
infeasible to do things correctly and performantly in JavaScript.

>  upon a lower level API. Thus they can have their "just add-milk" baking
> API. But those of us who need control of the raw ingredients beyond the
> "just add milk" can still innovate.
>
> -Robin
>
>
>    Peter Thatcher <[email-masked]>
>  19 June, 2013 2:49 AM
> wire completely up to the JS app.  So we couldn't re-open a debate of "SDP
> or not SDP" for the wire format, because there's nothing to debate.  We
>   Christer Holmberg <[email-masked]>
>  19 June, 2013 2:34 AM
>  Hi,
>
> going to be confused :)
>   Peter Thatcher <[email-masked]>
>  19 June, 2013 1:36 AM
>    Martin Thomson <[email-masked]>
>  18 June, 2013 6:25 PM
>    Peter Thatcher <[email-masked]>
>  18 June, 2013 6:16 PM
> different uses of SDP: 1.  as a control surface, 2. as a message format for
> By the way, a gentle reminder: SDP is not the only way to do #2.  I work
> on a rather large system almost entirely build around Jingle, without a
> hint of SDP, and it works just fine.  Much better than SDP would have, I
> think.  Just because SDPNG didn't work out doesn't mean there will never be
> any way other to do signalling than SDP.
>
>
>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 19 Jun 2013 09:36:20 -0700

I provided a use case that, unless one wants to write a bunch of SDP-munging JS state machine cannot be done.

The problem is that such use cases are either 1) ignored or 2) dismissed because of course if one writes said JS, they are possible with the current API

Matthew Kaufman

(Sent from my iPhone)

On Jun 19, 2013, at 9:28 AM, Peter Thatcher <[email-masked]> wrote:

> I might be wrong, but I tried reading and understanding your whole email, and it seems to come down to "I don't want to use SDP or a different (JSON) form of SDP".  That's a fine thing to request, but why don't you just say that?  It would save everyone a lot of reading and confusion to be more concise.  
> 
> Or, if you have specific things you'd like to do but can't, what are they?  I think that would help me, and others, understand more easily.  Use cases would be helpful.
> 
>> The trouble is not that we can choose to send whatever we want over the wire. I know we can. If the WebRTC API is left with SDP as it stands, I'll dissect the SDP from the browser, reinterpret and reconstruct on the SDP on the remote side. That is NOT the issue.
>> 
>> 1) I want as close to raw access to RTP/ICE streams, media, sources, outputs, codecs as viable. Obviously doing the actual transmission, encoding/decoding from JS is not feasible (yet), nor is secure [ICE must occur for mutual agreement to exchange data between peers], but having controls for how these components are wired together is extremely feasible from JS and would allow immensely powerful apps to be produced from JS.
> 
> What would you like to do that you can't do via SDP right now?  You said this isn't just about working through SDP.  But I don't see anything concrete you can't do right now with sufficient SDP parsing/building/munging/hackery.
> 
>  
>> 2) I don't want my primary interface to control media/RTP engines to be via obtaining or providing SDPs to the browser (or any alternative serialized format); especially given that SDP requires a round trip  offer/answer to the remote party to affect change (e.g. it's entirely possible to do that stateless and one-sided). The SPD interface API is a monolithic do-everything serialized format to control an engine but extremely badly/poorly/short sighted (regardless if it is SDP or whatever instead), and it's wholly unneeded.
> 
>> 3) I don't want a replacement for SDP with another more "pretty" format like JSON.
> 
> Short summary: "I don't want to use SDP or a different syntax for SDP".  Right?
> 
>> 4) I want no specified requirement from the browser to have any particular form of media negotiation API requirement what-so-ever (regardless if I can opt to substitute with my own format on the wire or not)
> 
> Short summary: "I don't want to use SDP or a different syntax for SDP".  Right?
>  
>> 5) Using SDP with offer/answer build into the browser binary is a horribly BAD technical choice (even for SIP folks) and must be stopped, see: http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html
> 
>> I too want to understand the rational for keeping something as bad as SDP with offer/answer as the primary mechanism for controlling the media components and interaction to those component and more importantly, I'd too would like to open debate to agreeing or not to provide a lower layer API rather than a media negotiation API as a complete substitute alternative to SDP with offer/answer.
>> 
>> If we can agree that it's far superior to have a lower level media/RTC component API rather than a media negotiation API, then we can propose what that API could look like (and there are people who have already  have starting proposals). I'd throw my hat in the ring to propose such and API if necessary as I've written such engines from scratch before. But I don't want to waste time proposing ore reviewing such an API which will be summarily dismissed because people are so stuck on requiring a media negotiation API built into the browser binary, and specifically SDP with offer/answer in this case.
> 
> 
> The WG may dislike and reject your proposal, but there's a bit of truth to the old mathematically incorrect sports adage "you miss 100% of the shots you don't take".
> 
> 
>> Anyone who argues that they need/want that simple SDP media negotiation API must understand that a lower level API would allow a wrapper API to produce the same WebRTC API the have today but be built entirely from JavaScript
> 
> That depends on how low-level you go.  If you go too low-level, it becomes infeasible to do things correctly and performantly in JavaScript.
>  
>> upon a lower level API. Thus they can have their "just add-milk" baking API. But those of us who need control of the raw ingredients beyond the "just add milk" can still innovate.
>> 
>> -Robin
>> 
>> 
>>> 	Peter Thatcher	19 June, 2013 2:49 AM
>>> 	Christer Holmberg	19 June, 2013 2:34 AM
>>> Hi,
>>>  
>>> 	Peter Thatcher	19 June, 2013 1:36 AM
>>> 	Martin Thomson	18 June, 2013 6:25 PM
>>> 	Peter Thatcher	18 June, 2013 6:16 PM
>>> Adam, I think you're confused.  As Ted pointed out, there are two different uses of SDP: 1.  as a control surface, 2. as a message format for signalling.  SDPNG was trying to replace SDP for #2.  While I believe this thread was started entirely focused on #1.  So you're talking about different things.
>>> 
>>> So far the only time spent on trying to replace or avoid SDP for #1 has been "comment 22", and to a lesser extent the proposal I just made for adding 2 methods to PeerConnection (createLocalStream and createRemoteStream).   I think it's incorrect to conclude that we should never try to improve #1 just because other in the past failed to replace #2.  They're very different.
>>> 
>>> I also don't think we should burn down WebRTC and start over, but despite what some seem to think, we don't have to choose between "burn it down" and "never improve it".  There are many options other than the two extremes.
>>> 
>>> 
>>> 
>>> By the way, a gentle reminder: SDP is not the only way to do #2.  I work on a rather large system almost entirely build around Jingle, without a hint of SDP, and it works just fine.  Much better than SDP would have, I think.  Just because SDPNG didn't work out doesn't mean there will never be any way other to do signalling than SDP.
>>> 
>>> 
>>> 
>>>

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 09:40:57 -0700

On Wed, Jun 19, 2013 at 9:10 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> wire

API calls must use the SDP O/A, but what goes on the wire doesn't have to
be.  With enough SDP hackery, you can do whatever you want over the wire,
including not use O/A semantics.

> PeerConnection-B.

A sufficiently smart chunk of JS could call
setLocalDescription/setRemoteDescription with SDP that it completely
created itself, and send whatever it wants over the wire.

> And since such a SDP is generated by the WebRTC

The JS parse the SDP from createOffer/createAnswer, get the info it needs,
make decisions and then serialize different SDP back down in
setLocalDescription/setRemoteDescription.  It's terribly ugly, but it works.

> something that constrains the signaling protocol itself.

It does not mandate SDP over the wire.  It's possible to write a JS app
that gets everything working with no SDP on the wire.  It's anything but
pretty, but it works.

> those give you what you want.  The "native WebRTC API" that you want to
wrap

> native API(s) as it prefers so the "JS wrapper" concept does not make

But you can't say "similar to native WebRTC API" because no such thing
exists.  You can't be similar to something that doesn't exist :).

> That boils down to "the same power of the current API, without going
through

> communication, all of this with the current API?

I think so, yes.

> (I mean without parsing the SDP blob and splitting it into blob
fragments).

Maybe... I don't know for sure.  But generally, anything beyond the most
basic uses of the API requires at least some SDP hackery, and advanced uses
require a lot.

Best regards.

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 09:49:48 -0700

I asked "is there something that can't be done without sufficient SDP
munging"?  You answered "I have something that can be done with sufficient
SDP munging".   OK.  But do you have something that *can't* be done with
SDP munging?

If there's nothing that can't be done with SDP munging, then this whole
thread boils down to "give us an API that has the same amount of control as
the current one, but without requiring SDP munging to do advanced things".
 And if that's is what is desired, then at least it can be clear and
concise.

On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman <[email-masked]> wrote:

> I provided a use case that, unless one wants to write a bunch of
> SDP-munging JS state machine cannot be done.
>
> The problem is that such use cases are either 1) ignored or 2) dismissed
> because of course if one writes said JS, they are possible with the current
> API
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
>  On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <[email-masked]>wrote:
>
>>
>> JavaScript

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 18:54:09 +0200

2013/6/19 Peter Thatcher <[email-masked]>

> What would you like to do that you can't do via SDP right now?  You said this isn't just about working through SDP.  But I don't see anything concrete you can't do right now with sufficient SDP par…

If the "solution" with the current API/model is "SDP
parsing/building/munging/hackery" then let me strongly say that:

*** I don't want SDP ***

:)

>
> The WG may dislike and reject your proposal

With all due respect,

And which proposal will the WG accept then? It's frustrating IMHO that
we still have no pro-SDP arguments in this long thread and still must
accept that the SDP model would be the chosen one. Does the silence
strategy mean "SDP usage was already voted two years ago, ignore
current complains"? That could be a good argument if during the last
TWO years we had *something* really good and usable based on the SDP
model, but we don't have that. Instead we have tons of drafts and
alternatives to make SDP fulfil WebRTC requirements, and none of them
is good.

IMHO current complains are based on the *experience* of the people
trying to make the SDP model work in WebRTC, including people that
were in favour of SDP two years ago and now have changed their mind
(like me).

> That depends on how low-level you go.  If you go too low-level, it becomes infeasible to do things correctly and performantly in JavaScript.

There are tons of bug in current WebRTC implementations. Yes, there
will be also bugs in future JS libraries dealing with WebRTC internals
(those we propose), but they can be potentially fixed without
requiring upgrading the browser, and without waiting for all the
browser vendors to fix/implement them.

And with all due respect, I don't agree at all with the "JavaScript
performance issue" that worries you, but I think that it is not up to
me to prove that a problem does not exist ;)

Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 18:58:29 +0200

2013/6/19 Peter Thatcher <[email-masked]>:
> But generally, anything beyond the most basic uses of the API requires at
> least some SDP hackery, and advanced uses require a lot.

Hi Peter, most of the solutions in your mail are basically based on
"blob SDP parsing/mangling/hackery". Can we agree that the current API
is a pain?:)

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 10:12:49 -0700

> "blob SDP parsing/mangling/hackery". Can we agree that the current API
Of course.  That's why I made a proposal that attempts to lessen the pain
(the NoPlan JS API).  I'm trying to help you :).

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 19:27:17 +0200

> (the NoPlan JS API).  I'm trying to help you :).

And don't you agree that the pain is even less if we entirely remove SDP?

And don't you agree that after two years we don't have yet a valid SDP
model for WebRTC so it makes no sense to keep it since it helps
nothing?

:)

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 10:29:26 -0700

> parsing/building/munging/hackery" then let me strongly say that:

It may be helpful to respond to your original request to the WG chairs with
something a little more clear, specific, concise, and actionable then your
original email.  I know many people reading this thread will just think
"what's this?  Oh, just more SDP ranting" and it will fall on deaf ears.

Also, explaining your use case and specific pain points may be helpful.

> And which proposal will the WG accept then?

I don't know.  Perhaps none of them.  It's possible we'll be stuck with SDP
munging forever.

But I think you'll maximize your chances of success by being clear with
what you need, propose digestible solutions, avoid being ranty, and not try
to blow it all up and start from scratch.  But I could be wrong.  Maybe
there's a better way.

> It's frustrating IMHO that

> were in favour of SDP two years ago and now have changed their mind

It may help you to understand this from the other side's perspective.  Many
people in the WG like SDP and want to use SDP for everything and don't want
to change SDP much, if at all.   And when someone comes through ranting
about SDP, they don't find that persuasive.

If there's new information gained in the last two years that might be
persuasive, present that.  But try to do it in clear, concise, way that
says "here's what I'm trying to do", "here's my experience", "here's my
pain", "here's how I think we can fix it".  That might be a lot more
persuasive.  Then again, it might now;  who knows? :)

>
>
> That depends on how low-level you go.  If you go too low-level, it
becomes infeasible to do things correctly and performantly in JavaScript.

Best regards.

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

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 19:31:57 +0200

Agreed with all you said, and thanks ;)

2013/6/19 Peter Thatcher <[email-masked]>:
> But I think you'll maximize your chances of success by being clear with what
> you need, propose digestible solutions, avoid being ranty, and not try to
> blow it all up and start from scratch.  But I could be wrong.  Maybe there's
> a better way.
>
>
>>
> persuasive, present that.  But try to do it in clear, concise, way that says
> "here's what I'm trying to do", "here's my experience", "here's my pain",
> "here's how I think we can fix it".  That might be a lot more persuasive.
> Then again, it might now;  who knows? :)
>
>
>
>

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 10:35:31 -0700

> And don't you agree that the pain is even less if we entirely remove SDP?
I don't think it's removal of SDP that you want.  I think what you want is
a way to use the API without using SDP.  If the SDP is still there, but you
don't have to use it, you're still happy, right?

> model for WebRTC so it makes no sense to keep it since it helps

My thinking is "choose your battles".  Fight for what you really need
rather than fighting everything at once.  If you want a way to bypass SDP,
fight for that.  If you fight to remove SDP altogether, you'll increase
your likelihood of being rejected.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 19:45:23 +0200

2013/6/19 Peter Thatcher <[email-masked]>:
> I don't think it's removal of SDP that you want.  I think what you want is a
> way to use the API without using SDP.  If the SDP is still there, but you

AFAIK no API in the world provides two ways to do the same, or at
least, no API provide them with the same "quality" and "affection".
Duplicating the work does not seem a long-term solution IMHO.

But I may be wrong :)

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

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 19 Jun 2013 10:46:12 -0700

On 6/19/2013 10:35 AM, Peter Thatcher wrote:
>
>
>
> On Wed, Jun 19, 2013 at 10:27 AM, Iñaki Baz Castillo <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     2013/6/19 Peter Thatcher <[email-masked]
>     <mailto:[email-masked]>>:
> I don't think it's removal of SDP that you want.  I think what you 
> want is a way to use the API without using SDP.  If the SDP is still 
> there, but you don't have to use it, you're still happy, right?

I want the offer/answer state machine to go away. I don't like an API 
that requires me to fight with it to get it to do what I want, no matter 
what kinds of things I put in (SDP, JSON, wahtever).

Why should I need to have the browser make an "offer" that I can then 
manipulate to turn into an "answer" just to get it to listen to some RTP 
and render it?

Matthew Kaufman

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 19 Jun 2013 18:01:34 +0000

Fighting the offer/answer machinery in the browser is always possible, but never easier.

I want an API that let's me tell the browser what to do, not engage in an argument with it until it is beaten into submission. I think an API that let's me tell the browser what to do will then also be much easier to extend to give me *more* control.

As an example, putting A and V over the same transport... Could be one more JS API, instead of a discussion at MMUSIC about how to encode that in our must-use SDP, followed by JS code I need to write to argue with the browser when it offers that but I want to turn it off, or vice versa.

Matthew Kaufman

(Sent from my iPhone)

On Jun 19, 2013, at 9:50 AM, "Peter Thatcher" <[email-masked]<mailto:[email-masked]>> wrote:

I asked "is there something that can't be done without sufficient SDP munging"?  You answered "I have something that can be done with sufficient SDP munging".   OK.  But do you have something that *can't* be done with SDP munging?

If there's nothing that can't be done with SDP munging, then this whole thread boils down to "give us an API that has the same amount of control as the current one, but without requiring SDP munging to do advanced things".  And if that's is what is desired, then at least it can be clear and concise.

On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman <[email-masked]<mailto:[email-masked]>> wrote:
I provided a use case that, unless one wants to write a bunch of SDP-munging JS state machine cannot be done.

Matthew Kaufman

(Sent from my iPhone)

On Jun 19, 2013, at 9:28 AM, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <[email-masked]<mailto:[email-masked]>> wrote:

-Robin

Peter Thatcher<mailto:[email-masked]>
19 June, 2013 2:49 AM
Correct my if I'm wrong, but the API already leaves what goes over the wire completely up to the JS app.  So we couldn't re-open a debate of "SDP or not SDP" for the wire format, because there's nothing to debate.  We already decided it would be left to the JS to decide.  The only thing left to debate is the API.

Or am I wrong?

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb
Christer Holmberg<mailto:[email-masked]>
19 June, 2013 2:34 AM
Hi,

Right?

Regards,

Christer

-----Original Message-----
From: Peter Thatcher [[email-masked]<mailto:[email-masked]>]
To: Martin Thomson [[email-masked]<mailto:[email-masked]>]
CC: [email-masked]<mailto:[email-masked]> [[email-masked]<mailto:[email-masked]>]
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb
Peter Thatcher<mailto:[email-masked]>
19 June, 2013 1:36 AM
Martin, you're right; that was overly harsh of me.  Adam, I apologize.  I'll be civil in the future.

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb
Martin Thomson<mailto:[email-masked]>
18 June, 2013 6:25 PM
I agree with Peter, except for this bit:

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

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

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

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

---

From: Robin Raymond <[email-masked]>
Date: Wed, 19 Jun 2013 14:05:29 -0400

Why aren't we using the JavaScript object model for control of 
components instead of serializing our control requests via SDP/whatever 
format and hoping that it worked?

-Robin

> 19 June, 2013 12:49 PM
> munging"?  You answered "I have something that can be done with 
> sufficient SDP munging".   OK.  But do you have something that *can't* 
> be done with SDP munging?
>
> If there's nothing that can't be done with SDP munging, then this 
> whole thread boils down to "give us an API that has the same amount of 
> control as the current one, but without requiring SDP munging to do 
> advanced things".  And if that's is what is desired, then at least it 
> can be clear and concise.
>
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Wed, 19 Jun 2013 18:04:32 +0000

All of what you say below is true, but this is entirely backwards from how web page authors are supposed to interact with the browser.

Imagine if displaying JPEG images in the page were equally possible, if you wanted to munge a bunch of strings, but otherwise you were out of luck.

Matthew Kaufman

(Sent from my iPhone)

On Jun 19, 2013, at 9:41 AM, "Peter Thatcher" <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Jun 19, 2013 at 9:10 AM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:
Hi Peter, for now just some comments (I agree that more use cases and

API calls must use the SDP O/A, but what goes on the wire doesn't have to be.  With enough SDP hackery, you can do whatever you want over the wire, including not use O/A semantics.

A sufficiently smart chunk of JS could call setLocalDescription/setRemoteDescription with SDP that it completely created itself, and send whatever it wants over the wire.

The JS parse the SDP from createOffer/createAnswer, get the info it needs, make decisions and then serialize different SDP back down in setLocalDescription/setRemoteDescription.  It's terribly ugly, but it works.

It does not mandate SDP over the wire.  It's possible to write a JS app that gets everything working with no SDP on the wire.  It's anything but pretty, but it works.

> native API(s) as it prefers so the "JS wrapper" concept does not make

But you can't say "similar to native WebRTC API" because no such thing exists.  You can't be similar to something that doesn't exist :).

I think so, yes.

> (I mean without parsing the SDP blob and splitting it into blob fragments).

Maybe... I don't know for sure.  But generally, anything beyond the most basic uses of the API requires at least some SDP hackery, and advanced uses require a lot.

Best regards.

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

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 11:07:22 -0700

That is precisely the argument that will be used against you to do
everything with SDP and only SDP.

---

From: Matthew Kaufman <[email-masked]>
Date: Wed, 19 Jun 2013 11:18:21 -0700

On 6/19/2013 11:05 AM, Robin Raymond wrote:
> components instead of serializing our control requests via 
> SDP/whatever format and hoping that it worked?
>
That's a great question. Have you read the CU-RTCWEB proposal? Is it any 
closer to what you imagined the RTCWEB API might be?

Matthew Kaufman

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 11:40:31 -0700

On Wed, Jun 19, 2013 at 10:46 AM, Matthew Kaufman <[email-masked]>wrote:

> On Wed, Jun 19, 2013 at 10:27 AM, Iñaki Baz Castillo <[email-masked]>wrote:
>
>  I don't think it's removal of SDP that you want.  I think what you want
> is a way to use the API without using SDP.  If the SDP is still there, but
> you don't have to use it, you're still happy, right?
>
>
> I want the offer/answer state machine to go away. I don't like an API that
> requires me to fight with it to get it to do what I want, no matter what
> kinds of things I put in (SDP, JSON, wahtever).
>
>
Are you demanding both adding what you want and removing what is there?
 Or,  if you could add everything you want, but leave what is currently
there (SDP O/A), would you be content?

> manipulate to turn into an "answer" just to get it to listen to some RTP

With my recent proposal (NoPlan JS API), you don't have to, at least not
for media streams.  You just tell the browser what to send with on the send
side, and then what to receive with on the receive side.  My proposal does
not cover transports, however.  It's an incremental improvement that
relieves some of the pain, but not all.

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 11:43:37 -0700

On Wed, Jun 19, 2013 at 11:04 AM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

>  All of what you say below is true, but this is entirely backwards from
> how web page authors are supposed to interact with the browser.
>
>

>  Imagine if displaying JPEG images in the page were equally possible, if
> you wanted to munge a bunch of strings, but otherwise you were out of luck.
>

Web page authors currently interact with the browser by munging lots of
URLs, HTML, CSS, and JS.  Why not SDP?  It's one more buzz word to add to
your resume.

(I'm trolling)

> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 19, 2013, at 9:41 AM, "Peter Thatcher" <[email-masked]>
> wrote:
>
>
>
>
>  API calls must use the SDP O/A, but what goes on the wire doesn't have
> to be.  With enough SDP hackery, you can do whatever you want over the
> wire, including not use O/A semantics.
>
>
>>
>  The JS parse the SDP from createOffer/createAnswer, get the info it
> needs, make decisions and then serialize different SDP back down in

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 11:46:37 -0700

On Wed, Jun 19, 2013 at 11:18 AM, Matthew Kaufman <[email-masked]>wrote:

> Why aren't we using the JavaScript object model for control of components
> instead of serializing our control requests via SDP/whatever format and
> hoping that it worked?
>

My "NoPlan JS API" proposal also allows control of components without
serialize control via a format, if the JS chooses to do so (SDP is still
there if JS wants).  It only does so for media streams, not for transports,
but it allows incremental improvement to the API.

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 11:50:51 -0700

On Wed, Jun 19, 2013 at 11:01 AM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

>  I want an API that let's me tell the browser what to do, not engage in
> an argument with it until it is beaten into submission. I think an API that
> let's me tell the browser what to do will then also be much easier to
> extend to give me *more* control.
>
>
My recent "NoPlan JS API" give you precisely that, at least for media
streams (not for transports).  But it's an incremental improvement, which
you have categorically rejected.

>  As an example, putting A and V over the same transport... Could be one
> more JS API, instead of a discussion at MMUSIC about how to encode that in
> our must-use SDP, followed by JS code I need to write to argue with the
> browser when it offers that but I want to turn it off, or vice versa.
>

Again, my "NoPlan JS API" give you exactly that, at least in theory.  No
one has implemented it yet :).

>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 19, 2013, at 9:50 AM, "Peter Thatcher" <[email-masked]>
> wrote:
>
> On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman <[email-masked]>wrote:
>
>>  The problem is that such use cases are either 1) ignored or 2)
>> dismissed because of course if one writes said JS, they are possible with
>> the current API
>>
>> Matthew Kaufman
>>
>> (Sent from my iPhone)
>>
>>    I might be wrong, but I tried reading and understanding your whole
>> email, and it seems to come down to "I don't want to use SDP or a different
>> (JSON) form of SDP".  That's a fine thing to request, but why don't you
>> just say that?  It would save everyone a lot of reading and confusion to be
>> more concise.
>>
>>   Or, if you have specific things you'd like to do but can't, what are
>> they?  I think that would help me, and others, understand more easily.  Use
>> cases would be helpful.
>>
>>> encoding/decoding from JS is not feasible (yet), nor is secure [ICE
>>> must occur for mutual agreement to exchange data between peers], but having
>>  What would you like to do that you can't do via SDP right now?  You
>> said this isn't just about working through SDP.  But I don't see anything
>> The WG may dislike and reject your proposal, but there's a bit of truth
>> to the old mathematically incorrect sports adage "you miss 100% of the
>> shots you don't take".
>>
>>
>>>  upon a lower level API. Thus they can have their "just add-milk"
>>> baking API. But those of us who need control of the raw ingredients beyond
>>> the "just add milk" can still innovate.
>>>
>>> -Robin
>>>
>>>
>>>    Correct my if I'm wrong, but the API already leaves what goes over
>>> the wire completely up to the JS app.  So we couldn't re-open a debate of
>>> "SDP or not SDP" for the wire format, because there's nothing to debate.
>>>  We already decided it would be left to the JS to decide.  The only thing
>>> left to debate is the API.
>>>
>>>  Or am I wrong?
>>>
>>>
>>>
>>>
>>> has been "comment 22", and to a lesser extent the proposal I just made for
>>> despite what some seem to think, we don't have to choose between "burn it
>>> down" and "never improve it".  There are many options other than the two
>>> extremes.
>>>
>>>
>>>
>>> work on a rather large system almost entirely build around Jingle, without
>>> a hint of SDP, and it works just fine.  Much better than SDP would have, I

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 19 Jun 2013 19:47:39 +0000

Hi,

>>> Why aren't we using the JavaScript object model for control of components instead of serializing our control requests via SDP/whatever format and hoping that it worked?
>>>
>> That's a great question. Have you read the CU-RTCWEB proposal? Is it any closer to what you imagined the RTCWEB API might be?
>
> My "NoPlan JS API" proposal also allows control of components without serialize control via a format, if the JS chooses to do so (SDP is still there if JS wants).  It only does so for media streams, not for transports, but it allows incremental improvement to the API.

So, IF we decide to remove SDP and Offer/Answer, we'll end up arguing about "Plan C(U) vs No Plan"? :)

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 19 Jun 2013 12:50:13 -0700

On Wed, Jun 19, 2013 at 12:47 PM, Christer Holmberg <
[email-masked]> wrote:

> >> That's a great question. Have you read the CU-RTCWEB proposal? Is it
> any closer to what you imagined the RTCWEB API might be?
> >
I think we already are :).

---

From: Robin Raymond <[email-masked]>
Date: Wed, 19 Jun 2013 16:08:10 -0400

Yes, I have looked at CU-RTCWeb. It is definitely closer and uses object 
models rather than serialization -- a definite step in the right 
direction. Should anyone take up the effort to propose another workable 
alternative to this current SDP situation (or an incremental improvement 
approach), I would recommend they read it for inspiration.

One thing that is missing for CU-RTCWeb is the JavaScript shim that 
proves that the SDP / SIP folks can produce a reasonable implementation 
for the simple API they do need to interface with SIP/SDP based devices 
and infrastructure. I know it shouldn't be Skype job to produce that 
shim but I don't think anyone will adopt anything unless it's 
demonstrably easy for the SIP world (unless I misunderstand their 
objections).

-Robin

> Matthew Kaufman <mailto:[email-masked]>
> 19 June, 2013 2:18 PM
> Robin Raymond <mailto:[email-masked]>
> 19 June, 2013 2:05 PM
>
> Matthew Kaufman <mailto:[email-masked]>
> 19 June, 2013 12:36 PM
> dismissed because of course if one writes said JS, they are possible 
> with the current API
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
>> email, and it seems to come down to "I don't want to use SDP or a 
>> different (JSON) form of SDP".  That's a fine thing to request, but 
>> why don't you just say that?  It would save everyone a lot of reading 
>> and confusion to be more concise.
>>
>> they?  I think that would help me, and others, understand more 
>> easily.  Use cases would be helpful.
>>
>>     The trouble is not that we can choose to send whatever we want
>>     over the wire. I know we can. If the WebRTC API is left with SDP
>>     as it stands, I'll dissect the SDP from the browser, reinterpret
>>     and reconstruct on the SDP on the remote side. That is NOT the issue.
>>
>>     1) I want as close to raw access to RTP/ICE streams, media,
>>     sources, outputs, codecs as viable. Obviously doing the actual
>>     transmission, encoding/decoding from JS is not feasible (yet),
>>     nor is secure [ICE must occur for mutual agreement to exchange
>>     data between peers], but having controls for how these components
>>     are wired together is extremely feasible from JS and would allow
>>     immensely powerful apps to be produced from JS.
>>
>>
>> said this isn't just about working through SDP.  But I don't see 
>> anything concrete you can't do right now with sufficient SDP 
>>     2) I don't want my primary interface to control media/RTP engines
>>     to be via obtaining or providing SDPs to the browser (or any
>>     alternative serialized format); especially given that SDP
>>     requires a round trip offer/answer to the remote party to affect
>>     change (e.g. it's entirely possible to do that stateless and
>>     one-sided). The SPD interface API is a monolithic do-everything
>>     serialized format to control an engine but extremely
>>     badly/poorly/short sighted (regardless if it is SDP or whatever
>>     (regardless if I can opt to substitute with my own format on the
>>     wire or not)
>>
>>
>>     horribly BAD technical choice (even for SIP folks) and must be
>>     stopped, see:
>>     I too want to understand the rational for keeping something as
>>     bad as SDP with offer/answer as the primary mechanism for
>>     controlling the media components and interaction to those
>>     component and more importantly, I'd too would like to open debate
>>     to agreeing or not to provide a lower layer API rather than a
>>     media negotiation API as a complete substitute alternative to SDP
>>     with offer/answer.
>>
>>     If we can agree that it's far superior to have a lower level
>>     media/RTC component API rather than a media negotiation API, then
>>     we can propose what that API could look like (and there are
>>     people who have already have starting proposals). I'd throw my
>>     hat in the ring to propose such and API if necessary as I've
>>     written such engines from scratch before. But I don't want to
>>     waste time proposing ore reviewing such an API which will be
>>     summarily dismissed because people are so stuck on requiring a
>>     media negotiation API built into the browser binary, and
>>     specifically SDP with offer/answer in this case.
>>
>>
>>
>> The WG may dislike and reject your proposal, but there's a bit of 
>> truth to the old mathematically incorrect sports adage "you miss 100% 
>> of the shots you don't take".
>>
>>
>>     Anyone who argues that they need/want that simple SDP media
>>     negotiation API must understand that a lower level API would
>>     allow a wrapper API to produce the same WebRTC API the have today
>>     but be built entirely from JavaScript
>>
>>
>>     baking API. But those of us who need control of the raw
>>>     Correct my if I'm wrong, but the API already leaves what goes
>>>     over the wire completely up to the JS app.  So we couldn't
>>>     re-open a debate of "SDP or not SDP" for the wire format,
>>>     because there's nothing to debate.  We already decided it would
>>>     be left to the JS to decide.  The only thing left to debate is
>>>     the API.
>>>
>>>     Or am I wrong?
>>>
>>>
>>>
>>>
>>>     [email-masked] <mailto:[email-masked]>
>>>     So, AFAIK, the discussion is about SDP O/A usage in the API,
>>>     only in the API, and nowhere but the API.
>>>     Sent from */Windows/* using *TouchDown* (www.nitrodesk.com
>>>     <http://www.nitrodesk.com>)
>>>
>>>     *From:* Peter Thatcher [[email-masked]
>>>     <mailto:[email-masked]>]
>>>     *To:* Martin Thomson [[email-masked]
>>>     <mailto:[email-masked]>]
>>>     *CC:* [email-masked] <mailto:[email-masked]> [[email-masked]
>>>     <mailto:[email-masked]>]
>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>
>>>     [email-masked] <mailto:[email-masked]>
>>>     Adam, I think you're confused.  As Ted pointed out, there are
>>>     two different uses of SDP: 1.  as a control surface, 2. as a
>>>     message format for signalling.  SDPNG was trying to replace SDP
>>>     for #2.  While I believe this thread was started entirely
>>>     focused on #1.  So you're talking about different things.
>>>
>>>     So far the only time spent on trying to replace or avoid SDP for
>>>     #1 has been "comment 22", and to a lesser extent the proposal I
>>>     just made for adding 2 methods to PeerConnection
>>>     (createLocalStream and createRemoteStream).   I think it's
>>>     incorrect to conclude that we should never try to improve #1
>>>     just because other in the past failed to replace #2.  They're
>>>     very different.
>>>
>>>     I also don't think we should burn down WebRTC and start over,
>>>     but despite what some seem to think, we don't have to choose
>>>     between "burn it down" and "never improve it".  There are many
>>>     options other than the two extremes.
>>>
>>>
>>>
>>>     By the way, a gentle reminder: SDP is not the only way to do #2.
>>>      I work on a rather large system almost entirely build around
>>>     Jingle, without a hint of SDP, and it works just fine.  Much
>>>     better than SDP would have, I think.  Just because SDPNG didn't
>>>     work out doesn't mean there will never be any way other to do
>>>     signalling than SDP.
>>>
>>>
>>>
>>>
>>>     [email-masked] <mailto:[email-masked]>
>> [email-masked] <mailto:[email-masked]>
> 19 June, 2013 12:28 PM
> email, and it seems to come down to "I don't want to use SDP or a 
> different (JSON) form of SDP".  That's a fine thing to request, but 
> why don't you just say that?  It would save everyone a lot of reading 
> and confusion to be more concise.
>
> they?  I think that would help me, and others, understand more easily. 
>  Use cases would be helpful.
>
>     The trouble is not that we can choose to send whatever we want
>     over the wire. I know we can. If the WebRTC API is left with SDP
>     as it stands, I'll dissect the SDP from the browser, reinterpret
>     and reconstruct on the SDP on the remote side. That is NOT the issue.
>
>     1) I want as close to raw access to RTP/ICE streams, media,
>     sources, outputs, codecs as viable. Obviously doing the actual
>     transmission, encoding/decoding from JS is not feasible (yet), nor
>     is secure [ICE must occur for mutual agreement to exchange data
>     between peers], but having controls for how these components are
>     wired together is extremely feasible from JS and would allow
>     immensely powerful apps to be produced from JS.
>
>
> said this isn't just about working through SDP.  But I don't see 
> anything concrete you can't do right now with sufficient SDP 
>     2) I don't want my primary interface to control media/RTP engines
>     to be via obtaining or providing SDPs to the browser (or any
>     alternative serialized format); especially given that SDP requires
>     a round trip offer/answer to the remote party to affect change
>     (e.g. it's entirely possible to do that stateless and one-sided).
>     The SPD interface API is a monolithic do-everything serialized
>     format to control an engine but extremely badly/poorly/short
>     sighted (regardless if it is SDP or whatever instead), and it's
>     wholly unneeded.
>
>
>     (regardless if I can opt to substitute with my own format on the
>     wire or not)
>
>
>     horribly BAD technical choice (even for SIP folks) and must be
>     stopped, see:
>     I too want to understand the rational for keeping something as bad
>     as SDP with offer/answer as the primary mechanism for controlling
>     the media components and interaction to those component and more
>     importantly, I'd too would like to open debate to agreeing or not
>     to provide a lower layer API rather than a media negotiation API
>     as a complete substitute alternative to SDP with offer/answer.
>
>     If we can agree that it's far superior to have a lower level
>     media/RTC component API rather than a media negotiation API, then
>     we can propose what that API could look like (and there are people
>     who have already have starting proposals). I'd throw my hat in the
>     ring to propose such and API if necessary as I've written such
>     engines from scratch before. But I don't want to waste time
>     proposing ore reviewing such an API which will be summarily
>     dismissed because people are so stuck on requiring a media
>     negotiation API built into the browser binary, and specifically
> The WG may dislike and reject your proposal, but there's a bit of 
> truth to the old mathematically incorrect sports adage "you miss 100% 
> of the shots you don't take".
>
>
>     Anyone who argues that they need/want that simple SDP media
>     negotiation API must understand that a lower level API would allow
>     a wrapper API to produce the same WebRTC API the have today but be
>     built entirely from JavaScript
>
>
>     baking API. But those of us who need control of the raw
>>     Correct my if I'm wrong, but the API already leaves what goes
>>     over the wire completely up to the JS app.  So we couldn't
>>     re-open a debate of "SDP or not SDP" for the wire format, because
>>     there's nothing to debate.  We already decided it would be left
>>     to the JS to decide.  The only thing left to debate is the API.
>>
>>     Or am I wrong?
>>
>>
>>
>>
>>     [email-masked] <mailto:[email-masked]>
>>     Sent from */Windows/* using *TouchDown* (www.nitrodesk.com
>>     <http://www.nitrodesk.com>)
>>
>>     *From:* Peter Thatcher [[email-masked]
>>     <mailto:[email-masked]>]
>>     *To:* Martin Thomson [[email-masked]
>>     <mailto:[email-masked]>]
>>     *CC:* [email-masked] <mailto:[email-masked]> [[email-masked]
>>     <mailto:[email-masked]>]
>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>>     [email-masked] <mailto:[email-masked]>
>>     format for signalling.  SDPNG was trying to replace SDP for #2.
>>      While I believe this thread was started entirely focused on #1.
>>      So you're talking about different things.
>>
>>     So far the only time spent on trying to replace or avoid SDP for
>>     #1 has been "comment 22", and to a lesser extent the proposal I
>>     just made for adding 2 methods to PeerConnection
>>     (createLocalStream and createRemoteStream).   I think it's
>>     incorrect to conclude that we should never try to improve #1 just
>>     because other in the past failed to replace #2.  They're very
>>     different.
>>
>>     despite what some seem to think, we don't have to choose between
>>     "burn it down" and "never improve it".  There are many options
>>     other than the two extremes.
>>
>>
>>
>>     By the way, a gentle reminder: SDP is not the only way to do #2.
>>      I work on a rather large system almost entirely build around
>>     Jingle, without a hint of SDP, and it works just fine.  Much
>>     better than SDP would have, I think.  Just because SDPNG didn't
>>     work out doesn't mean there will never be any way other to do
>>     signalling than SDP.
>>
>>
>>
>>
>>     [email-masked] <mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Jun 2013 13:15:49 -0700

On 19 June 2013 13:08, Robin Raymond <[email-masked]> wrote:

> One thing that is missing for CU-RTCWeb is the JavaScript shim that proves
> that the SDP / SIP folks can produce a reasonable implementation for the
> simple API they do need to interface with SIP/SDP based devices and
> infrastructure. I know it shouldn't be Skype job to produce that shim but I
> don't think anyone will adopt anything unless it's demonstrably easy for
> the SIP world (unless I misunderstand their objections).

We sketched out some designs for this that indicated that it is at least
feasible.  It's not that easy though - prancer in particular complicates
things considerably - and we managed to find more important things to spend
time on before we could do anything significant.  Full compliance with the
specification, rather than just an SDP implementation, is not something
that is easily replicated.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Wed, 19 Jun 2013 23:22:44 +0200

2013/6/19 Peter Thatcher <[email-masked]>:
> With my recent proposal (NoPlan JS API), you don't have to, at least not for
> media streams.  You just tell the browser what to send with on the send

Hi Peter, may you could reply to my mail about NoPlan:

  http://www.ietf.org/mail-archive/web/rtcweb/current/msg07871.html

:)

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Jun 2013 04:55:59 +0000

Hi,

>>> My "NoPlan JS API" proposal also allows control of components without serialize control via a format, if the JS chooses to 
>>> do so (SDP is still there if JS wants).  It only does so for media streams, not for transports, but it allows incremental improvement to the API.

At the virtual interim, the Plan A and Plan B folks were asked to sit down and try to come up with a compromise "Plan AB" solution.

I guess it would be good if people that don't want SDP could try to come up with a compromise "CU No Plan" solution :)

Regards,

Christer

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Jun 2013 15:25:37 +0000

IMHO the re-opening of the debate on "SDP or not SDP" is not the right approach to making progress at this moment in time as it would only serve to slow the process even further and reopen all the old arguments.

The agreement albeit a W3C agreement was to assess the requirements for a lower level API (Without SDP) once a first release of WebRTC is achieved and I think we should not reverse that agreement there was strong consensus on that at the time.

However I think we should have a close look at our priorities and what we really need to get to what would effectively be WebRTC 1.0. My feeling is that we are trying to do too much.

Let's take a short pause for breath and think about what we really need for a successful WebRTC 1.0 as I think we are maybe focused on the wrong issues and we seem to have got diverted from the priorities set in the charter (http://datatracker.ietf.org/wg/rtcweb/charter/).

For example to make even basic WebRTC applications easily deployable we need to resolve the firewall issues as stated in the charter (bullet 3). We don't even have an adopted draft for that yet but I hope that can be changed very soon.  If WebRTC apps work from my home but not when I check in to a hotel or go to my office then we really have a problem even with the most basic audio only apps.

In conclusion, let's focus on the requirements specified in the charter, concentrate on more basic issues relating to security and deployment that really need to be solved now. Some of the more sophisticated features such as SSRC signaling and bundling could become part of WebRTC 2.0.

Let's make WebRTC 1.0 successful as soon as possible.

Regards
Andy

> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Iñaki Baz Castillo
> Sent: 18 June 2013 17:36
> To: [email-masked]
> Subject: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Jun 2013 17:32:43 +0200

On 06/19/2013 10:15 PM, Martin Thomson wrote:
> On 19 June 2013 13:08, Robin Raymond <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     One thing that is missing for CU-RTCWeb is the JavaScript shim
>     that proves that the SDP / SIP folks can produce a reasonable
>     implementation for the simple API they do need to interface with
>     SIP/SDP based devices and infrastructure. I know it shouldn't be
>     Skype job to produce that shim but I don't think anyone will adopt
>     anything unless it's demonstrably easy for the SIP world (unless I
>     misunderstand their objections).
>
>
> We sketched out some designs for this that indicated that it is at 
> least feasible.  It's not that easy though - prancer in particular 
> complicates things considerably - and we managed to find more 
> important things to spend time on before we could do anything 
> significant.  Full compliance with the specification, rather than just 
> an SDP implementation, is not something that is easily replicated.

I think interoperability with an application written to the 
implementations that are based on the current specifications (that is - 
a Javascript application that you could load into both Chrome and your 
demo of CU-RTCWeb, using a JS shim in your demo, and have them talk to 
each other) would be a pretty compelling argument.

If it didn't use PR-Answer, that would only detract a little bit from 
the compellingness.

---

From: Roman Shpount <[email-masked]>
Date: Thu, 20 Jun 2013 11:47:06 -0400

My question is, would this WebRTC 1.0 API ever become a standard without
SDP portion of it being well defined? Right not this is an opaque blob with
little or no definition attached to it. It can be modified and extended in
non-compatible way by an implementer with no changes to the actual external
API surface. I do not think we are anywhere near the working API unless we
specify exactly what SDP can be generated WebRTC compliant browser and what
is an SDP acceptable to WebRTC compliant browser and lock it down. Ideally
it should be defined in a way that can be extended in the future (ie
forcing only certain features to be used via some sort of version based
initialization).
_____________
Roman Shpount

On Thu, Jun 20, 2013 at 11:25 AM, Hutton, Andrew <
[email-masked]> wrote:

>
> IMHO the re-opening of the debate on "SDP or not SDP" is not the right
> approach to making progress at this moment in time as it would only serve
> to slow the process even further and reopen all the old arguments.
>
> The agreement albeit a W3C agreement was to assess the requirements for a
> lower level API (Without SDP) once a first release of WebRTC is achieved
> and I think we should not reverse that agreement there was strong consensus
> on that at the time.
>
> However I think we should have a close look at our priorities and what we
> really need to get to what would effectively be WebRTC 1.0. My feeling is
> that we are trying to do too much.
>
> Let's take a short pause for breath and think about what we really need
> for a successful WebRTC 1.0 as I think we are maybe focused on the wrong
> issues and we seem to have got diverted from the priorities set in the
> charter (http://datatracker.ietf.org/wg/rtcweb/charter/).
>
> For example to make even basic WebRTC applications easily deployable we
> need to resolve the firewall issues as stated in the charter (bullet 3). We
> don't even have an adopted draft for that yet but I hope that can be
> changed very soon.  If WebRTC apps work from my home but not when I check
> in to a hotel or go to my office then we really have a problem even with
> the most basic audio only apps.
>
> In conclusion, let's focus on the requirements specified in the charter,
> concentrate on more basic issues relating to security and deployment that
> really need to be solved now. Some of the more sophisticated features such
> as SSRC signaling and bundling could become part of WebRTC 2.0.
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 20 Jun 2013 15:57:20 +0000

It must be possible for a third party to implement a compatible browser without referring to anything but the chain of normative references. At the present time, this is not the case, and would be grounds for not ratifying the specification within W3C.

Matthew Kaufman

________________________________
From: [email-masked] [[email-masked]] on behalf of Roman Shpount [[email-masked]]
Sent: Thursday, June 20, 2013 8:47 AM
To: Hutton, Andrew
Cc: [email-masked]
Subject: Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate to be re-opened .

My question is, would this WebRTC 1.0 API ever become a standard without SDP portion of it being well defined?

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Jun 2013 18:15:13 +0200

2013/6/20 Harald Alvestrand <[email-masked]>:
> I think interoperability with an application written to the implementations
> that are based on the current specifications (that is - a Javascript
> application that you could load into both Chrome and your demo of CU-RTCWeb,
> using a JS shim in your demo, and have them talk to each other) would be a
> pretty compelling argument.

Hi Harald, with all due respect:

So, it seems that the current SDP-based spec is God, and if somebody
wants to propose another alternative, it must be compatible with God,
regardless that God is not yet a proven standard and what some of us
are asserting is that God is bad, very bad. Am I right?

IMHO it would be much more interesting a JS demo that takes the SDP
generated by Chrome and "converts" it into a Jingle XML session
description (I mean XEP-0167), and that can interoperate (via XMPP
over WebSocket or whatever) with a XMPP/Jingle endpoint by
incrementally sending/receiving transport (ICE stuff) and media
capabilities (as XEP-0167 allows) in different XMPP messages.

And it would also be interesting a JS demo that interoperates with a
SIP gateway and is able to perform the "hold" / "unhold" feature so
widely extended in SIP world (via reINVITE with a=inactive/sendonly
and 200 "OK" with a=inactive/recvonly).

It seems that we must prove how bad SDP is while the fact is that
those in favour of the SDP-based model should demonstrate how
"flexible" and powerful it is. As far as we can see in the spec
development, SDP does not seem to be so good and hence it should be
questionable IMHO.

Just my opinion.

Best regards.

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Jun 2013 16:28:40 +0000

This has been debated many times in the working group and consensus in the past was to move forward with an SDP based API so evidence suggests that the majority of the working groups (IETF & W3C) believe it is possible to have a WebRTC 1.0 API which uses SDP.

If we need to rigorously define an SDP profile for RTCWEB then that is what we should be doing rather like we do for RTP in the rtp-usage draft. In fact I think somebody started that work but there has been very little discussion in that direction.

It seems to me we are making things more difficult than they need to be by trying to make complex extensions to SDP as part of WebRTC 1.0 which means we have a moving target with regards to SDP. 

If we keep things simple there is more chance of success.

Regards
Andy

> From: Roman Shpount [mailto:[email-masked]]
> Sent: 20 June 2013 16:47
> To: Hutton, Andrew
> Cc: [email-masked]
> My question is, would this WebRTC 1.0 API ever become a standard
> without SDP portion of it being well defined? Right not this is an
> opaque blob with little or no definition attached to it. It can be
> modified and extended in non-compatible way by an implementer with no
> changes to the actual external API surface. I do not think we are
> anywhere near the working API unless we specify exactly what SDP can be
> generated WebRTC compliant browser and what is an SDP acceptable to
> WebRTC compliant browser and lock it down. Ideally it should be defined
> in a way that can be extended in the future (ie forcing only certain
> features to be used via some sort of version based initialization).
> 
> _____________
> Roman Shpount
> 
> On Thu, Jun 20, 2013 at 11:25 AM, Hutton, Andrew
> <[email-masked]> wrote:
> 
> approach to making progress at this moment in time as it would only
> serve to slow the process even further and reopen all the old
> arguments.
> 
> The agreement albeit a W3C agreement was to assess the requirements for
> a lower level API (Without SDP) once a first release of WebRTC is
> achieved and I think we should not reverse that agreement there was
> strong consensus on that at the time.
> 
> However I think we should have a close look at our priorities and what
> we really need to get to what would effectively be WebRTC 1.0. My
> feeling is that we are trying to do too much.
> 
> for a successful WebRTC 1.0 as I think we are maybe focused on the
> wrong issues and we seem to have got diverted from the priorities set
> in the charter (http://datatracker.ietf.org/wg/rtcweb/charter/).
> 
> need to resolve the firewall issues as stated in the charter (bullet
> 3). We don't even have an adopted draft for that yet but I hope that
> can be changed very soon.  If WebRTC apps work from my home but not
> when I check in to a hotel or go to my office then we really have a
> problem even with the most basic audio only apps.
> 
> In conclusion, let's focus on the requirements specified in the
> charter, concentrate on more basic issues relating to security and
> deployment that really need to be solved now. Some of the more
> sophisticated features such as SSRC signaling and bundling could become
> part of WebRTC 2.0.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Jun 2013 18:41:53 +0200

> If we keep things simple there is more chance of success.

Hi Andrew, please don't take me wrong but:

So the only arguments pro-SDP are "it was debated many times" (it
seems it does not matter than many people that agreed then have
changed their mind after getting experience), "let do something simple
for now based on SDP, something that allows a simple PSTN call" (so
SDP will be here forever and any future WebRTC app will have to deal
with SDP nightmares and will be subject to its O/A model, forever and
ever).

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

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 20 Jun 2013 09:58:16 -0700

"Some of the more sophisticated features such as SSRC signaling and
bundling could become part of WebRTC 2.0"

That's tantamount to saying Plan A vs. Plan B vs. NoPlan is part of WebRTC
2.0.  Is that what you're suggesting?

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Jun 2013 17:00:14 +0000

> with SDP nightmares and will be subject to its O/A model, forever and

No it is not the only argument it is just stating the fact that we had the debate previously in which the arguments were made and the balance was in favor of SDP.  As I said I don't really want to reopen all the old arguments.

I am saying that people are getting frustrated and considering a change because we are concentrating on extending SDP rather than keeping things simple and focusing on the current deliverables as specified in the charter.  If we had not gone this route then I think we would have more success and people would not have become so frustrated.

Changing fundamental decisions at a late stage is not a major deal and comes with great costs so needs even more justification than the original decision did.

Andy.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 20 Jun 2013 19:03:53 +0200

> are asserting is that God is bad, very bad. Am I right?

Inaki, that's quite a bit below your usual standard of argument.

> capabilities (as XEP-0167 allows) in different XMPP messages.

You find it interesting. I'm sure you have a particular XMPP/Jingle
endpoint in mind that you want to connect to.

Create one. Or try, and share with us why it did not work.

> and 200 "OK" with a=inactive/recvonly).

We have people who have demonstrated interoperability with SIP softphones.
Some of them are on this list.
Can they tell us what happened when they tried?

> development, SDP does not seem to be so good and hence it should be

The purported value of SDP is interoperability (and the idea that specs
defining what it's supposed to mean already exist).
If you can show (by code) that this purported value can be achieved
without SIP, you have an argument.

If you cannot show anything, you have words.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Jun 2013 10:16:46 -0700

Peter Thatcher said: 
"Some of the more sophisticated features such as SSRC signaling and bundling could become part of WebRTC 2.0"

That's tantamount to saying Plan A vs. Plan B vs. NoPlan is part of WebRTC 2.0.  Is that what you're suggesting?

[BA] If the "Plan A" vs. "Plan B" issue is not resolved, then WebRTC v1.0 would really only cover audio scenarios adequately.   That might make sense if we believed that WebRTC API 2.0 would go in a different direction and be concluded quickly. However, I'd observe that just because something isn't specified in a standard doesn't mean it won't be widely implemented.   And once you have functionality widely implemented, you typically have to deal with backward compatibility - and when the thing to be backward compatible with isn't specified, then it's a bit of a headache.

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 20 Jun 2013 10:18:13 -0700

I think Plan A vs Plan B is very different than No Plan vs.  CU.  The first
is "we both agree on a text blob;  what goes in the text blob?".  The
second is "let's add a few methods" vs.  "let's through out everything and
start over".

If the WG decided "Let's throw out everything and start over with WebRTC
2.0", I'd be happy to help work on a "CU NoPlan" in that context.  On the
other hand, if the WG said "Let's try adding methods in an incremental way
that allow JS to avoid SDP in WebRTC 2.0", I'd be happy to work on that as
well.  But I don't think CU-RTC is going to work well in the latter, since
the authors categorically reject incremental improvement.

On Wed, Jun 19, 2013 at 9:55 PM, Christer Holmberg <
[email-masked]> wrote:

> serialize control via a format, if the JS chooses to
> >>> do so (SDP is still there if JS wants).  It only does so for media
> streams, not for transports, but it allows incremental improvement to the
> API.
> At the virtual interim, the Plan A and Plan B folks were asked to sit down
> and try to come up with a compromise "Plan AB" solution.
>
> I guess it would be good if people that don't want SDP could try to come
> up with a compromise "CU No Plan" solution :)
>
> Regards,
>
> Christer
>
>

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 20 Jun 2013 10:20:42 -0700

On 6/20/2013 10:18 AM, Peter Thatcher wrote:
>  But I don't think CU-RTC is going to work well in the latter, since 

As long as the incremental improvement removes the offer/answer state 
machine, then that statement is false.

Matthew Kaufman

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 20 Jun 2013 10:25:08 -0700

Roman said: 

"My question is, would this WebRTC 1.0 API ever become a standard without SDP portion of it being well defined? Right not this is an opaque blob with little or no definition attached to it. It can be modified and extended in non-compatible way by an implementer with no changes to the actual external API surface."
[BA] I would note that the lack of definition in the SDP blob is not only an issue for the WebRTC 1.0 API, but it will also be an issue for a lower-level API if there is a requirement to demonstrate the ability to develop a shim on top to implement the WebRTC 1.0 API.   If WebRTC 1.0 is underspecified, and in particular if implementations either differ significantly from each other significantly or extend the functionality in undocumented ways, then a backward compatibility requirement on a lower-level API becomes very, very difficult to satisfy.   The practical reality is that a backward compatibility requirement needs to not only demonstrate compatibility with the "WebRTC 1.0 API" specification, but also with deployed implementations. 
Therefore my take is that an underspecified WebRTC 1.0 API effectively poisons the well.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 20 Jun 2013 13:28:06 -0400

Perhaps you could specify which references are missing?

On Thu, Jun 20, 2013 at 11:57 AM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

>  It must be possible for a third party to implement a compatible browser
> without referring to anything but the chain of normative references. At the
> present time, this is not the case, and would be grounds for not ratifying
> the specification within W3C.
>
>  Matthew Kaufman
>
>  ------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> Roman Shpount [[email-masked]]
> *Sent:* Thursday, June 20, 2013 8:47 AM
> *To:* Hutton, Andrew
> *Cc:* [email-masked]
> *Subject:* Re: [rtcweb] Priorities - Was: Requesting "SDP or not SDP"
> debate to be re-opened .
>
> SDP portion of it being well defined?
>

---

From: Robin Raymond <[email-masked]>
Date: Thu, 20 Jun 2013 13:28:46 -0400

Things to consider:
1) Many people who agreed with SDP have since changed their mind
2) If we opt to go with SDP in version #1 knowing that edge cases are 
causing major pains, those not doing SIP are having great pains, whose 
to say we will be able to fix it in version 2? At that point deployed 
systems will actually rely upon it and it will be even harder to affect 
change and then people will have two methods to do the same thing and 
have to support both because some browsers will be stuck on version 1 
for a long time to come.
3) SDP has become a serialized surface API for object control/properties 
and the only way to extend this in the future is via SDP extensions; 
that's a huge part of the issue and objection. That's also probably why 
so many are focused on extending SDP because they know it doesn't do 
anything beyond a simple demo at this point and is not ready for prime 
time deployments and many real-world use cases.
4) There is very few people saying SDP is "good" or "right". The 
arguments seem to fall into "we've made that choice", "it's too late", 
"we'll fix it later", "we must get something out now"
5) The cost of fixing it now could be much less than everyone working 
around this later

That's why I'd like to head up with a proposal with a JS shim for 
supporting SDP. We can get both worlds and put this debate truly to rest 
and (hopefully) even bring Microsoft onboard. I've written a media 
engine/RTC so I've got a good handle on what's involved and I've seen 
the webrtc C++ engine too. So I've got an idea as to what's going on 
under the hood and I have real world experience having written a SIP 
softphone client from scratch. Presently I'm trying to mangle Open Peer 
to utilize this SDP thing. Keep in mind, even I was okay at first with 
using SDP thinking I'd just parse/generate it until I thought about all 
its long term consequences as a surface API and then becomes strongly 
opposed to using it.

Making a simple surface API that isn't reliant on SDP and creating a JS 
SDP shim is entirely possible/feasible and will allow for a flexible 
future where we don't have tons of competing extensions to SDP with no 
idea what each browser actually/officially supports.

-Robin

> Hutton, Andrew <mailto:[email-masked]>
> 20 June, 2013 1:00 PM
>
> No it is not the only argument it is just stating the fact that we had 
> the debate previously in which the arguments were made and the balance 
> was in favor of SDP. As I said I don't really want to reopen all the 
> old arguments.
>
> I am saying that people are getting frustrated and considering a 
> change because we are concentrating on extending SDP rather than 
> keeping things simple and focusing on the current deliverables as 
> specified in the charter. If we had not gone this route then I think 
> we would have more success and people would not have become so frustrated.
>
> Changing fundamental decisions at a late stage is not a major deal and 
> comes with great costs so needs even more justification than the 
> original decision did.
>
> Andy.
> 20 June, 2013 12:41 PM

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 20 Jun 2013 10:31:36 -0700

Would you support incremental improvements that remove the offer/answer
state machine?  If so, I suggest you draft and propose such incremental
improvements.  I would love to see them.

On Thu, Jun 20, 2013 at 10:20 AM, Matthew Kaufman <[email-masked]>wrote:

>>  But I don't think CU-RTC is going to work well in the latter, since the
>> authors categorically reject incremental improvement.
>>
>>
>>

---

From: Matthew Kaufman <[email-masked]>
Date: Thu, 20 Jun 2013 10:37:35 -0700

On 6/20/2013 10:31 AM, Peter Thatcher wrote:
> Would you support incremental improvements that remove the 
> offer/answer state machine?  If so, I suggest you draft and propose 
> such incremental improvements.  I would love to see them.
>

When we broke our proposal down into a bunch of different deltas, we got 
strong feedback at the W3C meeting in Lyon that nobody wanted to touch 
SDP as the API or Offer/Answer as something that is baked in to the browser.

We've done a whole lot of work on our proposal *and* have running code 
that demonstrates it. We're not going to waste any more time writing 
additional proposals that will also be rejected by the folks who really 
love SDP + O/A.

If someone else wants to take our work as a reference or starting point, 
great. If everyone wants to wait until the current API gets to W3C to 
see what formal objections we file, that's fine too.

Matthew Kaufman

---

From: Peter Thatcher <[email-masked]>
Date: Thu, 20 Jun 2013 10:41:59 -0700

OK,  in that case, let me rewrite what I wrote earlier:

If the WG decided "Let's throw out SDP and O/A in WebRTC 2.0", I'd be happy
to help work on a "CU NoPlan" in that context.  On the other hand, if the
WG said "Let's leave SDP and O/A, but allow JS to bypass it", I'd be happy
to work on that as well.  But I don't think CU-RTC is going to work well in
the latter, since the authors categorically reject any API that contains
O/A.

Does that accurately reflect the position of the authors of CU-RTCWeb?

On Thu, Jun 20, 2013 at 10:37 AM, Matthew Kaufman <[email-masked]>wrote:

> strong feedback at the W3C meeting in Lyon that nobody wanted to touch SDP
> as the API or Offer/Answer as something that is baked in to the browser.
>
> great. If everyone wants to wait until the current API gets to W3C to see
> what formal objections we file, that's fine too.
>
> Matthew Kaufman
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Jun 2013 17:43:19 +0000

I obviously meant to say "is a major deal".

---

From: "Parthasarathi R" <[email-masked]>
Date: Thu, 20 Jun 2013 23:35:08 +0530

Hi Andy,

Your proposed approach looks reasonable way to move forward.

In case SDP improvements like multiplexing, bundling is taken the priority for WebRTC 1.0 which results in discussing whether offer/answer is required or not for those enhancements, then it will lead to discuss whether SDP is required or not as well. 

Thanks
Partha

> Behalf Of Hutton, Andrew
> Sent: Thursday, June 20, 2013 8:56 PM
> To: [email-masked]
> Subject: [rtcweb] Priorities - Was: Requesting "SDP or not SDP" debate
> to be re-opened .
> 
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 20 Jun 2013 19:38:43 +0000

What I am saying is that if we need a plan then no plan looks like the best option for WebRTC 1.0 and that we need to stop trying to boil the ocean and concentrate on what is needed to achieve the goals set out in the charter. It seems to me that we have got diverted from the original goals.

I don't believe this means that video is not adequately covered although it might mean a bit more implementation effort for those that want to get ahead of the game and build more complex applications but that is fair.

What is not fair is to reverse previous decisions because we are struggling to achieve things which are not even covered by the charter.

Regards
Andy

> From: Bernard Aboba [mailto:[email-masked]]
> Sent: 20 June 2013 18:17
> To: Peter Thatcher; Hutton, Andrew
> Cc: [email-masked]
> Subject: RE: [rtcweb] Priorities - Was: Requesting "SDP or not SDP"
> debate to be re-opened .
> 
> Peter Thatcher said:
> 
> That's tantamount to saying Plan A vs. Plan B vs. NoPlan is part of
> WebRTC 2.0.  Is that what you're suggesting?
> 
> [BA] If the "Plan A" vs. "Plan B" issue is not resolved, then WebRTC
> v1.0 would really only cover audio scenarios adequately.   That might
> make sense if we believed that WebRTC API 2.0 would go in a different
> direction and be concluded quickly. However, I'd observe that just
> because something isn't specified in a standard doesn't mean it won't
> be widely implemented.   And once you have functionality widely
> implemented, you typically have to deal with backward compatibility -
> and when the thing to be backward compatible with isn't specified, then
> it's a bit of a headache.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Jun 2013 23:49:27 +0200

> Create one. Or try, and share with us why it did not work.

It will not work (with the current SDP-based model) because it will
require that my JS code parses the SDP blob retrieved from the
browser, extracts all the fields/attributes and "exports" them into
some XML bodies.

What is the problem here? SDP itself because there are tons of
possible valid representations for the *same* session description
information into SDP blobs that look different (but mean the same).
And the problem is that we don't know how the SDP blob retrieved from
current browser model and version will look. My JS code could properly
parse a SDP blob generated by Chrome 35 but may fail in Chrome 36 or
Firefox 29 due to "cosmethic" changes in the SDP.

If this statement is not true (I hope I don't need to code a
XMPP/Jingle endpoint to prove it...), why are there so many SDP
compatibility issues in widely deployed SDP-based protocolos (i.e.
SIP)? Why do SBCs exist? (I know "fixing-SDP-compatibility-issues" is
not their only feature, but it is one of them).

> Can they tell us what happened when they tried?

Which kind of interoperability? Let me guess it:

- Initial INVITE with SDP.
- 200 OK response with SDP.
- Lot of applause when the browser produces audio.
- BYE.

In JsSIP we are getting frustrated trying to implement the "hold" /
"unhold" feature because it requires SDP parsing and mangling. Sending
a re-INVITE with a modified SDP (now with a video track enabled) seems
to work (after lot of pain) but we still miss a reliable API to know
what the new SDP means. Instead we need to parse the SDP to detect
global (or per m=) line attributes like "a=inactive" or "a=sendonly"
etc etc. It's really painful.

BTW I don't know wheter you support PlanA, PlanB or NoPlan, but I did
a question (in this case about NoPlan) for which I got no response,
and honestly I would like to see it replied regardless the solution
uses PlanA, PlanB or NoPlan model:

I would *really* appreciate a response to that mail (with any Plan as
solution), really.

Best regards.

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

---

From: Emil Ivov <[email-masked]>
Date: Fri, 21 Jun 2013 00:33:58 +0200

Hey Iñaki,

> etc etc. It's really painful.

I am having a problem following what you are trying to achieve here. In 
JsSIP you seem to be going for a full SIP implementation in the browser. 
If this is true and if this WG decides to remove SDP from the API 
surface, then you would need to completely parse SDP in the JS and then 
convert it into API calls. Similarly, when creating offers and answers 
you would need to construct SDP all by yourself.

So I am not sure why the SDP parsing in the current situation is so much 
of a blocker for your use case.

> I would *really* appreciate a response to that mail (with any Plan as

Yup, sorry for being silent on that one. Busy days.

My personal take on No Plan SIP interop is that the JS app would take 
the initial SDP out of the browser, send it to a signalling gateway and 
leave that gateway do whatever it wants with it.

Some gateways will resend it with no changes (it is likely that an 
increasing number of endpoints will come to support the kind of SDP that 
comes from browsers). Most GWs will probably handle it as any B2BUA 
handles a call leg. They'd keep a state and possibly convert some of the 
SDP to match what various endpoints expect.

The other option would be indeed to do the same thing in JS. I believe 
this is JsSIP's use case. In that case however, regardless of whether 
you choose Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be 
exposed to a fair amount of complexity, parsing and JS magic.

You are, after all, building a SIP stack.

In the above mail you also say:

> Another example:
>
> * I am a powerful SIP conference server which properly implements
> WebRTC. I initiate a call to 5 users (running JS SIP app in their
> browsers). The initial INVITE has SSRC/MSID fields in the SDP
> identifying all the participants, am I right?

No, with No Plan there are no SSRCs and MSIDs in the SDP that comes from 
the browser.

> * Later, during the conference, I call to another 6th participant and
> enter him into the conference, so I need to send a re-INVITE to every
> participant with a modified version of the SDP (note that this is SIP
> protocol, so I need to use SIP messages to carry the new info about
> SSRC/MSID and so on).

That's the thing. You don't need that. In Jitsi we do exactly this 
operation with no Offer/Answer signalling. RTP carries enough 
information to process streams and we use upper layer signalling (4575) 
for things such as mapping SSRCs to users and announcing current 
participant list.

Cheers,

Emil

-- 
https://jitsi.org

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Jun 2013 01:24:09 +0200

2013/6/21 Emil Ivov <[email-masked]>:
> JsSIP you seem to be going for a full SIP implementation in the browser. If
> this is true and if this WG decides to remove SDP from the API surface, then
> you would need to completely parse SDP in the JS and then convert it into
> API calls. Similarly, when creating offers and answers you would need to
> construct SDP all by yourself.

And we will do it very happily because then we will know what
*exactly* we are sending on-the-wire.

> So I am not sure why the SDP parsing in the current situation is so much of
> a blocker for your use case.

Because regardless I am a SIP-guy, I understand that the main mission
of WebRTC is to provide realtime communications *for* the WWW, and not
to enable a new interface for like-telephony-bussines.

Today I'm doing SIP. Tomorrow I may be doing
[[put_here_a_future_RTC_protocol_not_based_on_SDP]] and then I don't
want to be constrained by decisions made today that force any future
RTC protocol to deal with SDP O/A model.

:)

> The other option would be indeed to do the same thing in JS. I believe this
> is JsSIP's use case. In that case however, regardless of whether you choose
> Plan A, Plan B, No Plan or CU-RTC-Web, you will inevitably be exposed to a
> fair amount of complexity, parsing and JS magic.
>

Yes, but JsSIP creates its own SIP messages to be sent in the wire, so
we have full control over *what* we create and send. Those SIP
messages are not provided by the WebRTC API. But for the SDP
component, JsSIP retreives a SDP blob string from the PC.

> No, with No Plan there are no SSRCs and MSIDs in the SDP that comes from the
> browser.

OK

> That's the thing. You don't need that. In Jitsi we do exactly this operation
> with no Offer/Answer signalling. RTP carries enough information to process
> streams and we use upper layer signalling (4575) for things such as mapping
> SSRCs to users and announcing current participant list.

That is much better than Plan A and Plan B.

BTW: What would happen in NoPlan if the remote (i.e. a SIP
gateway/endpoing) sends you a re-INVITE for "hold" purposes and you
pass the SDP to your PC? or you should not pass the SDP to your PC?
and if so, what about if the SDP contains updated ICE candidates due
to remote peer network mobility?

Thanks a lot for your response.

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

---

From: Bossiel thioriguel <[email-masked]>
Date: Fri, 21 Jun 2013 10:40:00 +0100 (BST)

Hello,

I'm registered on this group since the beginning but this is my first post on this thread. So, I presente myself: Mamadou DIOP and I'm working for Doubango Telecom where we're building SIP endpoints, gateways, TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and open source.

What I'm talking about is not just feeling but something I've experienced.

Using the current WebRTC we have managed to *easily* build almost all kind of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, Telemedicine systems...and haven't seen any major issue. It's true that it's not natural to "hack" a blob SDP to implement features like hold/resume, media update, early media ... but it works and there are demo applications showing it. If there is something more beautiful we just want to see it in action and test it.

Many participants here have said that what they want is something close to CU-RTC-WEB. Don't really know if they tried to build applications using it or not but in my case I have.
My reference: http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info
First on Windows 8 but haven't gone far as there is no documentation to get started. Then, OSX and luckily there was a readme with two links for testing (only one work). You need to open 3 pages (1 master, 2 slaves) and check "send audio" on both slaves to header sound. Many javascript files and no documentation. It's said on these blogs that interop with SIP networks is easy but it's not my feeling ...I just want to see one :)

I don't really understand the issue with the O/A model. SDP or not SDP you'll always offer something and answer something. I'm I missing?

For the current WebRTC, Google open sourced their engine, produced drafts, a working implementation in chrome, a mailing-list to help developers, demo applications, documentation... we just want to see the same from any company asking to rewrite everything.

I'm not saying the current WebRTC implementation is perfect but I have seen my 14 year old nephew developing an audio/video chat for his homework :)

Regards

________________________________
 De : Iñaki Baz Castillo <[email-masked]>
À : Emil Ivov <[email-masked]> 
Cc : "[email-masked]" <[email-masked]> 
Envoyé le : Vendredi 21 juin 2013 1h24
Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

:)

OK

---

From: Bossiel thioriguel <[email-masked]>
Date: Fri, 21 Jun 2013 10:56:11 +0100 (BST)

Forgot to add:
We're willing to provide an open source gateway to SIP/IMS world and feedbacks for any new implementation to show "how good" or "how bad" it is :)

________________________________
 De : Bossiel thioriguel <[email-masked]>
À : "[email-masked]" <[email-masked]> 
Cc : "[email-masked]" <[email-masked]> 
Envoyé le : Vendredi 21 juin 2013 11h40
Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Hello,

Regards

:)

>> WebRTC. I initiate
 a call to 5 users (running JS SIP app in their

OK

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Jun 2013 12:19:05 +0200

2013/6/21 Bossiel thioriguel <[email-masked]>:
> Using the current WebRTC we have managed to *easily* build almost all kind
> of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs,
> Telemedicine systems...and haven't seen any major issue. It's true that it's
> not natural to "hack" a blob SDP to implement features like hold/resume,
> media update, early media ... but it works and there are demo applications
> showing it.

Hi Bossiel,

Current WebRTC is based on SDP mainly for "SIP interoperability", so
obviously it is "easy" to build like-SIP-based applications. Anyhow in
most of the apps you mean I'm pretty sure that there are just a few
SDP exchanges, probably just the initial SDP offer/answer and some
other for "hold" / "unhold" purposes (which requires SDP mangling).

Now let's assume that WebRTC is much more than
SIP-business-into-the-web, let's assume that WebRTC is RTC for the Web
rather than Web for RTC.

> For the current WebRTC, Google open sourced their engine, produced drafts, a working implementation in chrome, a mailing-list to help developers, demo applications, documentation... we just want to…

A company? AFAIK this is a IETF WG, not a company. I am not speaking
on behalf of any company or business.

Is there anyone not involved in SIP/PSTN business which feels
comfortable with the SDP-based specs of WebRTC?

Best regards.

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

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 21 Jun 2013 10:32:31 +0000

> comfortable with the SDP-based specs of WebRTC?
It seems that Bossiel's 14 year old nephew is quite comfortable with it.

Which means we have not been as unsuccessful as people seem to think.

Andy

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 21 Jun 2013 10:55:12 +0000

Thanks for this message I especially like the part about your 14 year old nephew writing WebRTC applications and I think we should take this as a sign of at least some success.

I have seen over the last year many demo's of WebRTC based applications developed both by major companies and by individuals some of which I assume know either nothing or very little about SDP.

The problems we are having in the IETF seem to be that we have lost sight of the original goals and got bogged down with the very complex requirements of some IETF participants.  I think it very likely that Bossiel's nephew is not very concerned about SSRC signaling and bundling and actually none of the very innovative WebRTC applications I have seen over the last year have needed these. However he probably will be concerned when his application does not work from his hotel or his office when he starts work. 

It just goes to show we have been diverted from what is really needed to complete WebRTC 1.0.

Let's concentrate on making sure all those innovative apps already written deployable before we start trying to satisfy the requirements of the mega application developers.

Andy

> Behalf Of Bossiel thioriguel
> Sent: 21 June 2013 10:40
> To: [email-masked]
> Cc: [email-masked]
> I'm registered on this group since the beginning but this is my first
> post on this thread. So, I presente myself: Mamadou DIOP and I'm
> working for Doubango Telecom where we're building SIP endpoints,
> gateways, TelePresence/Telemedicine systems... all focused on
> SIP/IMS/LTE/RCS-e and open source.
> 
> Using the current WebRTC we have managed to *easily* build almost all
> kind of applications: click-to-call, SIP/IMS clients, gateways to PSTN,
> MCUs, Telemedicine systems...and haven't seen any major issue. It's
> true that it's not natural to "hack" a blob SDP to implement features
> like hold/resume, media update, early media ... but it works and there
> are demo applications showing it. If there is something more beautiful
> we just want to see it in action and test it.
> 
> Many participants here have said that what they want is something close
> to CU-RTC-WEB. Don't really know if they tried to build applications
> using it or not but in my case I have.
> My
> reference: http://html5labs.interoperabilitybridges.com/prototypes/cu-
> rtc-web-roaming/cu-rtc-web-roaming/info
> First on Windows 8 but haven't gone far as there is no documentation to
> get started. Then, OSX and luckily there was a readme with two links
> for testing (only one work). You need to open 3 pages (1 master, 2
> slaves) and check "send audio" on both slaves to header sound. Many
> javascript files and no documentation. It's said on these blogs that
> interop with SIP networks is easy but it's not my feeling ...I just
> want to see one :)
> 
> I don't really understand the issue with the O/A model. SDP or not SDP
> you'll always offer something and answer something. I'm I missing?
> 
> For the current WebRTC, Google open sourced their engine, produced
> drafts, a working implementation in chrome, a mailing-list to help
> developers, demo applications, documentation... we just want to see the
> same from any company asking to rewrite everything.
> 
> I'm not saying the current WebRTC implementation is perfect but I have
> seen my 14 year old nephew developing an audio/video chat for his
> homework :)
> 
> Regards
> 
> ________________________________________
> operation

---

From: Robin Raymond <[email-masked]>
Date: Fri, 21 Jun 2013 08:18:03 -0400

Your point about it being easy to get a demo running I agree, or even 
interfacing with a SIP network.

I can't comment on the difficulty or not of CU-RTCWeb's implementation. 
It does look like CU-RTCWeb has a lot of features/complexity out of the 
gate which is necessary to do a lot of alternative scenarios but might 
cause someone to through up their hands in frustration trying to figure 
out how it all works, especially if you are an integrator of SIP and not 
an implementer.

I conquer whatever solution adopted must be equally as easy for SIP 
developers (even though that is not part of the mandate as I understand 
it). That's why I proposed that I would take it upon myself to lead an 
API proposal that could work for both. The simple "SIP/SDP" case being 
provided as a shim that you could write against if you are a SIP 
integrator (close to the current webrtc as reasonable) but something 
that doesn't break other non-SIP models.

Let me explain why offer/answer breaks other models. Offer/answer 
negotiates akin to "I send out an offer, but whatever you agree on from 
my offer we will use together". Further "if you disagree with my offer, 
we'll roll back to the existing offer". Finally "if we both make an 
offer at the same time, we'll conflict and we'll have to use conflict 
resolution to change our offers". That was true of when I last authored 
X-Lite/X-PRO SIP softphone client so perhaps something has changed since 
then to which I'm not aware, but that's my gross simplification of 
offer/answer.

However, that is absolutely _not_ the only way to negotiate. For 
example, Open Peer for example uses constraints based negotiation. This 
is akin to "if you send me anything, please send me this". The 
difference is that each side is allowed to change what it expects to 
receive without a round trip to the remote party agreeing and without 
risk of rollback. That makes it really easy to update and change what 
you expect without needing the complexities of an offer/answer state 
machine. If one is forced upon us, we'll have to find away around this 
offer/answer mechanism because negotiating is not an option for us - we 
simply don't do it at all. Whatever we do to hack around it will likely 
violate the offer/answer rules.

Offer/answer is wholly not necessary to be mandated as part of WebRTC to 
fulfill the charter but it currently is mandated. I don't want something 
just for "me", but we are forcing an unneeded model of negotiation upon 
JavaScript developers that may not want to adhere to that model either 
(and likely will violate it too, albeit unintentionally). Skype has 
similar objections to offer/answer but I can't speak to their 
negotiation strategy or presume to speak on their behalf. If 
offer/answer were removed as a mandate, you can do so yourself in your 
JavaScript without browser enforcement.

My other issue is that SDP has become an API surface for control, 
properties and extensions. We must remember that the consumer of what we 
produce must be acceptable to the W3C and their members (browser and 
JavaScript implementers) and not SIP integrators. If we are asking 
JavaScript developers to hack/mangle the SDP to do anything beyond 
"place/answer" a call, we are forcing them to learn an entirely new 
ill-defined language called SDP rather than just using a JavaScript API 
which is native to their language constructs.

If we are saying "people shouldn't touch the SDP nor need to" then why 
not have a binary format for the blob exchange that is untouchable? The 
reason we don't encode to binary is because we _expect_ people to have 
to mangle the SDP. That's simply not acceptable in my mind to require 
JavaScript developers to learn SDP. Perhaps this is outside the charter, 
but I don't think it's inside the charter either to mandate learning SDP 
to perform common edge case actions either (e.g. putting media on hold). 
There's a huge gray area here and effectively we are coming up with 
their API for the W3C called "SDP". Should we fail to provide a 
respectable API, they will reject what we have anyway and likely they 
will not come up with SDP as their solution (plus WebRTC will take 
another delay and blow).

The next issue is that SDP is not a well defined format. There is no 
100% sure way to write SDP to be compatible. This means that if we do 
have to mangle SDP, we'll have to do browser, version and platform 
detection to pre-determine what exact formats the SDP will 
generate/parses and have compatibilities for each. We must or we will 
break. This goes against browser philosophy entirely. The IETF might not 
care about that but the W3C will care. But we should care too because we 
cannot be sure that the next browser version update on some random 
platform won't just suddenly break any implementation. What we write 
will expect a certain syntax, and will break and there's no mandate that 
browser vendors come back to us for approval of their extensions they 
want/need. This will make implementations brittle.

The final thing that scares me is all the extensions being proposed to 
make this SDP, for example, BUNDLE. Nothing wrong with the concepts at 
all! But should some vendors start adopting some of these extensions (or 
fork the browser code base to support these extensions), we'll see 
environments where the SDP produced is massively complex, unknown and 
"special". This will be entirely legal since anything goes with SDP but 
will wholly break likely everything that doesn't know about those 
extensions, except those involved in producing those extensions. No 
longer will this be the open web, but a closed web tied to certain 
vendors via extensions. This isn't just some theoretical issue. This is 
already underway with an avalanche with many requests / demands being 
put upon the various browser vendors all with their own competing 
interests / alliances.

With an API model, extensions can be added as additional API, without 
breaking anyone. If you use the "basic" API, you get the same behaviours 
you expect as always even if new features are added later. If you use 
additional APIs, only then do you get the advanced features for the API 
you know about. With SDP, you don't know because their's nothing 
restricting exactly what the SDP expresses locally in advance nor what 
you will receive from a remote party.

Finally, by baking the SDP into the browser, you make it unchangeable. 
If there was issues with the SDP generated/parsing, you'll have to 
mangle the SDP from JavaScript (or from an SBC) to make it work (and you 
will need browser version detection to do that which is something the 
browser vendors are fighting hard to prevent). Were it instead written 
as a JavaScript shim, you could tweak the shim code yourself for 
whatever compatibility you need without waiting for the next browser 
update to fix the issue. Baked in the browser, you are out of luck.

This is why I'm proposing we have a reasonable API for JavaScript using 
their language constructs they already know and are familiar that is 
extensible for the future without more SDP mangling/extensions. Those 
who want to do SDP extensions can do it inside an updatable shim, which 
can be tailored to your specific SIP environment to be 100% compatible 
with little to no risk the browser vendors will break you.

I fully appreciate the need that whatever API is produced is not 
needlessly complex and to ensure the absolutely dead-easy implementation 
exist. I plan to satisfy the dead-easy situation by providing a shim 
written entirely in JavaScript that provides that "80%" of what people 
want, i.e. the current WebRTC API which is easy starting point for many 
SIP integrators. Those of us who in the 20% who don't use SIP can bypass 
(or modify) the shim to do what they want/need.

So I ask you, if I were to propose such a solution (and provide 
examples), would you be open minded to using a shim that provides your 
easy use case rather than forcing SDP inside of SDP being baked into 
browser binary? Do you also understand my objections to using SDP with 
offer/answer?

-Robin

> Bossiel thioriguel <mailto:[email-masked]>
> 21 June, 2013 5:40 AM
> Hello,
>
> kind of applications: click-to-call, SIP/IMS clients, gateways to 
> PSTN, MCUs, Telemedicine systems...and haven't seen any major issue. 
> It's true that it's not natural to "hack" a blob SDP to implement 
> features like hold/resume, media update, early media ... but it works 
> and there are demo applications showing it. If there is something more 
> beautiful we just want to see it in action and test it.
>
> Many participants here have said that what they want is something 
> close to CU-RTC-WEB. Don't really know if they tried to build 
> applications using it or not but in my case I have.
> My 
> reference: http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info
> First on Windows 8 but haven't gone far as there is no documentation 
> to get started. Then, OSX and luckily there was a readme with two 
> links for testing (only one work). You need to open 3 pages (1 master, 
> 2 slaves) and check "send audio" on both slaves to header sound. Many 
> developers, demo applications, documentation... we just want to see 
> the same from any company asking to rewrite everything.
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Jun 2013 15:08:55 +0200

> Let's concentrate on making sure all those innovative apps already written deployable before we start trying to satisfy the requirements of the mega application developers.

As said before, if WebRTC 1.0 borns with SDP O/A inside, WebRTC 2.0
will also (given the "backward compatibility" and given that WebRTC
1.0 will be a real standard, rather than the tons of draft we have
today).

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

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 21 Jun 2013 07:42:35 -0700

Do you work with video or just audio?

Do you work with multiple streams/tracks, both send and receive?

Do you use features such as rtx, fec, and simulcast?

Simple, single-track, audio-only clients that use SDP for signalling over
the wire are fairly well served by the current API, as are clients only
using the data channel.  But doing more advanced things, such as those I
mention, require significant SDP munging which can be a very slow and
error-prone experience.

Your experience may differ from others because they are trying to do things
that require a lot more SDP munging, which can be quite painful.
On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" <[email-masked]> wrote:

> Hello,
>
> I'm registered on this group since the beginning but this is my first post
> on this thread. So, I presente myself: Mamadou DIOP and I'm working for
> Doubango Telecom where we're building SIP endpoints, gateways,
> TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e and
> open source.
>
> Telemedicine systems...and haven't seen any major issue. It's true that
> it's not natural to "hack" a blob SDP to implement features like
> hold/resume, media update, early media ... but it works and there are demo
> applications showing it. If there is something more beautiful we just want
> to see it in action and test it.
>
> Many participants here have said that what they want is something close to
> CU-RTC-WEB. Don't really know if they tried to build applications using it
> or not but in my case I have.
> My reference:
> http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info
> get started. Then, OSX and luckily there was a readme with two links for
> testing (only one work). You need to open 3 pages (1 master, 2 slaves) and
> check "send audio" on both slaves to header sound. Many javascript files
> and no documentation. It's said on these blogs that interop with SIP
> networks is easy but it's not my feeling ...I just want to see one :)
>
> For the current WebRTC, Google open sourced their engine, produced drafts,
> a working implementation in chrome, a mailing-list to help developers, demo
> applications, documentation... we just want to see the same from any
> company asking to rewrite everything.
>
> seen my 14 year old nephew developing an audio/video chat for his homework
> :)
>
> Regards
>
>  *De :* Iñaki Baz Castillo <[email-masked]>
> *À :* Emil Ivov <[email-masked]>
> *Cc :* "[email-masked]" <[email-masked]>
> *Envoyé le :* Vendredi 21 juin 2013 1h24
> *Objet :* Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
>
> If
> this
> the

---

From: Bossiel thioriguel <[email-masked]>
Date: Fri, 21 Jun 2013 15:49:59 +0100 (BST)

@Peter
Both audio and video.
Yes we're doing all you're listing here and even more.

________________________________
 De : Peter Thatcher <[email-masked]>
À : Bossiel thioriguel <[email-masked]> 
Cc : [email-masked]; [email-masked] 
Envoyé le : Vendredi 21 juin 2013 16h42
Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Simple, single-track, audio-only clients that use SDP for signalling over the wire are fairly well served by the current API, as are clients only using the data channel.  But doing more advanced things, such as those I mention, require significant SDP munging which can be a very slow and error-prone experience.  
Your experience may differ from others because they are trying to do things that require a lot more SDP munging, which can be quite painful.
On Jun 21, 2013 2:40 AM, "Bossiel thioriguel" <[email-masked]> wrote:

Hello,

---

From: Bossiel thioriguel <[email-masked]>
Date: Fri, 21 Jun 2013 15:58:48 +0100 (BST)

@Robin
Yes we'll use such API (already said it on another thread). What I'm not supporting is "remove SDP and start from zero".
What you're proposing here represent huge amount of work. I guess you already know it :)

________________________________
 De : Robin Raymond <[email-masked]>
À : Bossiel thioriguel <[email-masked]> 
Cc : "[email-masked]" <[email-masked]>; "[email-masked]" <[email-masked]> 
Envoyé le : Vendredi 21 juin 2013 14h18
Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Offer/answer is wholly not necessary to be mandated as part of WebRTC to
 fulfill the charter but it currently is mandated. I don't want 
something just for "me", but we are forcing an unneeded model of 
negotiation upon JavaScript developers that may not want to adhere to 
that model either (and likely will violate it too, albeit 
unintentionally). Skype has similar objections to offer/answer but I 
can't speak to their negotiation strategy or presume to speak on their 
behalf. If offer/answer were removed as a mandate, you can do so 
yourself in your JavaScript without browser enforcement.

If we are saying "people shouldn't touch the SDP nor need to" then why 
not have a binary format for the blob exchange that is untouchable? The 
reason we don't encode to binary is because we _expect_ people to have 
to mangle the SDP. That's simply not acceptable in my mind to require 
JavaScript developers to learn SDP. Perhaps this is outside the charter,
 but I don't think it's inside the charter either to mandate learning 
SDP to perform common edge case actions either (e.g. putting media on 
hold). There's a huge gray area here and effectively we are coming up 
with their API for the W3C called "SDP". Should we fail to provide a 
respectable API, they will reject what we have anyway and likely they 
will not come up with SDP as their solution (plus WebRTC will take 
another delay and blow).

 care about that but the W3C will care. But we should care too because 
we cannot be sure that the next browser version update on some random 

-Robin

Bossiel thioriguel
>21 June, 2013 
5:40 AM
on this thread. So, I presente myself: Mamadou DIOP and I'm working for 
Doubango Telecom where we're building SIP endpoints, gateways, 
TelePresence/Telemedicine systems... all focused on SIP/IMS/LTE/RCS-e 
and open source.
>Using the current WebRTC we have managed to *easily* build almost all kind of applications: click-to-call, SIP/IMS clients, gateways to PSTN, MCUs, 
Telemedicine systems...and haven't seen any major issue. It's true that 
it's not natural to "hack" a blob SDP to implement features like hold/resume, media update, early 
media ... but it works and there are demo applications showing it. If 
there is something more beautiful we just want to see it in action and 
test it.
>
>
>Many participants here have said that what 
they want is something close to CU-RTC-WEB. Don't really know if they 
tried to build applications using it or not but in my case I have.
>First on Windows 8 but 
haven't gone far as there is no documentation to get started. Then, OSX 
and luckily there was a readme with two links for testing (only one 
work). You need to open 3 pages (1 master, 2 slaves) and check "send 
audio" on both slaves to header sound. Many javascript files and no 
documentation. It's said on these blogs that interop with SIP networks 
is easy but it's not my feeling ...I just want to see one :)
>
>
>I don't really understand the issue with the O/A model. 
SDP or not SDP you'll always offer something and answer something. I'm I missing?
>For the current WebRTC, 
Google open sourced their engine, produced drafts, a working 
implementation in chrome, a mailing-list to help developers, demo 
applications, documentation... we just want to see the same from any 
company asking to rewrite everything.
>I'm not 
saying the current WebRTC implementation is perfect but I have seen my 
14 year old nephew developing an audio/video chat for his homework :)

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 21 Jun 2013 17:01:10 +0200

> Yes we're doing all you're listing here and even more.

How much SDP parsing/mangling?

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Jun 2013 11:58:39 -0400

> comfortable with the SDP-based specs of WebRTC?

I am involved with SIP/PSTN and I am not comfortable with current WebRTC.

What is trivial to implement is a server based gateway that will terminate
and transcode media and signaling connection from WebRTC and connect WebRTC
to anything. For this you take the open source code which implements WebRTC
in Chrome, put it in your server and put a real SIP stack/media engine on
the other side. This way all the SDP negotiation and media decoding is done
using the same code as in the browser, and SIP/SDP negotiation on the
SIP/PSTN side is done using normal SIP stack. By normal SIP stack I mean
something that has been used with PSTN for significant period of time and
has all the interop issues resolved, and all the necessary configuration
parameters needed to work with SIP network implemented. Issues like hold do
not matter, since they are handled on the SIP side and not passed to WebRTC
side at all. Codec support, DTLS, ICE do not matter since they are handled
by the WebRTC engine in the server. If this is what you want you have
achieved your goal, but this is not a standard. There is no guarantee that
this will work in 5 years or even in 6 month, since SDP produced by WebRTC
can change. There is no guarantee that this will work with all the WebRTC
implementations, since the standard is loose enough that significant things
can be different while still being standard compliant. Finally, and most
importantly, this will not work if you want to pass SDP and media produced
by WebRTC to the outside world without transcoding it.

P.S. Not to offend anybody, but if you create a system any idiot can use,
only idiots will.
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Jun 2013 12:01:39 -0400

> Which means we have not been as unsuccessful as people seem to think.

If building a demo or a high school home work is your goal, then yes. If
you want the commercial product then no. I am not sure if you are familiar
with 80/20 rule, but normally 20% of features require 80% of time to
implement. In case of WebRTC it is 20% of features require 99% to
implement. In other words, you get something working quick, but getting it
to complete product take an inordinate amount of work.
_____________
Roman Shpount

---

From: "Hutton, Andrew" <[email-masked]>
Date: Fri, 21 Jun 2013 16:52:00 +0000

Now this is getting ridiculous.

You do know that one of the goals is to build an API that web developers without knowledge of IETF protocols can use to build apps. I was only using this as an example where this has been achieved.

I also think you know that there are many apps out there already which are much more than high school projects.

I believe we are simply making life difficult by trying to do too much at once  and we need to rethink what is really needed and deliver on what we have said we we will deliver please read the charter.

Andy

On 21 Jun 2013, at 17:01, "Roman Shpount" <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jun 21, 2013 at 6:32 AM, Hutton, Andrew <[email-masked]<mailto:[email-masked]>> wrote:

If building a demo or a high school home work is your goal, then yes. If you want the commercial product then no. I am not sure if you are familiar with 80/20 rule, but normally 20% of features require 80% of time to implement. In case of WebRTC it is 20% of features require 99% to implement. In other words, you get something working quick, but getting it to complete product take an inordinate amount of work.
_____________
Roman Shpount

---

From: Robin Raymond <[email-masked]>
Date: Fri, 21 Jun 2013 13:37:14 -0400

To me the issue is not easy of use but compatibility, as what is 
produced should increase compatibility not decrease it. That's one of 
the major drawbacks of SDP with offer/answer as I've described numerous 
times -- it increases incompatibility rather than decreases it.

I too want to see an API where people don't need to understand a complex 
mechanism to be able to produce a suitable application. Unfortunately, 
the current SDP approach all too often requires learning SDP by 
JavaScript developers to perform normal edge case scenarios (e.g. 
putting media on/off hold). That's simply not acceptable in my mind.

That's why I will drafting up an alternative approach which can have a 
reasonable non-SDP based API without offer/answer but I will provide a 
JavaScript shim on top that will provide the current "simple" approach, 
including being able perform offer/answer using SDP (as some people 
prefer). This should more than adequately satisfy the charter's limited 
1.0 goals and responsibilities and give the non-SDP people a basis for 
moving forward where they can feel comfortable will satisfy their needs 
as well.

-Robin

> 21 June, 2013 12:52 PM
> You do know that one of the goals is to build an API that web 
> developers without knowledge of IETF protocols can use to build apps. 
> I was only using this as an example where this has been achieved.
>
> I believe we are simply making life difficult by trying to do too much 
> at once  and we need to rethink what is really needed and deliver on 
> what we have said we we will deliver please read the charter.
>
> Andy
>

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Fri, 21 Jun 2013 20:19:50 +0000

Bossiel thioriguel : "I don't really understand the issue with the O/A model. SDP or not SDP you'll always offer something and answer something. I'm I missing?"

What you are missing is that you *don't* "always offer something and answer something. There is a completely different programming model where the server or program executing on the client is entirely in control of what happens.

As an example, if I say "draw a box that is 10 pixels wide and 10 pixels high" that's me telling the browser what to do. With offer/answer, I would say "I would like a box, what size boxes can you draw?" and the browser would respond with a list, and I would pick one of those.

RTCWEB is the *only* case where someone is seriously proposing an API that doesn't allow the programmer to directly control the behavior of the browser.

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bossiel thioriguel
Sent: Friday, June 21, 2013 2:40 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

Hello,

Regards

________________________________
De : Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>>
À : Emil Ivov <[email-masked]<mailto:[email-masked]>>
Cc : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Envoyé le : Vendredi 21 juin 2013 1h24
Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

:)

OK

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sat, 22 Jun 2013 09:40:35 +1000

Did you develop a SDP manipulation library that you could share/point us to?
Silvia.
 On 22 Jun 2013 00:50, "Bossiel thioriguel" <[email-masked]> wrote:

>  *De :* Peter Thatcher <[email-masked]>
> *À :* Bossiel thioriguel <[email-masked]>
> *Cc :* [email-masked]; [email-masked]
> *Envoyé le :* Vendredi 21 juin 2013 16h42
> Your experience may differ from others because they are trying to do
> things that require a lot more SDP munging, which can be quite painful.

---

From: Bossiel thioriguel <[email-masked]>
Date: Sat, 22 Jun 2013 00:46:56 +0100 (BST)

Yes
https://code.google.com/p/sipml5/source/browse/#svn%2Ftrunk%2Fsrc%2FtinySDP%2Fsrc

________________________________
 De : Silvia Pfeiffer <[email-masked]>
À : Bossiel thioriguel <[email-masked]> 
Cc : [email-masked]; Peter Thatcher <[email-masked]>; "[email-masked]" <[email-masked]> 
Envoyé le : Samedi 22 juin 2013 1h40
Objet : Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened

@Peter

---

From: Silvia Pfeiffer <[email-masked]>
Date: Sat, 22 Jun 2013 09:54:28 +1000

Is it possible to continue using SDP but not do o/a ?

While I am all for having an easy API to manipulate SDP for the common use
cases (and this abstract away the mangling) I am not too fussed about the
use of SDP itself.

I wonder if the restricted negotiation that you propose will still need
something like SDP to communicate the parameters of the negotiation. So we
could leave the data structure intact, but have a different negotiation
algorithm between browsers. We could even offer in the SDP a choice of
which negotiation algo to use so as to make interfacing with the SIP works
easier.

I hope this makes sense.

Cheers,
Silvia.
 On 22 Jun 2013 03:37, "Robin Raymond" <[email-masked]> wrote:

>
> To me the issue is not easy of use but compatibility, as what is produced
> should increase compatibility not decrease it. That's one of the major
> drawbacks of SDP with offer/answer as I've described numerous times -- it
> increases incompatibility rather than decreases it.
>
> mechanism to be able to produce a suitable application. Unfortunately, the
> current SDP approach all too often requires learning SDP by JavaScript
> developers to perform normal edge case scenarios (e.g. putting media on/off
> hold). That's simply not acceptable in my mind.
>
> prefer). This should more than adequately satisfy the charter's limited 1.0
> goals and responsibilities and give the non-SDP people a basis for moving
> forward where they can feel comfortable will satisfy their needs as well.
>
> -Robin
>
>
>
>   Hutton, Andrew <[email-masked]>
>  21 June, 2013 12:52 PM
>  You do know that one of the goals is to build an API that web developers
> without knowledge of IETF protocols can use to build apps. I was only using
> this as an example where this has been achieved.
>
> at once  and we need to rethink what is really needed and deliver on what
> we have said we we will deliver please read the charter.
>
>  Andy
>
>

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Jun 2013 20:08:02 -0400

> Is it possible to continue using SDP but not do o/a ?

Neither SDP not O/A belongs in API.

The issue with SDP is that it creates an API surface which is using a
string blob. To make such API a standard you need to standardize the blob
format. Also, every time you add features you need to update the SDP format
and all the parsers that are dealing with it. Not sustainable long term.
Finally, SDP mixes multiple unrelated data items together, ie it specifies
transport parameters and media parameters at the same time. For a normal
API flow you need to control those separately.

O/A implies one model to negotiate media and transport parameters and
forces them to be negotiated at the same time. One other thing to keep in
mind that O/A compliant end points are not O/A internally. For instance you
can change the sending codec or sending codec parameters (like bitrate)
without going through offer/answer exchange. So, normally end points expose
offer/answer to the network, but use a different API internally to control
transport and media settings based on data received from O/A exchanges,
user input, and other factors (like detecting high packet loss and reducing
bandwidth or changing codec).
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Jun 2013 20:17:14 -0400

Just keep in mind that with this library, after you parse SDP, you will end
up with a bunch of connection line attributes and format parameters. You
will need to interpret those and figure out what they mean on your own.

SDP is well defined format in the sense that you can parse it. Figuring out
what this all means is a different story. For all you care, you can create
a birthday party invitation and stuff it in SDP. Will make no sense to your
WebRTC browser but will be well formed SDP none the less.
_____________
Roman Shpount

On Fri, Jun 21, 2013 at 7:46 PM, Bossiel thioriguel <[email-masked]>wrote:

>  *De :* Silvia Pfeiffer <[email-masked]>
> *Cc :* [email-masked]; Peter Thatcher <[email-masked]>; "
> [email-masked]" <[email-masked]>
> *Envoyé le :* Samedi 22 juin 2013 1h40
>

---

From: Martin Thomson <[email-masked]>
Date: Sun, 23 Jun 2013 20:02:27 -0700

> Is it possible to continue using SDP but not do o/a ?

Strictly speaking: yes.  In practice, however, some of the features that we
use depend on definitions that are only valid in the offer/answer context.
This includes security features.

Fixing that is possible, but it's easier to avoid SDP altogether.  Because
it's just not that hard to design an API without it.