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

From: Adrian Georgescu <[email-masked]>
Date: Tue, 18 Jun 2013 20:22:29 +0200

+1

While working with the specs, some may have realised that SDP is not such a great idea to put in practice and may also want to come forward to admit their mistake.

Regards,
Adrian

---

From: Matthew Jordan <[email-masked]>
Date: Tue, 18 Jun 2013 14:19:14 -0500

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

> +1
>
> While working with the specs, some may have realised that SDP is not such
> a great idea to put in practice and may also want to come forward to admit
> their mistake.
>
> Regards,
> Adrian
>
>
In the Asterisk project, we were able to use our legacy SIP stack to enable
very basic WebRTC communication with Chrome and FireFox. That sounds nice,
until you realize we have to continually preface that with "sometimes".

Because the answer is, more often than not, something breaks. Invariably,
the breakages have been in the SDPs sent to Asterisk by the browser. What
SDP breaks us changes depending on the browser being used, the version of
said browser, and whether or not some new WebRTC SDP feature has been put
in the browser's latest release. And just when we think we have to modify
Asterisk to handle the new SDP sent by some browser, the browser changes
again. As a result, Asterisk 11 hasn't changed a lot since we released;
we've been trying to avoid coding to a moving target. We always envisioned
that things would quiet down and the browsers would settle on an
implementation of SDP that we could adapt to - but it doesn't seem like
things are quieting down as much as we'd like. And sure, the SIP stack in
Asterisk is crufty, and sure, sometimes the fault is in our implementation,
not the browser's - but I think we on the Asterisk project can certainly
say that relying on SDP hasn't been a panacea for interoperability.

It feels like maintaining compatibility with "traditional" SDP
implementations is getting harder for the browsers to manage and holding
the entire process back. As one of those older "traditional"
implementations, I'd rather write an entirely new channel driver for
Asterisk than have to re-write our SDP handling.

So... +1 to Inaki's request.

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

---

From: Gustavo García <[email-masked]>
Date: Wed, 26 Jun 2013 19:29:59 -0400

"We reject kings, presidents and voting. We believe in rough consensus and running code". (IETF TAO)

- Lot of developers building stuff beyond a PSTN interconnection demo are having problems with the existing model.   Complexity, limitations and incompatibilities make us feel like fighting an API instead of using it.
- There are a lot of issues (bugs, incompatibilities, feature requests) because of SDP and O/A.  Take a look at webrtc issue tracker.
- The actual experience of people using the API should be a stronger argument than a voting done one year ago.  Specially when most of developers are not participating in IETF voting and after realizing the implications of SDP and O/A model f.e. on all those endless Plan-XXX  discussions.
- There is a much more simple solution (something like CU-RTC-Web) and you can always write a SDP/O/A/PeerConnection API on top of it (I had a prototype working in a couple of hours), but the other way around is much more hard if not impossible. 

In my opinion the only reasonable approaches are:
- Change the API now
- Change the API in one year

+1 to Iñaki's request too

G.

On 18/06/2013, at 15:19, Matthew Jordan wrote:

> 
> On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <[email-masked]> wrote:
> +1
> 
> In the Asterisk project, we were able to use our legacy SIP stack to enable very basic WebRTC communication with Chrome and FireFox. That sounds nice, until you realize we have to continually preface that with "sometimes".
> 
> Because the answer is, more often than not, something breaks. Invariably, the breakages have been in the SDPs sent to Asterisk by the browser. What SDP breaks us changes depending on the browser being used, the version of said browser, and whether or not some new WebRTC SDP feature has been put in the browser's latest release. And just when we think we have to modify Asterisk to handle the new SDP sent by some browser, the browser changes again. As a result, Asterisk 11 hasn't changed a lot since we released; we've been trying to avoid coding to a moving target. We always envisioned that things would quiet down and the browsers would settle on an implementation of SDP that we could adapt to - but it doesn't seem like things are quieting down as much as we'd like. And sure, the SIP stack in Asterisk is crufty, and sure, sometimes the fault is in our implementation, not the browser's - but I think we on the Asterisk project can certainly say that relying on SDP hasn't been a panacea for interoperability.
> 
> It feels like maintaining compatibility with "traditional" SDP implementations is getting harder for the browsers to manage and holding the entire process back. As one of those older "traditional" implementations, I'd rather write an entirely new channel driver for Asterisk than have to re-write our SDP handling.
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 26 Jun 2013 16:46:00 -0700

