Subject: [rtcweb] Checkpointing decisions in RTCWEB

From: Ted Hardie <[email-masked]>
Date: Thu, 7 Mar 2013 14:48:49 -0800

Howdy,

For any working group to be able to make consistent progress, it must
be able to rely on decisions that have already been taken to remain
stable in the absence of new technical issues.    Re-raising old
issues without new information does not help move the work forward,
and, as tempting as it may be for those who raised it the initial
times, nor does a chorus of "I thought that all along".

For the specific question in the thread entitled "Proposed Plan for
Usage of SDP and RTP - Lower level API minus SDP", I believe every
point in the thread has been raised before.  SDP has been unlovely and
arcane for many years, so this is not new news.  Despite that old
news, we have run consensus calls on this topic in both the IETF and
the W3C and agreed to use both it and offer/answer.

May I politely suggest we finish that work *before* we examine the
need and feasibility of an addtional, potentially lower-layer approach
to this?  Finishing the work before us does not close off all related
work for all time, but failure to produce something viable soon likely
will.

I'm not sure what hat to wear for this message, so assume a "grumpy
old timer" porkpie, size 7 and 3/8ths.

regards,

Ted Hardie

---

From: Mary Barnes <[email-masked]>
Date: Fri, 8 Mar 2013 08:49:41 -0600

As an individual that's also a chair, I truly do understand your pain.
 I realize that a change this late in the game is not at all a good
thing.  I also realize the impact this might have on folks whose
products are very entrenched in SDP (including my own employer).  But,
this seems very much to be a pay now or pay later situation.  I have
100% confidence that this energetic and intelligent group of folks can
come up with a protocol spec that relies on SDP - we have shown over
and over that we can eventually make decisions when there are strong
proponents with different approaches.  I don't debate that at all, but
I am concerned about interoperability issues and the fragility of SDP.
 This is not at all a new sort of problem - it's a pattern that exists
very often in product development.  In my experience, doing something
that seems a little more novel and disruptive can be done more quickly
than trying to work with existing code/architectures that are being
pushed well beyond their limits (based upon original design intent).
I've seen this time and again in developing products.

We also have a number of situations in IETF where we have been
determined to complete something based upon a decision that was made
and we have successfully completed protocol documents in these cases.
However, we have a number of these cases where those documents just
get put on a shelf.

Best Regards,
Mary

On Thu, Mar 7, 2013 at 4:48 PM, Ted Hardie <[email-masked]> wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Jim Barnett <[email-masked]>
Date: Fri, 8 Mar 2013 14:57:25 +0000

Mary,
  How can there be interoperability issues if no one is required to use SDP over the wire?  Are you saying that there are things that we need that SDP cannot express (or cannot be extended to express)?  

- Jim

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mary Barnes
Sent: Friday, March 08, 2013 9:50 AM
To: Ted Hardie
Cc: [email-masked]; [email-masked]
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB

As an individual that's also a chair, I truly do understand your pain.
 I realize that a change this late in the game is not at all a good thing.  I also realize the impact this might have on folks whose products are very entrenched in SDP (including my own employer).  But, this seems very much to be a pay now or pay later situation.  I have 100% confidence that this energetic and intelligent group of folks can come up with a protocol spec that relies on SDP - we have shown over and over that we can eventually make decisions when there are strong proponents with different approaches.  I don't debate that at all, but I am concerned about interoperability issues and the fragility of SDP.
 This is not at all a new sort of problem - it's a pattern that exists very often in product development.  In my experience, doing something that seems a little more novel and disruptive can be done more quickly than trying to work with existing code/architectures that are being pushed well beyond their limits (based upon original design intent).
I've seen this time and again in developing products.

We also have a number of situations in IETF where we have been determined to complete something based upon a decision that was made and we have successfully completed protocol documents in these cases.
However, we have a number of these cases where those documents just get put on a shelf.

Best Regards,
Mary

---

From: Adam Roach <[email-masked]>
Date: Fri, 8 Mar 2013 09:26:55 -0600

> However, we have a number of these cases where those documents just

I'm not sure which spec you're trying to warn us about never being deployed. The RTCWEB specification, for all its current holes, already has independent interoperable implementations in the field. 

/a

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 8 Mar 2013 07:33:21 -0800

Sorry for answering a question addressed to Mary, but it's important
to me to remind everyone that SDP isn't the only signalling protocol
in use, and that there isn't a 1:1 mapping between SDP and what
browsers support.

On Fri, Mar 8, 2013 at 6:57 AM, Jim Barnett <[email-masked]> wrote:
> Mary,
>   How can there be interoperability issues if no one is required to use SDP over the wire?

Not everything uses SDP over the wire.  Jingle devices and
applications don't use SDP over the wire.  If I'd like to interop with
Jingle applications and devices, I would not use SDP over the wire.

> Are you saying that there are things that we need that SDP cannot express (or cannot be extended to express)?