On Wed, Jun 26, 2013 at 4:29 PM, Gustavo García <[email-masked]> wrote:

> - Lot of developers building stuff beyond a PSTN interconnection demo are
> having problems with the existing model.   Complexity, limitations and
> incompatibilities make us feel like fighting an API instead of using it.
> - There are a lot of issues (bugs, incompatibilities, feature requests)
> because of SDP and O/A.  Take a look at webrtc issue tracker.
> - The actual experience of people using the API should be a stronger
> argument than a voting done one year ago.  Specially when most of
> developers are not participating in IETF voting and after realizing the
> implications of SDP and O/A model f.e. on all those endless Plan-XXX
>  discussions.
>

If there's a great "silent majority" out there, I think it would help the
WG a lot for them to come on the forum and give clear, concrete examples
(not ranty, please) of what they're trying to do and what their pain points
are.   I think that's much more helpful than just remaining silently in
pain.  On the flip side, if app developers love using the current API and
think SDP O/A is great, they should express that as well.

> - There is a much more simple solution (something like CU-RTC-Web) and you
> can always write a SDP/O/A/PeerConnection API on top of it (I had a
> prototype working in a couple of hours), but the other way around is much
> more hard if not impossible.
>

You know you're in trouble when CU-RTC-Web is considered "much more simple"
:).

I think your "bulid RtcPeerConnection on top in JS" is a great idea, but
you had a prototype in a couple of hours?  I have a hard time you could
implement much of SDP O/A correctly in a couple of ours.  And how could you
test such a thing, without a working implementation of CU-RTC-Web?

> - Change the API in one year
You could add:

- Change the API every couple weeks by changing what SDP is
generated/supported.

:)

> > While working with the specs, some may have realised that SDP is not
> such a great idea to put in practice and may also want to come forward to
> admit their mistake.
> >
> > Regards,
> > Adrian
> >
> >
> > In the Asterisk project, we were able to use our legacy SIP stack to
> enable very basic WebRTC communication with Chrome and FireFox. That sounds
> nice, until you realize we have to continually preface that with
> "sometimes".
> >
> > Because the answer is, more often than not, something breaks.
> Invariably, the breakages have been in the SDPs sent to Asterisk by the
> browser. What SDP breaks us changes depending on the browser being used,
> the version of said browser, and whether or not some new WebRTC SDP feature
> has been put in the browser's latest release. And just when we think we
> have to modify Asterisk to handle the new SDP sent by some browser, the
> browser changes again. As a result, Asterisk 11 hasn't changed a lot since
> we released; we've been trying to avoid coding to a moving target. We
> always envisioned that things would quiet down and the browsers would
> settle on an implementation of SDP that we could adapt to - but it doesn't
> seem like things are quieting down as much as we'd like. And sure, the SIP
> stack in Asterisk is crufty, and sure, sometimes the fault is in our
> implementation, not the browser's - but I think we on the Asterisk project
> can certainly say that relying on SDP hasn't been a panacea for
> interoperability.
> >

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Jun 2013 16:54:04 -0700

> You know you're in trouble when CU-RTC-Web is considered "much more simple"

When you are comparing to SDP O/A, pigs start looking like princesses.

> how could you test such a thing, without a working implementation of CU-RTC-Web?

http://html5labs.interoperabilitybridges.com/prototypes/cu-rtc-web-roaming/cu-rtc-web-roaming/info

Surely that's enough to build a proof of concept application.  I'm not
claiming that it's glamorous, far from it, there's some atrocious code
in there, but it's not a complete vacuum.