Of course there are things SDP cannot currently express.  For example,
the browser API has explicit methods to support trickle ICE because
SDP doesn't express it well.  It looks like we're going down the same
path with SCTP data channels: since SDP doesn't support SCTP data
channels currently, it's easier for the browser to express data
channels mostly outside of SDP rather than extend SDP.

Of course we can keep extending SDP to include more and more, but even
extending SDP isn't enough.  Just because there's an SDP extension
doesn't mean the browser supports it.  RFC5576, for example.  It's a
standardized extension to SDP, but is it supported by the browser?
There's enormous debate over whether it should be or not.

So, we already have the case that the browser does things that aren't
expressed in SDP, and SDP expresses things the browser can't do.
Extending SDP isn't always the right answer.

---

From: Mary Barnes <[email-masked]>
Date: Fri, 8 Mar 2013 10:36:09 -0600

>   How can there be interoperability issues if no one is required to use SDP over the wire?
[MB]  My concern is extrapolated a bit beyond just RTCWEB to the
extensions that are being proposed for SDP to support RTCWEB -
independent of whether RTCWEB uses it over the wire.  In cases where
folks want interop with "legacy" SIP some form of the SDP needs to go
over the wire.  In an ideal world, that would be the same SDP blob,
but it doesn't appear that would be the case where RTCWEB is now.
[/MB]

[MB] Are you saying that there are things that we need that SDP cannot
express (or cannot be extended to express)?
[MB] Right now, there are things you need in SDP that there is no
agreement as to how they should be expressed.  I agree that the group
could certainly pick a way and then try to live with it.  However,
some of these things overlap with what CLUE needs.  If CLUE wants to
use the same building blocks (and not create yet another way to do
multi-stream), then CLUE would reuse some of what is being driven to
meet RTCWEB requirements.  A CLUE application/endpoint will be using
the SDP over the wire.  As I said initially, I arrived at my current
position after seeing the lack of consensus that was being reached at
the interim meeting.  I could be a total pessimist and all this will
get figured out next week in Orlando, but I am typically over
optimistic about work getting done in IETF, so I'm wouldn't put any
money on it.
 [/MB]

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Mar 2013 10:45:18 -0600

> but it doesn't appear that would be the case where RTCWEB is now.

Much to my surprise, we actually saw exactly this mostly work at the 
SIPit in Boston. The places we fell down were ICE support and DTLS-SRTP, 
both of which are in the process of being adopted in SIP products at the 
moment.

> the SDP over the wire.

Given that most of the extensions under discussion are driven in equal 
measures by RTCWEB and CLUE, are you about to propose that CLUE move 
away from SDP as well? We could well charter a new WG for SDPNGNG.

/a

---

From: Mary Barnes <[email-masked]>
Date: Fri, 8 Mar 2013 11:08:13 -0600

On Fri, Mar 8, 2013 at 10:45 AM, Adam Roach <[email-masked]> wrote:
> Much to my surprise, we actually saw exactly this mostly work at the SIPit
> in Boston. The places we fell down were ICE support and DTLS-SRTP, both of
> which are in the process of being adopted in SIP products at the moment.
[MB2] Right, but that wasn't doing any of the multistream stuff was
it?   Or, did I miss something in the SIPit report?  Again, I don't
debate you wizards can make things work.  [/MB2]
> measures by RTCWEB and CLUE, are you about to propose that CLUE move away
> from SDP as well? We could well charter a new WG for SDPNGNG.
[MB2]  My personal opinion is that CLUE would do much better to
minimize its dependency on SDP.  We will use SIP for basic session
setup.  We are in the process of figuring out exactly what from the
CLUE data (see the FW and data model in CLUE) can or should be carried
in SDP.   I'm (as an individual) of the opinion that we should do bare
minimum in SDP - e.g., just what it takes to get a CLUE client
endpoint connected  to a non-CLUE endpoint.  I believe that the more
we put in SDP, the less extensible CLUE will be. I don't think that's
a good thing when we are defining a new application.  There are those
that believe we can signal lots of stuff in the SDP - that introduces
a tighter coupling between the CLUE data and SDP.  As I said for the
RTCWEB folks, I don't doubt that the CLUE folks can eventually get it
specified and made to work putting as much as possible in SDP.  I will
note that there are already deployed and interoperable telepresence
applications out there that do rely entirely on SIP and SDP, so I am
not suggesting it isn't possible, but the reason for chartering CLUE
was that the implementations are not standards based (despite there
being a specification that defines the interfaces) and not easily
extended.  That was the motivation for chartering CLUE.  Note, we will
be having this discussion in CLUE WG on Monday morning.

And, no I don't think we need SDPNGNG.  I think we need to decouple
our applications from the underlying session setup protocols.  [/MB2]

---

From: Robin Raymond <[email-masked]>
Date: Fri, 8 Mar 2013 14:05:02 -0500

On Fri, Mar 8, 2013 at 9:57 AM, Jim Barnett <[email-masked]>wrote:

> Mary,
>   How can there be interoperability issues if no one is required to use
> SDP over the wire?  Are you saying that there are things that we need that
> SDP cannot express (or cannot be extended to express)?
>
> - Jim
>
>
I just want to clarify something. Is the expectation that an application
developer can (if they so choose) take the SDP, parse it, extract the data,
send in an alternative format and then reassemble the SDP at the remote
side an accepted practice and an expected use case?

Regardless if it is or not, I'm positive that this extraction/assembly
process will be done but I want to make sure the expectation/use case is
absolutely clear. From what I've been reading, the expectation is the
browser generates "blob" and "blob" gets given to other party 'as is' but
perhaps I'm mistaken.

Further, the issue with SDP is also offer/answer. SDP isn't just a
arcane/obtuse format. It's a state machine and a media signalling protocol.
That causes a great deal of pain (breaks or messy hybrids) for other models
even if we can "disassemble and reassemble" SDP.

---

From: Jim Barnett <[email-masked]>
Date: Fri, 8 Mar 2013 19:33:13 +0000

My understanding is that SDP is an API surface _only_.  So, yes, the application developer can send whatever he wants over the wire.   (I imagine that a lot of implementations, including ours, will send the SDP to the other side, but it's not required.)

I tend to agree with a previous poster who suggests that we separate problems with the offer/answer state machine from problems with the SDP API surface.  We could keep the state machine but change the API surface, or change the API language and keep the state machine.

-          Jim

From: Robin Raymond [mailto:[email-masked]]
Sent: Friday, March 08, 2013 2:05 PM
To: Jim Barnett
Cc: Mary Barnes; Ted Hardie; [email-masked]
Subject: Re: [rtcweb] Checkpointing decisions in RTCWEB

On Fri, Mar 8, 2013 at 9:57 AM, Jim Barnett <[email-masked]<mailto:[email-masked]>> wrote:
Mary,
  How can there be interoperability issues if no one is required to use SDP over the wire?  Are you saying that there are things that we need that SDP cannot express (or cannot be extended to express)?

- Jim

I just want to clarify something. Is the expectation that an application developer can (if they so choose) take the SDP, parse it, extract the data, send in an alternative format and then reassemble the SDP at the remote side an accepted practice and an expected use case?

Regardless if it is or not, I'm positive that this extraction/assembly process will be done but I want to make sure the expectation/use case is absolutely clear. From what I've been reading, the expectation is the browser generates "blob" and "blob" gets given to other party 'as is' but perhaps I'm mistaken.

Further, the issue with SDP is also offer/answer. SDP isn't just a arcane/obtuse format. It's a state machine and a media signalling protocol. That causes a great deal of pain (breaks or messy hybrids) for other models even if we can "disassemble and reassemble" SDP.

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Fri, 8 Mar 2013 19:33:25 +0000

Classification: UNCLASSIFIED
Caveats: NONE

[MB2] ...  I think we need to decouple our applications from the underlying
session setup protocols.  [/MB2]

[RRR]
It is a good idea to do so as it is also seen somewhat in the centralized
conferencing FW (RFC 5239). Accordingly, all other things were developed and
most of them have been new protocols although SIP and SDP were kept as they
are without any extensions per se. Probably it was the case to do so for
this.

If we use the same principles for RTCWEB, we can write a framework document
based on the experiences that we have gained after almost working nearly
more than a year, we can then start to see where we need to do the
development of new protocols keeping SIP and SDP as they are if we think
that our efforts have met a wall.

The reason that we need to do so because we can do an analysis and see what
exactly our requirements are and why we need to start all over again with a
new approach. So far, we have some ideas in both ways with pros and cons,
but it is not entirely clear why and what we exactly need to do to change
our present approaches. Even we take a new approach, we need to a convincing
analysis beforehand we will succeed in solving problems with our new
approach before changing our direction again. [/RRR]

Classification: UNCLASSIFIED
Caveats: NONE

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Mar 2013 11:51:17 -0800

On 8 March 2013 11:33, Jim Barnett <[email-masked]> wrote:

>  My understanding is that SDP is an API surface _*only*_.  So, yes, the
> application developer can send whatever he wants over the wire.   (I
> imagine that a lot of implementations, including ours, will send the SDP to
> the other side, but it’s not required.)****
>
>
Even if this were the case, there are two important problems:
 - two browsers made by different vendors need to be able to produce and
consume SDP with predictable results.
- applications that do slice and dice need to be able to receive
predictable inputs and be able to produce outputs that are consumed by the
APIs in a predictable fashion.  Robin is right: applications will do this
because they have to.

Less important is the ability to take the product of a browser and send
that to a legacy endpoint, or do the same in the opposite direction.

> I tend to agree with a previous poster who suggests that we separate
> problems with the offer/answer state machine from problems with the SDP API
> surface.  We could keep the state machine but change the API surface, or
> change the API language and keep the state machine.
>
>  **
>
Both are problems, but yes, they are separable. Many things are almost
infinitely separable, but where separation can increase clarity, it can
also mask issues.  Caution advised.