---

From: Gustavo Garcia Bernardo <[email-masked]>
Date: Wed, 26 Jun 2013 23:57:31 +0000

Getting the feeling of that silent mayority is what we are doing in this thread.  Hope we can put something together as Robin volunteered to lead.

There is a working implementation of cu-web-rtc, look for it in Microsoft html labs page.  Obviously my prototype is quick and dirty but you get my point on what you can do.

Sent from mobile

Peter Thatcher <[email-masked]> wrote:

On Wed, Jun 26, 2013 at 4:29 PM, Gustavo García <[email-masked]<mailto:[email-masked]>> wrote:
"We reject kings, presidents and voting. We believe in rough consensus and running code". (IETF TAO)

If there's a great "silent majority" out there, I think it would help the WG a lot for them to come on the forum and give clear, concrete examples (not ranty, please) of what they're trying to do and what their pain points are.   I think that's much more helpful than just remaining silently in pain.  On the flip side, if app developers love using the current API and think SDP O/A is great, they should express that as well.

You know you're in trouble when CU-RTC-Web is considered "much more simple" :).

I think your "bulid RtcPeerConnection on top in JS" is a great idea, but you had a prototype in a couple of hours?  I have a hard time you could implement much of SDP O/A correctly in a couple of ours.  And how could you test such a thing, without a working implementation of CU-RTC-Web?

You could add:

- Change the API every couple weeks by changing what SDP is generated/supported.

:)

G.

On 18/06/2013, at 15:19, Matthew Jordan wrote:

>
> On Tue, Jun 18, 2013 at 1:22 PM, Adrian Georgescu <[email-masked]<mailto:[email-masked]>> wrote:
> +1
>
> [email-masked]<mailto:[email-masked]>

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

________________________________

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 26 Jun 2013 17:02:23 -0700

> When you are comparing to SDP O/A, pigs start looking like princesses.

Nice.

> in there, but it's not a complete vacuum.

I didn't realize you had that out there.  Thanks for letting me know.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 26 Jun 2013 17:05:33 -0700

> I didn't realize you had that out there.  Thanks for letting me know.

The older version has different demos, I think:
http://html5labs.interopbridges.com/prototypes/cu-rtc-web/cu-rtc-web/info

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 26 Jun 2013 17:12:17 -0700

On Wed, Jun 26, 2013 at 4:57 PM, Gustavo Garcia Bernardo <[email-masked]> wrote:

>  Getting the feeling of that silent mayority is what we are doing in this
> thread.  Hope we can put something together as Robin volunteered to lead.
>
>
Even the "SDP rebellion" aside (by the way, you guys need some Star Wars
jokes), it would very useful to have a good idea of who is working on what
and how well the API is working for them, and what things could be added or
changed to help.   Most of the WG does seem to have any real experience
actually using the API, and I think that limits are ability to design the
right API.  More input from people actually using the API could only help,
and I look forward to hearing more.

 There is a working implementation of cu-web-rtc, look for it in Microsoft
> html labs page.  Obviously my prototype is quick and dirty but you get my
> point on what you can do.
>
>
I apologize if I missed the link to your prototype.  I'd like to see it.
 Can you repost the link?

>  If there's a great "silent majority" out there, I think it would help
> the WG a lot for them to come on the forum and give clear, concrete
> examples (not ranty, please) of what they're trying to do and what their
> pain points are.   I think that's much more helpful than just remaining
> silently in pain.  On the flip side, if app developers love using the
> current API and think SDP O/A is great, they should express that as well.
>
>
>> - There is a much more simple solution (something like CU-RTC-Web) and
>> you can always write a SDP/O/A/PeerConnection API on top of it (I had a
> ------------------------------
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar
> nuestra política de envío y recepción de correo electrónico en el enlace
> situado más abajo.
> This message is intended exclusively for its addressee. We only send and
> receive email on the basis of the terms set out at:

---

From: Marc Abrams <[email-masked]>
Date: Wed, 26 Jun 2013 20:05:12 -0700

It’s pretty telling when you have Digium and others making statements like “...that relying on SDP hasn't been a panacea for interoperability, “ or “... [they would] rather write an entirely new channel driver for Asterisk than have to re-write [their] SDP handling, “ you know that it’s not “just” an SDB Rebellion. It’s a problem. And waving your hands and claiming it’s necessary does not make SDP the solution. 

We should punt on SDP for v1.0 and move on. 

Thanks.

marc.
__________________
+1-949-270-0935

On Jun 26, 2013, at 5:12 PM, Peter Thatcher <[email-masked]> wrote:

> Even the "SDP rebellion" aside (by the way, you guys need some Star Wars jokes), it would very useful to have a good idea of who is working on what and how well the API is working for them, and what things could be added or changed to help.   Most of the WG does seem to have any real experience actually using the API, and I think that limits are ability to design the right API.  More input from people actually using the API could only help, and I look forward to hearing more.  
> 
> I apologize if I missed the link to your prototype.  I'd like to see it.  Can you repost the link?
>  
> 
> Sent from mobile
>

---

From: Alexandre GOUAILLARD <[email-masked]>
Date: Mon, 1 Jul 2013 09:52:58 +0800

dear all,

I will speak for the first time on this thread, so I guess I belong to that
silent majority. I will make some candid comments here, hoping this help.
This is *NOT* a call for more flame wars, far from it.

The reasons why it took me so long to write here are manifold. In order:
1. The repeated shocks coming from non-constructive posts (understatement
of the century), which make me feel like putting on my anti-riot
protection, hide behind a virtual pillar not to take a lost bullet or die
under friendly fire. (sometimes make me feel like being back in
junior-high, which is just a slight variation of the previous feeling).
2. the time needed to find, read and digest all the RFC / proposals and to
start getting the big picture.
3. the fact that it is difficult to articulate the pain points not knowing
what is supposed to be difficult, and what is difficult because of wrong
design. Coming from another field, and having a hacker mentality,
everything is equally new and challenging, and our team just went ahead and
find solutions. Being able to separate what is challenging because it's new
and what is challenging because it shouldn't be done  that way is hard at
best without the right background and the global picture in mind. That is
slowly changing.
4. I don't have a proposal to make it better at this stage.
5. webrct world is developing fast and we need to stay in the race,
allocating most of our time to development, and maybe not enough to the
standard part (our mistake). That is changing too.

ok, that might have helped to answer the why people are silent, but not
what should be done next. Here are a few more details.

1. we don't want to see webrtc being slow down. We would vote against
anything that bring us back to zero like a complete rewrite. We would favor
transition plans.
2. today, we manipulate SDP for the following things:
  - bandwidth limitation, as a temporary work around while corresponding
constraints are not honored.
  - codec order
  - ICE candidate priority
3. We are available to give comment on other people proposal (if most of
bitterness and non-constructive "I told you so", "i m not going to write a
draft for something that should already be there", "feel free to wait until
the end for my official rebuttal, so everybody will have lost their time"
messages are left at the door), and spend some time testing, but it's very
likely that we will *NOT* make a proposal ourselves.
4. We like the *concept* of separating functions/features in the peer
connection, and we are interested in the way datachannels are set up, *but*
we haven't took the time to dig into it enough. Now webrct expo in atlanta
is over, this should change, hence this e-mail.

HTH.

alex.

On Thu, Jun 27, 2013 at 11:05 AM, Marc Abrams <[email-masked]> wrote:

> It’s pretty telling when you have Digium and others making statements like
> “...that relying on SDP hasn't been a panacea for interoperability, “ or
> “... [they would] rather write an entirely new channel driver for Asterisk
> than have to re-write [their] SDP handling, “ you know that it’s not “just”
> an SDB Rebellion. It’s a problem. And waving your hands and claiming it’s
> necessary does not make SDP the solution.
>
>>> - Lot of developers building stuff beyond a PSTN interconnection demo
>>> are having problems with the existing model.   Complexity, limitations and