Subject: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 05:57:05 -0700

Google is in full support of "Plan B" for encoding multiple media sources
in SDP, and would like to see the Plan A vs. Plan B decision resolved soon.
 Recently, though, a third option, called "NoPlan" has been proposed, but
it lacked the details of what a JS API would look like for NoPlan.  Cullen
asked to see such an API proposal, and so I have worked with Emil to make
one.  He will be adding it to the NoPlan draft, but I will also include it
in this email.

Again, Google is in full support of "Plan B".  But if Plan A vs. Plan B
cannot be decided, then we support NoPlan with the following additions to
the WebRTC JS API as an option that allows implementing either Plan A or
Plan B  in Javascript.  And even if Plan A vs. Plan B is resolved, these
API additions would still be a big improvement for those WebRTC
applications that don't use SDP for signalling.

It is a bit long because I have added many comments and examples, but the
actually additions only include two new methods on PeerConnection and a few
new dictionaries.  So don't be overwhelmed :).

Intro: This follows the model of createDataChannel, which has a JS method
on PeerConnection that makes it possible to add data channels without going
through SDP.  Furthermore, just like createDataChannel allows 2 ways to
handle neogitation (the "I know what I'm doing;  Here's what I want to
send; Let me signal everything" mode and the "please take care of it for
me;  send an OPEN message" mode), this also has 2 ways to handle
negotiation (the "I know what I'm doing; Here's what I want to send; Let me
signal everything" mode and the "please take care of it for me;  send SDP
back and forth" mode).

Following the success of createDataChannel, this allows simple applications
to Just Work and more advanced applications to easily control what they
need to.  In particular, it's possible to use this API to implement either
Plan A or Plan B.

// The following two method are added to RTCPeerConnection
partial interface RTCPeerConnection {
 // Create a stream that is used to send a source stream.
 // The MediaSendStream.description can be used for signalling.
 // No media is sent until addStream(MediaSendStream) is called.
 LocalMediaStream createLocalStream(MediaStream sourceStream);

 // Create a stream that is used to receive media from the remote side,
 // given the parameters signalled from MedaiSendStream.description.
 MediaStream createRemoteStream(MediaStreamDescription description);
}

interface LocalMediaStream implements MediaStream {
  // This can be changed at any time, but especially before calling
  // PeerConnection.addStream
  attribute MediaStreamDescription description;
}

// Represents the parameters used to either send or receive a stream
// over a PeerConnection.
dictionary MediaStreamDescription {
  MediaStreamTrackDescription[] tracks;
}

// Represents the parameters used to either send or receive a track over //
a PeerConnection.  A track has many "flows", which can be grouped
// together.
dictionary MediaStreamTrackDescription {
  // Same as the MediaStreamTrack.id
  DOMString id;

  // Same as the MediaStreamTrack.kind
  DOMString kind;

  // A track can have many "flows", such as for Simulcast, FEC, etc.
  // And they can be grouped in arbitrary ways.
  MediaFlowDescription[] flows;
  MediaFlowGroup[] flowGroups;
}

// Represents the parameters used to either send or receive a "flow"
// over a PeerConnection.  A "flow" is a media that arrives with a
// single, unique SSRC.  One to many flows together make up the media
// for a track.  For example, there may be Simulcast, FEC, and RTX
// flows.
dictionay MediaFlowDescription {
  // The "flow id" must be unique to the track, but need not be unique
  // outside of the track (two tracks could both have a flow with the
  // same flow ID).
  DOMString id;

  // Each flow can go over its own transport.  If the JS sets this to a
  // transportId that doesn't have a transport setup already, the
  // browser will use SDP negotiation to setup a transport to back that
  // transportId.  If This is set to an MID in the SDP, then that MID's
  // transport is used.
  DOMString transportId;

  // The SSRC used to send the flow.
  unsigned int ssrc;

  // When used as receive parameters, this indicates the possible list
  // of codecs that might come in for this flow.  For exmample, a given
  // receive flow could be setup to receive any of OPUS, ISAC, or PCMU.
  // When used as send parameters, this indicates that the first codec
  // should be used, but the browser can use send other codecs if it
  // needs to because of either bandwidth or CPU constraints.
  MediaCodecDescription[] codecs;
}

dictionary MediaFlowGroup {
  DOMString type;  // "SIM" for Simulcast, "FEC" for FEC, etc
  DOMString[] flowids;
}

dictionary MediaCodecDescription {
  unsigned byte payloadType;
  DOMString name;
  unsigned int? clockRate;
  unsigned int? bitRate;
  // A grab bag of other fmtp that will need to be further defined.
  MediaCodecParam[] params;
}

dictionary MediaCodecParam {
  DOMString key;
  DOMString value;
}

Notes:

- When LocalMediaStreams are added using addStream, onnegotiatedneeded is
not called, and those streams are never reflected in future SDP exchanges.
 Indeed, it would be impossible to put them in the SDP without first
resolving if that would be Plan A SDP or Plan B SDP.

- Just like piles of attributes would need to be defined for Plan A and for
Plan B, similar attributes would need to be defined here (Luckily,  much
work has already been done figuring out what those parameters are :).

Pros:

- Either Plan A or Plan B or could be implemented in Javascript using this
API
- It exposes all the same functionality to the Javascript as SDP, but in a
much nicer format that is much easier to work with.
- Any other signalling mechanism, such as Jingle or CLUE could be
implemented using this API.
- There is almost no risk of signalling glare.
- Debugging errors with misconfigured descriptions should be much easier
with this than with large SDP blobs.

Cons:

- Now there are two slightly different ways to add streams: by creating a
LocalMediaStream first, and not.  This is, however, analogous to setting
"negotiated: true" in createDataChannel.  On way is "Just Work", and the
other is more advanced control.

- All the options in MediaCodecDescription are a bit complicated.  Really,
this is only necessary because Plan A requires being able to specify codec
parameters per SSRC, and set each flow on different transports.  If we did
not have this requirement, we could simplify.

Example Usage:

// Imagine I have MyApp, handles creating a PeerConnection,
// signalling, and rendering streams.  This is how the new API could be
// used.
var peerConnection = MyApp.createPeerConnection();

// On sender side:
var stream = MyApp.getMediaStream();
var localStream = peerConnection.createSendStream(stream);
sendStream.description = MyApp.modifyStream(localStream.description)
MyApp.signalAddStream(localStream.description, function(response)) {
  if (!response.rejected) {
    // Media will not be sent.
    peerConnection.addStream(localStream);
  }
}

// On receiver side:
MyApp.onAddStreamSignalled = function(streamDescription) {
  var stream = peerConnection.createReceiveStream(streamDescription);
  MyApp.renderStream(stream);
}

// In this exchange, the MediaStreamDescription signalled from the
// sender to the receiver may have looked something like this:

{
  tracks: [
  {
    id: "audio1",
    kind: "audio",
    flows: [
    {
      id: "main",
      transportId: "transport1",
      ssrc: 1111,
      codecs: [
      {
        payloadType: 111,
        name: "opus",
        // ... more codec details
      },
      {
        payloadType: 112,
        name: "pcmu",
        // ... more codec details
      }]
   }]
 },
 {
    id: "video1",
    kind: "video",
    flows: [
    {
      id: "sim0",
      transportId: "transport2",
      ssrc: 2222,
      codecs: [
      {
        payloadType: 122,
        name: "vp8"
        // ... more codec details
      }]
   },
   {
     id: "sim1",
     transportId: "transport2",
     ssrc: 2223,
     codecs: [
     {
       payloadType: 122,
       name: "vp8",
       // ... more codec details
     }]
   },
   {
     id: "sim2",
     transportId: "transport2",
     ssrc: 2224,
     codecs: [
     {
       payloadType: 122,
       name: "vp8",
       // ... more codec details
     }]
   },

   {
     id: "sim0fec",
     transportId: "transport2",
     ssrc: 2225,
     codecs: [
     {
       payloadType: 122,
       name: "vp8",
       // ...
     }]
   }],
   flowGroups: [
   {
     semantics: "SIM",
     ssrcs: [2222, 2223, 2224]
   },
   {
     semantics: "FEC",
     ssrcs: [2222, 2225]
   }]
 }]
}

Constructive feedback is welcome :).

---

From: Stefan Håkansson LK <[email-masked]>
Date: Mon, 17 Jun 2013 13:58:36 +0000

A couple of questions (to help me understand) in-line //Stefan

On 2013-06-17 14:57, Peter Thatcher wrote:
> Google is in full support of "Plan B" for encoding multiple media
> sources in SDP, and would like to see the Plan A vs. Plan B decision
> resolved soon.  Recently, though, a third option, called "NoPlan" has
> been proposed, but it lacked the details of what a JS API would look
> like for NoPlan.  Cullen asked to see such an API proposal, and so I
> have worked with Emil to make one.  He will be adding it to the NoPlan
> draft, but I will also include it in this email.
>
> cannot be decided, then we support NoPlan with the following additions
> to the WebRTC JS API as an option that allows implementing either Plan A
> or Plan B  in Javascript.  And even if Plan A vs. Plan B is resolved,
> these API additions would still be a big improvement for those WebRTC
> It is a bit long because I have added many comments and examples, but
> the actually additions only include two new methods on PeerConnection
> and a few new dictionaries.  So don't be overwhelmed :).
>
>
>
> Intro: This follows the model of createDataChannel, which has a JS
> method on PeerConnection that makes it possible to add data channels
> without going through SDP.  Furthermore, just like createDataChannel
> allows 2 ways to handle neogitation (the "I know what I'm doing;  Here's
> what I want to send; Let me signal everything" mode and the "please take
> care of it for me;  send an OPEN message" mode), this also has 2 ways to
> handle negotiation (the "I know what I'm doing; Here's what I want to
> me;  send SDP back and forth" mode).
>
> Following the success of createDataChannel, this allows simple
> applications to Just Work and more advanced applications to easily
> control what they need to.  In particular, it's possible to use this API
> to implement either Plan A or Plan B.
>

what would happen if the application adds or removes a track from 
sourceStream (I'm thinking on how what would impact the created 
LocalMediaStream and the MediaStream at the remote end)?

> // Represents the parameters used to either send or receive a track over
> // a PeerConnection.  A track has many "flows", which can be grouped
> // together.

Where from do you get transportId (e.g. if you want to re-use one)?

> - When LocalMediaStreams are added using addStream, onnegotiatedneeded
> is not called, and those streams are never reflected in future SDP
> exchanges.  Indeed, it would be impossible to put them in the SDP
> without first resolving if that would be Plan A SDP or Plan B SDP.
>
> - Just like piles of attributes would need to be defined for Plan A and
> for Plan B, similar attributes would need to be defined here (Luckily,
>   much work has already been done figuring out what those parameters are :).
>
>
> Pros:
>
> - Either Plan A or Plan B or could be implemented in Javascript using
> this API
> - It exposes all the same functionality to the Javascript as SDP, but in
> a much nicer format that is much easier to work with.
> - Now there are two slightly different ways to add streams: by creating
> a LocalMediaStream first, and not.  This is, however, analogous to
> setting "negotiated: true" in createDataChannel.  On way is "Just Work",
> and the other is more advanced control.
>
> - All the options in MediaCodecDescription are a bit complicated.
>   Really, this is only necessary because Plan A requires being able to
> specify codec parameters per SSRC, and set each flow on different
> transports.  If we did not have this requirement, we could simplify.
>
>
> Example Usage:
>

Should it say "localStream.description"?

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 08:13:29 -0700

Answers:

> LocalMediaStream and the MediaStream at the remote end)?
Good question.  I'd have to think about it some more, but off the bat, I'd
say that on the sender side, adding or removing tracks from the source
MediaStream would have no effect on what is sent.  In other words, it's as
if the source MediaStream were cloned when createLocalStream was called.
 If you want to modify the LocalStream, you have to go through the
.description.   On the receiver side, it would look like any other received
MediaStream: if you remove the track, it just doesn't play out anymore.

> Where from do you get transportId (e.g. if you want to re-use one)?

First, the browser would fill it in via createLocalStream.  So in almost
all cases, the JS would not need to set it.  In very advanced applications
that want to do tricky things with transports, then the value should be the
MID for that transport found in the SDP, as it says in the comment.

> Should it say "localStream.description"?

Yes. There was a last-minute rename and I missed a spot.  Anywhere you see
"sendStream", it should be "localStream".

---

From: Jim Barnett <[email-masked]>
Date: Mon, 17 Jun 2013 15:21:49 +0000

What can you modify in a LocalMediaStream by editing its description?  Can you add a video track to it?  That would imply calling gUM, and you’d  have to thread it’s success and failure callbacks up to the editing operation.  Or is the track list fixed, so that you can only tweak transport info by editing the LocalMediaStream’s description?

-          Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: Monday, June 17, 2013 11:13 AM
To: Stefan Håkansson LK
Cc: <[email-masked]>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Answers:

On Mon, Jun 17, 2013 at 6:58 AM, Stefan Håkansson LK <[email-masked]<mailto:[email-masked]>> wrote:
A couple of questions (to help me understand) in-line //Stefan

Good question.  I'd have to think about it some more, but off the bat, I'd say that on the sender side, adding or removing tracks from the source MediaStream would have no effect on what is sent.  In other words, it's as if the source MediaStream were cloned when createLocalStream was called.  If you want to modify the LocalStream, you have to go through the .description.   On the receiver side, it would look like any other received MediaStream: if you remove the track, it just doesn't play out anymore.

First, the browser would fill it in via createLocalStream.  So in almost all cases, the JS would not need to set it.  In very advanced applications that want to do tricky things with transports, then the value should be the MID for that transport found in the SDP, as it says in the comment.

Yes. There was a last-minute rename and I missed a spot.  Anywhere you see "sendStream", it should be "localStream".

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 09:20:52 -0700

On Mon, Jun 17, 2013 at 8:21 AM, Jim Barnett <[email-masked]>wrote:

>  What can you modify in a LocalMediaStream by editing its description?
> Can you add a video track to it?  That would imply calling gUM, and you’d
> have to thread it’s success and failure callbacks up to the editing
> operation.  Or is the track list fixed, so that you can only tweak
> transport info by editing the LocalMediaStream’s description?****
>
> **
>

If the JS calls gUM to get a second MediaStreamTrack (say, for screencast),
it could simply call createLocalStream again to add it, in a different
LocalMediaStream, and the remote end would get a second MediaStream by
calling createRemoteStream.  Why would you want more than one video
MediaStreamTrack in MediaStream at the same time?

In general, before you start sending or receiving, you can edit everything
side of the MediaStreamTrackDescription:  change the ssrcs, codecs,
transport, video resolution to send with, what repair flows to include,
whether to use simulcast, etc.  Basically, anything on a track level.

But I don't really see a use case where you would need to add tracks to a
MediaStreamTrackDescription, other than when parsing signalling and
building the MediaStreamTrackDescription to send down into
createRemoteStream.  Perhaps if we had a use case, we could define such
support.  But otherwise, I'd say it's not allowed.

-          **Jim****

** **

*From:* [email-masked] [mailto:[email-masked]] *On Behalf
Of *Peter Thatcher
*Sent:* Monday, June 17, 2013 11:13 AM
*To:* Stefan Håkansson LK
*Cc:* <[email-masked]>
*Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple
sources without encoding them in SDP)****

** **

Answers:****

** **

On Mon, Jun 17, 2013 at 6:58 AM, Stefan Håkansson LK <
[email-masked]> wrote:****

A couple of questions (to help me understand) in-line //Stefan****

On 2013-06-17 14:57, Peter Thatcher wrote:
> }****

what would happen if the application adds or removes a track from
sourceStream (I'm thinking on how what would impact the created
LocalMediaStream and the MediaStream at the remote end)?****

** **

** **

MediaStream: if you remove the track, it just doesn't play out anymore.****

** **

 ****

>    DOMString transportId;****

Where from do you get transportId (e.g. if you want to re-use one)?****

 ** **

First, the browser would fill it in via createLocalStream.  So in almost
all cases, the JS would not need to set it.  In very advanced applications
that want to do tricky things with transports, then the value should be the
MID for that transport found in the SDP, as it says in the comment. ****

 ****

> sendStream.description = MyApp.modifyStream(localStream.description)****

Should it say "localStream.description"?****

 ** **

Yes. There was a last-minute rename and I missed a spot.  Anywhere you see
"sendStream", it should be "localStream".****

 ****

> Constructive feedback is welcome :).****

 ** **

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Jun 2013 18:34:52 +0200

2013/6/17 Peter Thatcher <[email-masked]>:
> MediaStreamTrackDescription, other than when parsing signalling and building
> the MediaStreamTrackDescription to send down into createRemoteStream.
> Perhaps if we had a use case, we could define such support.  But otherwise,
> I'd say it's not allowed.

Use case:

- Start a session/call with just audio (no video requested to the user
via getUserMedia).
- Latter the user wants to add video.
- For that a new getUserMedia(video: true) is requested.
- Extract the video track from the obtained MediaStream and add it to the PC.

Hope this is an enough common use case.

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

---

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

In that use case, just call createLocalStream again with the new
MediaStream from GetUserMedia and get a new LocalMediaStream.  There's no
need to alter the existing one.

On Mon, Jun 17, 2013 at 9:34 AM, Iñaki Baz Castillo <[email-masked]> wrote:

> building

---

From: José Luis Millán <[email-masked]>
Date: Mon, 17 Jun 2013 20:52:01 +0200

Hi,

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

> need to alter the existing one.
On the receiver side, I would expect to represent each remote MediaStream
on its own audio+video display element.

If, as a sender, I create a new LocalStream to represent a change in an
existent media stream source, how will the receiver notice that the NEW
MediaStream does refer to the previous one?

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

-- 
José Luis Millán

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Jun 2013 11:57:44 -0700

Maybe you'd expect me to be more supportive of something that looked
so much like CU-RTC-Web.  It inherits all the worst properties of JSEP
(Offer/Answer, SDP editing) with a partial implementation of a clean
API.

It's comment 22-lite.  It's an abomination.  If you are going to do
this, do it properly.

On 17 June 2013 05:57, Peter Thatcher <[email-masked]> wrote:
> Google is in full support of "Plan B" for encoding multiple media sources in
> SDP, and would like to see the Plan A vs. Plan B decision resolved soon.
> Recently, though, a third option, called "NoPlan" has been proposed, but it
> lacked the details of what a JS API would look like for NoPlan.  Cullen
> Plan B  in Javascript.  And even if Plan A vs. Plan B is resolved, these API
> additions would still be a big improvement for those WebRTC applications
> that don't use SDP for signalling.
>
> Intro: This follows the model of createDataChannel, which has a JS method on
> PeerConnection that makes it possible to add data channels without going
> handle neogitation (the "I know what I'm doing;  Here's what I want to send;
> Let me signal everything" mode and the "please take care of it for me;  send
> an OPEN message" mode), this also has 2 ways to handle negotiation (the "I
> know what I'm doing; Here's what I want to send; Let me signal everything"
> mode and the "please take care of it for me;  send SDP back and forth"
> mode).
>
> to Just Work and more advanced applications to easily control what they need
> to.  In particular, it's possible to use this API to implement either Plan A
> or Plan B.
>

---

From: Emil Ivov <[email-masked]>
Date: Mon, 17 Jun 2013 21:09:52 +0200

On 17.06.13, 20:57, Martin Thomson wrote:
> so much like CU-RTC-Web.

No, but this doesn't mean you can't at least be constructive ...

> It inherits all the worst properties of JSEP

So here's your chance: could you please share your view of how this 
would look if done properly?

Emil

-- 
https://jitsi.org

---

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

Yes, I was expecting you to be more supportive.  I'm surprised out how your
want "all or nothing".  I'm afraid if our options for a clean API are all
or nothing, we'll just end up with nothing.  I'd prefer to try incremental
improvements to word toward (eventually) a clean API.

Do you think it is impossible to work toward a clean API in an incremental
approach?  If you think it's possible, I'd like to hear your thoughts on
how.

By the way, these API additions would greatly minimize the amount of SDP
editing necessary for JS clients that don't use SDP for signalling.  And
later incremental improvements could reduce it further.  Also, it's no
longer necessary to do offer/answer for adding tracks.  It's only the
intial PeerConnection setup that needs to do Offer/Answer.  So, it doesn't
inherit all the problems quite as much as you described.  It may be
slightly abominable, but I certainly consider it less abominable than the
SDP editing necessary without it.

On Mon, Jun 17, 2013 at 11:57 AM, Martin Thomson
<[email-masked]>wrote:

> sources in
> it
> method on
> send;
> applications
> need
> //
> for
> this
> a
>  Really,

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 12:32:38 -0700

What do you mean by "change to an existing media stream"?  Do you mean
adding and removing tracks?  I don't know of any other changes that can be
made to a MediaStream.

On Mon, Jun 17, 2013 at 11:52 AM, José Luis Millán <[email-masked]>wrote:

>> On Mon, Jun 17, 2013 at 9:34 AM, Iñaki Baz Castillo <[email-masked]>wrote:
>>

---

From: José Luis Millán <[email-masked]>
Date: Mon, 17 Jun 2013 21:42:52 +0200

Yes, just adding and removing tracks.

Regards

-- 
José Luis Millán

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 12:53:35 -0700

To remove a track, stop/remove the track locally and signal the fact that
the track is stopped to the remote side (in an app specific way).

To add a track, don't modify the existing MediaStream.  Create a new
MediaStream and call createLocalStream with the new MediaStream, and then
signal the MediaStreamDescription for it to the remote side.  If you really
want two MediaStreams to be merged into one MediaStream (the previous one
and the new one), signal that desire to the remote side (in an app specific
way), and the remote JS application can handle merging them.

The key here is that that we need an API for telling the browser how to
send tracks and how to receive tracks, and this provides it.  How those
tracks get arranged into MediaStreams can be done completely  by JS and
app-specific signalling.  In fact, we could model this entirely as
PeerConnection.createLocalTrack and createRemoteTrack instead of
.createLocalStream and createRemoteStream, but we kept is stream-oriented
because it works better with the existing methods in the simple cases.

On Mon, Jun 17, 2013 at 12:42 PM, José Luis Millán <[email-masked]>wrote:

>>> On the receiver side, I would expect to represent each remote
>>> MediaStream on its own audio+video display element.
>>>

---

From: Jim Barnett <[email-masked]>
Date: Mon, 17 Jun 2013 20:07:44 +0000

Peter,
You say that only initial PeerConnection set up requires offer answer.   Where is that in your example?  In the example, all we see on the receiving side is that it calls createReceiveStream.

-          Jim

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: Monday, June 17, 2013 3:26 PM
To: Martin Thomson
Cc: <[email-masked]>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Yes, I was expecting you to be more supportive.  I'm surprised out how your want "all or nothing".  I'm afraid if our options for a clean API are all or nothing, we'll just end up with nothing.  I'd prefer to try incremental improvements to word toward (eventually) a clean API.

Do you think it is impossible to work toward a clean API in an incremental approach?  If you think it's possible, I'd like to hear your thoughts on how.

By the way, these API additions would greatly minimize the amount of SDP editing necessary for JS clients that don't use SDP for signalling.  And later incremental improvements could reduce it further.  Also, it's no longer necessary to do offer/answer for adding tracks.  It's only the intial PeerConnection setup that needs to do Offer/Answer.  So, it doesn't inherit all the problems quite as much as you described.  It may be slightly abominable, but I certainly consider it less abominable than the SDP editing necessary without it.

On Mon, Jun 17, 2013 at 11:57 AM, Martin Thomson <[email-masked]<mailto:[email-masked]>> wrote:
Maybe you'd expect me to be more supportive of something that looked
so much like CU-RTC-Web.  It inherits all the worst properties of JSEP
(Offer/Answer, SDP editing) with a partial implementation of a clean
API.

On 17 June 2013 05:57, Peter Thatcher <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Jun 2013 14:23:38 -0700

On 17 June 2013 12:09, Emil Ivov <[email-masked]> wrote:
> So here's your chance: could you please share your view of how this would
> look if done properly?

Actually, it would look very similar to this.  For everything.  No SDP
anywhere.  It's comment 22.

It's in the archives of the webrtc list:
http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realtime-media.html

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Jun 2013 14:56:18 -0700

On 17 June 2013 12:26, Peter Thatcher <[email-masked]> wrote:
> want "all or nothing".  I'm afraid if our options for a clean API are all or
> nothing, we'll just end up with nothing.  I'd prefer to try incremental

Yes, I apologize if the language seemed strong, but I stand by those words.

The problem that I see with this, and it is a problem with any
incremental approach, is that it produces two very different
interaction models for things that are approximately the same
fundamental operation.

That is, when I add the first video track to a session I perform one
set of actions.  Then, when I add subsequent tracks, it's different.

This also has all the purported drawbacks of comment 22 with respect
to usability, whatever they are.  There must have been some because I
got a lot of heat about that when we discussed it.

> approach?  If you think it's possible, I'd like to hear your thoughts on

The fundamental problem in WebRTC is the Offer/Answer semantics in the
API.  That's hard to remove now.  I can't see an incremental change
that would remove that, and that's every bit as much of a problem as
having to deal with SDP.  That's how we got to comment 22.

I know that you wanted to do some sort of object representation of
SDP.  That can be done incrementally by adding to
RTCSessionDescription, or by replacing it entirely, but it doesn't
really go to the core of the problem.  If you were willing to tolerate
the fact that there would be two code paths, two control surfaces that
effectively did the same things.

> longer necessary to do offer/answer for adding tracks.  It's only the intial
> PeerConnection setup that needs to do Offer/Answer.  So, it doesn't inherit
> all the problems quite as much as you described.  It may be slightly
> abominable, but I certainly consider it less abominable than the SDP editing
> necessary without it.

If I am forced to do SDP, I'd rather not have something else as well
unless that something else is getting me something concrete.  What you
are proposing does too little to advance a cleaner API model to
justify the extra overhead that it introduces.  It doesn't tackle the
hard problems.

I appreciate the philosophy behind no-plan, which is not a non-plan in
any sense.  It addresses a concern that we (unfortunately) didn't
really touch on in the MMUSIC call this morning.  However, the
requirements of the-not-no-plan could be far more elegantly addressed
within the constraints of the current API without adding all those
extra description bits.

--Martin

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 17 Jun 2013 23:56:04 +0200

> http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realtime-media.html

+1

What is the aim of NoPlan? The draft says "This document does not
question the use of SDP and the Offer/Answer model". Why? It should
question it since it treats SDP as if it was a silly and unmanageable
binary blob. It is like "we must live with SDP because it is
mandatory, but let's try to ignore it as much as possible". If so, why
don't ignore SDP entirely?

However NoPlan is the best we have if, finally, SDP is mandated in WebRTC.

I think it is time to write two lists:

1) Advantages of using SDP in WebRTC.

2) Dissadvantages of using SPD in WebRTC.

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

---

From: Roman Shpount <[email-masked]>
Date: Mon, 17 Jun 2013 18:03:47 -0400

> 1) Advantages of using SDP in WebRTC.

Somebody wrote a bunch of code based on JSEP.

> 2) Dissadvantages of using SPD in WebRTC.

An unmanageable monster was created which currently stays in the way of
developing new functionality (bundle), building applications (does not
provide obvious ways to implement obvious tasks, like adding an extra
stream without re-negotiating all the existing ones) and even interop with
existing SIP endpoints (which was the original but now is complicated since
it would require a non trivial set of constraints and subsequent SDP
manipulation).
_____________
Roman Shpount

---

From: Robin Raymond <[email-masked]>
Date: Mon, 17 Jun 2013 20:13:44 -0400

Seems that this SDP issue keeps coming back with a bit of "I told you 
so" attached. It's truly awful and I've expressed my personal disdain 
previously. I've only kept quiet because I have no desire to stop WebRTC 
despite how personally horrible I find SDP. However bad it is I do want 
WebRTC released and hopefully this existing SDP based API can be 
deprecated -- fast. I want to see Microsoft onboard with WebRTC but I 
fully understand their position. I find it equally horrible for our Open 
Peer P2P signalling although we can "work around" it temporarily but it 
does hinder our ability to innovate. And when I refer to SDP I really 
mean SDP + offer/answer.

As I knew going in this effort is being primarily spearheaded by the SIP 
world and the push for SDP comes from that realm. At first I thought the 
SIP vendors would love it but I've refined my thinking and I think it's 
equally bad for SIP guys too if they were to think about the 
consequences. They are demanding features like crazy in the browser but 
have made the browser the bottle neck for innovation rather than 
allowing all their features to be implemented within JavaScript with 
media engine hooks inside the browser. The SDP produced by browsers 
won't likely be compatible with them anyway and they are likely to 
require SBCs to "fix" it. This is just bad, especially knowing how SIP 
guys love tweaking SIP for their own favourite flavours.

As much as I hate to say it, I think we need to hold off on releasing 
WebRTC as it is until we have a lower level API. SDP offer/answer is not 
going to cut it for the initial release, this first version of the 
standard needs to live on for at least a few years. We must deprecate 
the current WebRTC API in favour of a more suitable low-level 
replacement API. The revision should focus instead on the extensions 
that can be added in the JavaScript layer and only put the necessary 
hooks in the browser at the most basic level for a media and RTC engine 
to be controlled. Let's not hamper innovation!

If we need compatibility with the current WebRTC API it would be easy to 
create a JavaScript shim that supports the current API and allows a more 
long innovative approach. If there is interest in creating such a shim, 
I would be more than happy to be part of that development effort.

I've written more on the subject here but I don't want to post a long 
rant here: 
http://blog.webrtc.is/2013/06/17/sdp-inside-webrtc-is-bad-for-sip/

-Robin

> Martin Thomson <mailto:[email-masked]>
> 17 June, 2013 5:56 PM
> On 17 June 2013 12:26, Peter Thatcher<[email-masked]>  wrote:
> Peter Thatcher <mailto:[email-masked]>
> 17 June, 2013 3:26 PM
> Yes, I was expecting you to be more supportive.  I'm surprised out how 
> your want "all or nothing".  I'm afraid if our options for a clean API 
> are all or nothing, we'll just end up with nothing.  I'd prefer to try 
> incremental improvements to word toward (eventually) a clean API.
>
> Do you think it is impossible to work toward a clean API in an 
> incremental approach?  If you think it's possible, I'd like to hear 
> your thoughts on how.
>
>
> By the way, these API additions would greatly minimize the amount of 
> SDP editing necessary for JS clients that don't use SDP for 
> signalling.  And later incremental improvements could reduce it 
> further.  Also, it's no longer necessary to do offer/answer for adding 
> tracks.  It's only the intial PeerConnection setup that needs to do 
> Offer/Answer.  So, it doesn't inherit all the problems quite as much 
> as you described.  It may be slightly abominable, but I certainly 
> consider it less abominable than the SDP editing necessary without it.
>
>
>
> Martin Thomson <mailto:[email-masked]>
> 17 June, 2013 2:57 PM
> Peter Thatcher <mailto:[email-masked]>
> 17 June, 2013 8:57 AM
> Again, Google is in full support of "Plan B".  But if Plan A vs. Plan 
> B cannot be decided, then we support NoPlan with the following 
> additions to the WebRTC JS API as an option that allows implementing 
> either Plan A or Plan B  in Javascript.  And even if Plan A vs. Plan B 
> is resolved, these API additions would still be a big improvement for 
> those WebRTC applications that don't use SDP for signalling.
>
> allows 2 ways to handle neogitation (the "I know what I'm doing; 
>  Here's what I want to send; Let me signal everything" mode and the 
> "please take care of it for me;  send an OPEN message" mode), this 
> also has 2 ways to handle negotiation (the "I know what I'm doing; 
> Here's what I want to send; Let me signal everything" mode and the 
> "please take care of it for me;  send SDP back and forth" mode).
>
> control what they need to.  In particular, it's possible to use this 
> API to implement either Plan A or Plan B.
>
> // Represents the parameters used to either send or receive a track 
> over // a PeerConnection.  A track has many "flows", which can be grouped
> // together.
> - Just like piles of attributes would need to be defined for Plan A 
> and for Plan B, similar attributes would need to be defined here 
> (Luckily,  much work has already been done figuring out what those 
> parameters are :).
>
>
> Pros:
>
> - It exposes all the same functionality to the Javascript as SDP, but 
> in a much nicer format that is much easier to work with.
> - Debugging errors with misconfigured descriptions should be much 
> easier with this than with large SDP blobs.
>
>
> Cons:
>
> - Now there are two slightly different ways to add streams: by 
> creating a LocalMediaStream first, and not.  This is, however, 
> analogous to setting "negotiated: true" in createDataChannel.  On way 
> is "Just Work", and the other is more advanced control.
>

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 17 Jun 2013 17:14:00 -0700

2) Dissadvantages of using SDP in WebRTC.
Roman said:"An unmanageable monster was created which currently stays in the way of developing new functionality (bundle), building applications (does not provide obvious ways to implement obvious tasks, like adding an extra stream without re-negotiating all the existing ones) and even interop with existing SIP endpoints (which was the original but now is complicated since it would require a non trivial set of constraints and subsequent SDP manipulation)." [BA] Hard to argue with this, but I would point out that by far the ugliest part of the monster is the video hindquarters.  While one could argue that we have been living with the warts of SDP for audio and therefore know the workarounds, with video there are substantial interoperability issues, *even among vendors who utilize the same codec*, sometimes even in relatively basic scenarios (e.g. P2P video call with H.264/SVC).  So the "multivendor legacy of interop" just doesn't exist yet (at least, based on standards).  So as I see it, it does represent progress that we have contained the SDP monster's impact on the  the data channel, and I welcome Peter's effort to enable applications who don't care about SDP to minimize its usage even if it is not eliminated entirely.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 18 Jun 2013 11:00:36 +1000

Hi Peter, all,

I'm looking at all this from the view of a JS developer and I am
really excited that there is movement in this space. Having hit my
head hard against the limitations of the current WebRTC API and being
forced to learn SDP to achieve some of the less common use cases, I'm
feeling the pain. I am therefore happy to see that there is a proposal
for a higher-level API with similarities to the Microsoft's CU-WebRTC
proposal and I hope that together with Microsoft's input this can
become a really useful API.

What I would like to see, though, is a bit different from what you've
proposed. In particular, the MediaFlowDescription object is the one
object that I believe is supposed to enable JS developers to  do "SDP
hacking" without having to understand SDP. Unfortunately, the way in
which it is currently written, this API doesn't help a JS developer
much. There are properties in that object like "ssrc" that mean
nothing unless you understand SDP.

I would therefore like to recommend making the properties on the
MediaFlowDescription more semantic - in particular giving them better
names - such that a JS developer really doesn't have to understand SDP
to create/change media flow descriptions. Can we find better names for
 id, transportId and ssrc that are more explicitly expressing what
they stand for and when a JS developer would actually change them?

It would be nice if the MediaFlowDescription was abstract enough such
that in future it doesn't matter if SDP is actually underneath (with
offer/answer), but that's not actually my main goal. What I'm after is
an API that can be used without having to understand what is
underneath.

Thanks for listening and HTH,
Silvia.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 18 Jun 2013 01:35:05 +0000

The problem is that all sorts of interesting use cases are hampered by having a giant object that encapsulates everything and which is controlled with a pointy SDP stick or even a stick that has the SDP covered in tape and glue.

Here’s an example case I’d love to have someone show me how to do with the current API:

  Open a connection between client A and client B that tests for a peer-to-peer path between client A and client B (by doing a STUN connectivity test) but which prefers to send media via a relayed path (over my own private fiber backbone).

I want to do the connectivity test so that I know whether when there’s a path failure I need to instantiate a new relay path or I can just fall back to the Internet path. Oh, and I’d like to collect the derived addresses and some other stats from the connectivity test so I can feed that back into my big data analysis system.

Other than opening a second full PeerConnection object, I don’t see that I have enough control over the candidate selection, even if I mangle the SDP, and certainly not at all if I don’t.

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Thatcher
Sent: Monday, June 17, 2013 12:26 PM
To: Martin Thomson
Cc: <[email-masked]>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 18 Jun 2013 01:37:58 +0000

Note that “all or nothing” doesn’t mean “take it or leave it with regard to the full CU-RTCWEB proposal from Microsoft”. It means “keep SDP offer/answer and the big blob of text and all that” or “start with the CU-RTCWEB proposal as a base and use community input and consensus to make it into something even better”.

Matthew Kaufman

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 18 Jun 2013 01:41:55 +0000

Inline below

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: Monday, June 17, 2013 3:04 PM
To: Iñaki Baz Castillo
Cc: <[email-masked]>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

On Mon, Jun 17, 2013 at 5:56 PM, Iñaki Baz Castillo <[email-masked]<mailto:[email-masked]>> wrote:

MK: And some other people thought that using SDP offer/answer would magically get full interoperability with existing SIP+SDP O/A systems.

An unmanageable monster was created which currently stays in the way of developing new functionality (bundle), building applications (does not provide obvious ways to implement obvious tasks, like adding an extra stream without re-negotiating all the existing ones) and even interop with existing SIP endpoints (which was the original but now is complicated since it would require a non trivial set of constraints and subsequent SDP manipulation).

MK: Pretty much sums it up, including the fallacy of SIP interop. And note that the SIP interop issue isn't just that there's no SIP systems that have ICE (which we need to protect people from their browser) and DTLS-SRTP (which we need if we don't get SRTP w/SDES)... in fact there's a draft summarizing many (but not all) of the *other* things that don't interoperate between the two without SDP mangling.

_____________

Roman Shpount

---

From: Robin Raymond <[email-masked]>
Date: Mon, 17 Jun 2013 22:54:33 -0400

I actually need access to the raw controls like SSRC, detailed ICE 
candidate control, encryption keying, etc, and as much control over how 
media should be controlled/behave as possible. Those things are 
extremely important for interoperability and signaling and have specific 
meaning for those who deal with that kind of stuff daily.

However, as a JavaScript developer, you likely need a simple high level 
API. Why should you care about all that low level junk? It's meaningless 
nonsense to you.

Real-Time Communication is hard because there is a lot involved, 
especially if there is any kind of compatibility, advanced features or 
network control. Nobody wants a difficult API for the sake of being 
difficult, especially for a sleek language like JavaScript. It's more 
that it's just necessary if we audio/video people want to do some really 
cool features that work with new or existing platforms, devices and 
services.

But we can have the best of both worlds! There are many people who are 
in this RTC domain who can wrap that lower level API to give very simple 
and easy to understand conceptual APIs that abstract that weird funky 
stuff away. I'd be one of those people to offer such a simpler library 
(along with many others I'm sure).

In some way, it's not all that dissimilar with DOM and CSS3, etc.; 
jQuery and jQuery UI (and other libraries) create wrappers to make 
access and control easier but for those who need to raw control they 
have it. Most people use wrappers and toolkits when they are trying to 
do the standard stuff, but someone put together the APIs originally to 
make common use cases.

On a side note, I agree that SDP should go (and quickly) but it's not 
the format that's the problem. Granted, it is obtuse. But it's not just 
that; it's a monolithic do-everything offer/answer model that offers 
very little control and the API to control the browser's RTC is 
effectively via manipulation of the SDP. Yuck! Even if it were fancier 
and prettier JSON, it would still be an ugly do-everything monolithic 
object with a sketchy offer/answer model that is brittle and offered 
very little real-scenario controls for those whom need it. It's 
absolutely horrible and is in good need of quick deprecation.

-Robin

> Silvia Pfeiffer <mailto:[email-masked]>
> 17 June, 2013 9:00 PM
> Hi Peter, all,
>

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 18 Jun 2013 13:27:27 +1000

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

> media should be controlled/behave as possible. Those things are extremely
> important for interoperability and signaling and have specific meaning for
> those who deal with that kind of stuff daily.
>

Sure - but if you need to hack SDP directly, you're already able to do that.

> difficult, especially for a sleek language like JavaScript. It's more that
> it's just necessary if we audio/video people want to do some really cool
> features that work with new or existing platforms, devices and services.
>
> But we can have the best of both worlds!
>

Agreed, that's what I'm after, but not as a library, but rather as part of
the WebRTC API.

> There are many people who are in this RTC domain who can wrap that lower
> level API to give very simple and easy to understand conceptual APIs that
> abstract that weird funky stuff away. I'd be one of those people to offer
> such a simpler library (along with many others I'm sure).
>

I think you should write a proposal!

> In some way, it's not all that dissimilar with DOM and CSS3, etc.; jQuery
> and jQuery UI (and other libraries) create wrappers to make access and
> control easier but for those who need to raw control they have it. Most
> people use wrappers and toolkits when they are trying to do the standard
> stuff, but someone put together the APIs originally to make common use
> cases.
>

jQuery was necessary because HTML did not evolve. Now that a lot of the
jQuery APIs have been added to HTML directly, you can even get away pretty
well without using jQuery.

On a side note, I agree that SDP should go (and quickly) but it's not the
> format that's the problem. Granted, it is obtuse. But it's not just that;
> it's a monolithic do-everything offer/answer model that offers very little
> control and the API to control the browser's RTC is effectively via
> manipulation of the SDP. Yuck! Even if it were fancier and prettier JSON,
> it would still be an ugly do-everything monolithic object with a sketchy
> offer/answer model that is brittle and offered very little real-scenario
> controls for those whom need it. It's absolutely horrible and is in good
> need of quick deprecation.
>

Right - by providing a higher level abstraction of it, you'd enable that
stuff underneath to be replaced. I don't have a good handle on SDP, so but
I think what is proposed can be improved. If you have any ideas on how to,
this would be a good time to help out, IMHO.

Cheers,
Silvia.

> -Robin
>
>
>
>
>   Silvia Pfeiffer <[email-masked]>
>  17 June, 2013 9:00 PM
> Hi Peter, all,
>
>   Peter Thatcher <[email-masked]>
>  17 June, 2013 8:57 AM
> applications to Just Work and more advanced applications to easily control
> what they need to.  In particular, it's possible to use this API to
> implement either Plan A or Plan B.
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 17 Jun 2013 21:01:27 -0700

> need of quick deprecation.

I think that this sums up my views on the subject.  Offer/answer is at the
heart of this.  SDP is just the ugly wrapper that attracts all the heat.
SDP isn't so bad if you are doing SAP.  Of course, once you drop O/A, then
you have to build something else.

I made a start at that, but I caution, this approach was soundly rejected:
http://lists.w3.org/Archives/Public/public-webrtc/2012Oct/att-0076/realtime-media.html

No matter how right you are, the political reality is that it's not cool to
raise comment 22.

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 22:27:13 -0700

On Mon, Jun 17, 2013 at 2:56 PM, Martin Thomson <[email-masked]>wrote:

> your
I don't thing we have to have two different sets of actions.  If a JS app
chooses, it could use createLocalStream and createRemoteStream for all of
its streams, and only use SDP for setting up the transport.  For example, I
could choose to write JS that would setup one transport with one call to
createOffer/setLocalDescription/setRemoteDescription (ignore trickle ICE
and ICE restarts for them moment) and bundle all media over it.  That means
the SDP is really just used as a way to tell the browser what ice ufrag,
ice pwd, and DTLS fingerprint to use.  It would look something like this
(forgive me if I got the SDP slightly wrong;  it's easy to get wrong):

v=0
o=- 697639972863421376 2 IN IP4 127.0.0.1
s=-
t=0 0
m=application 1 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=mid:transport

a=ice-ufrag:tEP42he9r6LycvmM
a=ice-pwd:cKJLuvHy9pas9rdezUZB9xet
a=fingerprint:sha-256
EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79:C4:95:9C

Ignoring ICE candidates and restarts, that's all the SDP what would be
needed for the whole PeerConnection (one for the local and one for the
remote).  The first set of streams has the same actions as the 100th set of
streams, if the JS chooses.

10 lines of SDP just to setup a transport isn't quite such an abomination,
is it?

> incremental

There are two places we currently have offer/answer: 1.  To setup the
transports.  2.  To define the streams.  And once upon a time, there was
going to be 3.  To define the data channels.  We were able to prevent #3
and just have data channel be defined in terms of createDataChannel, and
not in terms of SDP.  That was good, was it not?  What I'm proposing is
that we do something similar for audio and video streams (#2).  That way,
all that you need to use SDP for would be #1 (to setup the transports).
 And someday, we might be able to improve that as well (perhaps a future
.createTransport method).

> intial

You're not forced to do SDP, except for the transports.  For defining the
streams, you can avoid SDP altogether.  As a WebRTC JS app developer, I
know I would find working with this API much better than working with SDP
munging.

> within the constraints of the current API without adding all those

I'm a bit confused.  Do you consider changes to SDP more elegant than
dictionaries like MediaStreamTrackDescription?  I would find that somewhat
ironic.  Or are you suggesting there's a way I can simplify all the
"description bits".  If there's a specific way I can simply it to make it
better, I'd lover to hear it.

And, thanks for your feedback.  I hope my response about not requiring SDP
for the first streams helps clarify.

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 22:30:46 -0700

As I mentioned in the previous email, I think O/A is use in two different
ways: transport and streams.  I believe it's mostly painful for adding
streams, and less painful for establishing the transport.  If we allowed
adding streams without O/A, we'd have relieved more than half the pain, or
at least more than half the pain I experience.   And that's just what I'm
proposing we allow with createLocalStream/createRemoteStream.

On Mon, Jun 17, 2013 at 9:01 PM, Martin Thomson <[email-masked]>wrote:

> No matter how right you are, the political reality is that it's not cool
> to raise comment 22.
>

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 22:34:08 -0700

I like your comparison to the data channels.  As I just pointed out in
another email, I think it was good that we "contained the SDP monster", as
you put it, with createDataChannel.  One of the purposes of
createLocalStream/createRemoteStream is to allow a JS app, if it chooses,
to "contain the SDP monster" when adding media streams.  It would still be
needed for setting up the PeerConnection's transport (a monster container
for a future day perhaps), but that's still significant progress in my
book, and it does so with simple additions to the PeerConnection that don't
attempt to blow up the WG.

On Mon, Jun 17, 2013 at 5:14 PM, Bernard Aboba <[email-masked]>wrote:

> Roman said:
> "An unmanageable monster was created which currently stays in the way of
> manipulation)."
> [BA] Hard to argue with this, but I would point out that by far the
> ugliest part of the monster is the video hindquarters.  While one could
> argue that we have been living with the warts of SDP for audio and
> therefore know the workarounds, with video there are substantial
> interoperability issues, *even among vendors who utilize the same
> codec*, sometimes even in relatively basic scenarios (e.g. P2P video call
> with H.264/SVC).  So the "multivendor legacy of interop" just doesn't exist
> yet (at least, based on standards).
>
> So as I see it, it does represent progress that we have contained the SDP
> monster's impact on the  the data channel, and I welcome Peter's effort to
> enable applications who don't care about SDP to minimize its usage even if
> it is not eliminated entirely.
>

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 22:44:53 -0700

I need to write a more complete example, but it basically would be:

var signalling = new AppSpecificSignalling();
var stream = getUserMedia(...);  // For the example, imagine it's
synchronous.
var pc = new PeerConnection(...);
var dc = pc.createDataChannel(...);
pc.createOffer(function(offer) {
  pc.setLocalDescription(offer);
  signalling.swapTransportParams(offer.sdp, function(answerSdp) {
    pc.setRemoteDescription(new SessionDescription(answerSdp);
  });
});
var localStream = pc.createLocalStream(stream);
signalling.addStream(localStream.description);
signalling.onStreamAdded = function(remoteStreamDescription) {
  var remoteStream = pc.createRemoteStream(stream);
  // Render the remoteStream.
});

And in all of this, the only SDP involved would be to setup the transport
the data channel, which would then be used to BUNDLE audio and video over
the same (with rtcp-mux, naturally).  Something like this:

v=0 o=- 697639972863421376 2 IN IP4 127.0.0.1
s=-
t=0 0
m=application 1 DTLS/SCTP 5000
c=IN IP4 0.0.0.0
a=mid:transport

10 lines of SDP (per side) is, relatively speaking, very small, and it
really only contains three values: ice-ufrag/ice-pwd, and dtsl fingerprint.

I may be missing something, but I think this would work.  If anyone knows a
reason why it wouldn't, I'm sure you'll let me know :).

On Mon, Jun 17, 2013 at 1:07 PM, Jim Barnett <[email-masked]>wrote:

>  Peter,****
>
> You say that only initial PeerConnection set up requires offer answer.
>   Where is that in your example?  In the example, all we see on the
> receiving side is that it calls createReceiveStream.****
>
> ** **
>
> **-          **Jim ****
>
> ** **
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Peter Thatcher
> *Sent:* Monday, June 17, 2013 3:26 PM
> *To:* Martin Thomson
>
> *Cc:* <[email-masked]>
> your want "all or nothing".  I'm afraid if our options for a clean API are
> all or nothing, we'll just end up with nothing.  I'd prefer to try
> incremental improvements to word toward (eventually) a clean API. ****
>
> ** **
>
> how. ****
> SDP editing necessary without it.****
>
> ** **
>
> On Mon, Jun 17, 2013 at 11:57 AM, Martin Thomson <[email-masked]>
> wrote:****
>
> this, do it properly.****
>
>

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 17 Jun 2013 22:48:19 -0700

We're being very explicit that this isn't intended to blow up the WG like
comment 22 does.  It's merely adding two methods to PeerConnection that
allows JS apps to optionally avoid the issues of adding many media streams
to SDP.  We're focusing on making the smallest change that can bring the
biggest value, not rewriting all of WebRTC from scratch.

---

From: Emil Ivov <[email-masked]>
Date: Tue, 18 Jun 2013 08:17:09 +0200

Hey Silvia,

> nothing unless you understand SDP.

SSRC is really just a flow identifier and it actually comes from RTP, 
not SDP.

Using SSRCs is important because they are the only way to refer to an 
RTP flow. Any other identifier (such as an MSID) would have to be mapped 
to an SSRC. Such a mapping could only happen in SDP and would have to be 
updated when new streams are added which brings us back to over-reliance 
on SDP Offer/Answer, which is what No Plan is trying to alleviate.

Emil

-- 
https://jitsi.org

---

From: Silvia Pfeiffer <[email-masked]>
Date: Tue, 18 Jun 2013 16:25:05 +1000

On Tue, Jun 18, 2013 at 4:17 PM, Emil Ivov <[email-masked]> wrote:
> SSRC is really just a flow identifier and it actually comes from RTP, not
> SDP.

OK, could we call it rtpflowId or mediaflowId or peerflowId or
something? And what exactly are the other identifiers?
(You will notice that I am really naive wrt SDP, sorry!)

Thanks,
Silvia.

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Jun 2013 10:11:37 +0200

On 06/17/2013 06:20 PM, Peter Thatcher wrote:
>
>
>
> On Mon, Jun 17, 2013 at 8:21 AM, Jim Barnett 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     What can you modify in a LocalMediaStream by editing its
>     description?  Can you add a video track to it?  That would imply
>     calling gUM, and you'd  have to thread it's success and failure
>     callbacks up to the editing operation.  Or is the track list
>     fixed, so that you can only tweak transport info by editing the
>     LocalMediaStream's description?
>
>
> If the JS calls gUM to get a second MediaStreamTrack (say, for 
> screencast), it could simply call createLocalStream again to add it, 
> in a different LocalMediaStream, and the remote end would get a second 
> MediaStream by calling createRemoteStream.  Why would you want more 
> than one video MediaStreamTrack in MediaStream at the same time?
>
> In general, before you start sending or receiving, you can edit 
> everything side of the MediaStreamTrackDescription:  change the ssrcs, 
> codecs, transport, video resolution to send with, what repair flows to 
> include, whether to use simulcast, etc.  Basically, anything on a 
> track level.

This raises an interesting issue: Anything the user is allowed to set, 
the UA has to assume that the user can get wrong. So we need to have 
error handling for AddLocalStream saying "sorry, this is impossible".

Perennial question: Exception or callback?

>
> But I don't really see a use case where you would need to add tracks 
> to a MediaStreamTrackDescription, other than when parsing signalling 
> and building the MediaStreamTrackDescription to send down into 
> createRemoteStream.  Perhaps if we had a use case, we could define 
> such support.  But otherwise, I'd say it's not allowed.
>
>
> -Jim
>
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked] <mailto:[email-masked]>] *On 
> *Cc:* <[email-masked] <mailto:[email-masked]>>
> *Subject:* Re: [rtcweb] Proposal for a JS API for NoPlan (adding 
> multiple sources without encoding them in SDP)
>
> Answers:
>
> On Mon, Jun 17, 2013 at 6:58 AM, Stefan Håkansson LK 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Good question.  I'd have to think about it some more, but off the bat, 
> I'd say that on the sender side, adding or removing tracks from the 
> source MediaStream would have no effect on what is sent.  In other 
> words, it's as if the source MediaStream were cloned when 
> createLocalStream was called.  If you want to modify the LocalStream, 
> you have to go through the .description. On the receiver side, it 
> would look like any other received MediaStream: if you remove the 
> track, it just doesn't play out anymore.
>
>     >
>     >
> First, the browser would fill it in via createLocalStream.  So in 
> almost all cases, the JS would not need to set it.  In very advanced 
> applications that want to do tricky things with transports, then the 
> value should be the MID for that transport found in the SDP, as it 
> says in the comment.
>
>
>     >
>     creating
> Yes. There was a last-minute rename and I missed a spot.  Anywhere you 
> see "sendStream", it should be "localStream".
>
>
>     >    var stream =
>     peerConnection.createReceiveStream(streamDescription);

---

From: Stefan Håkansson LK <[email-masked]>
Date: Tue, 18 Jun 2013 08:27:46 +0000

On 2013-06-17 18:21, Peter Thatcher wrote:
>
>
>
> On Mon, Jun 17, 2013 at 8:21 AM, Jim Barnett <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     calling gUM, and you’d  have to thread it’s success and failure
>     callbacks up to the editing operation.  Or is the track list fixed,
>     so that you can only tweak transport info by editing the
>     LocalMediaStream’s description?____
>
>     __
>
>
> screencast), it could simply call createLocalStream again to add it, in
> a different LocalMediaStream, and the remote end would get a second
> MediaStream by calling createRemoteStream.  Why would you want more than
> one video MediaStreamTrack in MediaStream at the same time?

I think there are use-cases for that, especially if keep the notion of 
that sync is maintained within a MediaStream but not across different MS's.

You could easily imagine that you have two cameras capturing the same 
speaker. You'd want lip sync when rendering at a remote peer regardless 
of which video that is played.

> include, whether to use simulcast, etc.  Basically, anything on a track
> level.
>
> But I don't really see a use case where you would need to add tracks to
> a MediaStreamTrackDescription,

I agree - but that is obvious (a MediaStreamTrackDescription describes 
exactly one MediaStreamTrack). But there are use-cases for adding tracks 
to a MediaStream description.

> other than when parsing signalling and
> -__Jim____
> __ __
> multiple sources without encoding them in SDP)____
>
> __ __
>
> Answers:____
>
> __ __
>
> <mailto:[email-masked]>> wrote:____
>
> A couple of questions (to help me understand) in-line //Stefan____
>
>
>  > }____
> LocalMediaStream and the MediaStream at the remote end)?____
>
> __ __
>
> __ __
>
> would look like any other received MediaStream: if you remove the track,
> it just doesn't play out anymore.____
>
> __ __
>
> ____
>
>      >
>      >
>      >    DOMString transportId;____
>
>     Where from do you get transportId (e.g. if you want to re-use one)?____
>
> __ __
>
> all cases, the JS would not need to set it.  In very advanced
> value should be the MID for that transport found in the SDP, as it says
> in the comment. ____
>
> ____
>
>
>      >
>      > sendStream.description =
>     MyApp.modifyStream(localStream.description)____
>
>     Should it say "localStream.description"?____
>
> __ __
>
> see "sendStream", it should be "localStream".____
>
> ____
>
>
>      > Constructive feedback is welcome :).____
>
> __ __
>
>

---

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

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

> That means the
> SDP is really just used as a way to tell the browser what ice ufrag, ice
> pwd, and DTLS fingerprint to use.

And do we really need SDP for that? mandatory?

> It would look something like this

Unneeded line v.

> o=- 697639972863421376 2 IN IP4 127.0.0.1

Unneeded line o.

> t=0 0

Unneeded lines s and t.

> m=application 1 DTLS/SCTP 5000

Why is this required at all?

> c=IN IP4 0.0.0.0

Anti-useful c line.

> a=mid:transport

What else can it be?

> EC:E0:95:43:B7:01:49:8B:BC:21:CC:41:7F:10:FD:92:28:B8:F8:41:07:70:77:7D:7C:47:92:30:79:C4:95:9C

Finally we get 3 useful fields (related to ICE and encryption). And
are we going to mandate SDP O/A for this? really? I really hope NOT.

> remote).

And WHY do we need to *mandate* SDP for that? Why don't we define a
IceData object, something that can be serialized in JSON to be sent to
the remote peer in any custom way? Why should we deal with blob
strings in an old-school format?

> 10 lines of SDP just to setup a transport isn't quite such an abomination,

Yes, because we don't need those 10 lines, but just 3 string values.

> streams, you can avoid SDP altogether.  As a WebRTC JS app developer, I know
> I would find working with this API much better than working with SDP
> munging.

And what is the advantage of mandating usage of SDP for the transport
(over letting the user communicate it to the browser via API by
passing some JS object?).

Regards.

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

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 18 Jun 2013 10:38:48 +0200

On 06/18/2013 07:44 AM, Peter Thatcher wrote:
> And in all of this, the only SDP involved would be to setup the 
> transport the data channel, which would then be used to BUNDLE audio 
> and video over the same (with rtcp-mux, naturally).  Something like this:
>
> I may be missing something, but I think this would work.  If anyone 
> knows a reason why it wouldn't, I'm sure you'll let me know :).

At the risk of adding some more complexity:

if both sides add the offerToReceiveVideo=true constraint, the SDP will 
also include M-lines for audio and video, indicating supported codecs, 
which allows the initial offer/answer to supply information that allows 
the UA to check that the parameters to the addLocalStream / 
addRemoteStream calls actually make sense in context, that payload type 
numbers actually mean what they're supposed to mean, and so on.

You know, what SDP was originally designed for....

>
>
>
> On Mon, Jun 17, 2013 at 1:07 PM, Jim Barnett 
>     You say that only initial PeerConnection set up requires offer
>     answer.   Where is that in your example?  In the example, all we
>     see on the receiving side is that it calls createReceiveStream.
>
>     -Jim
>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     *On Behalf Of *Peter Thatcher
>     Yes, I was expecting you to be more supportive.  I'm surprised out
>     how your want "all or nothing".  I'm afraid if our options for a
>     clean API are all or nothing, we'll just end up with nothing.  I'd
>     prefer to try incremental improvements to word toward (eventually)
>     a clean API.
>
>     incremental approach?  If you think it's possible, I'd like to
>     hear your thoughts on how.
>
>     By the way, these API additions would greatly minimize the amount
>     of SDP editing necessary for JS clients that don't use SDP for
>     further.  Also, it's no longer necessary to do offer/answer for
>     adding tracks.  It's only the intial PeerConnection setup that
>     needs to do Offer/Answer.  So, it doesn't inherit all the problems
>     quite as much as you described.  It may be slightly abominable,
>     but I certainly consider it less abominable than the SDP editing
>     necessary without it.
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>     creating a
>     > [email-masked] <mailto:[email-masked]>

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 18 Jun 2013 11:21:31 +0200

> And do we really need SDP for that? mandatory?

I won't comment on whether SDP was the best option to begin with, but
the fact that every other person on this list has a demo WebRTC app
that, with little to no manipulation, achieves some kind of *basic*
interoperability with legacy SIP proves that it was in fact a somewhat
practical one.

A whole different story is whether we want to tie ourselves to the
complicacies of multiple SDP renegotiations for any non-obvious use case
that may or may not exist today in other that slideware form, but that
certainly still have to show any decent level of interoperability.

Enrico

---

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

> interoperability with legacy SIP proves that it was in fact a somewhat

Yes, that is basically a "PSTN call", no more. For sure, many people
have seen their mission accomplished with those demos ("we can enter
the PSTN from the web, we are done, WebRTC satisfy our needs !!!!").

> that may or may not exist today in other that slideware form,

I could not give my opinion better than what is told in these posts:

http://blog.webrtc.is/2013/03/06/sdp-the-webrtc-boat-anchor/
http://blog.webrtc.is/2013/06/17/sdp-inside-webrtc-is-bad-for-sip/

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

---

From: Enrico Marocco <[email-masked]>
Date: Tue, 18 Jun 2013 11:41:32 +0200

> the PSTN from the web, we are done, WebRTC satisfy our needs !!!!").

And even from the no-plan side of the fence that looks like a feature
rather than a bug.

Enrico

---

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

> And even from the no-plan side of the fence that looks like a feature

It's easy to build a spec based on "SIP interoperability" and then
make a "SIP intercommunication demo". Now the problem is that any
*future* custom signaling protocol on top of WebRTC must deal with O/A
and SDP limitations. WebRTC innovation subject to SIP model, forever.

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

---

From: Emil Ivov <[email-masked]>
Date: Tue, 18 Jun 2013 12:08:39 +0200

> and SDP limitations. WebRTC innovation subject to SIP model, forever.

This is exactly what No Plan tries to avoid. It gets you
interoperability for widely deployed legacy (as in SIP phones, popular
free SBCs and PSTN) and then it lets you do what you want for all the
fancy use cases that you are going to come up with. You are in no way
hampered by SDP this way.

Emil

--
https://jitsi.org

---

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

> hampered by SDP this way.

Hi Emil,

I understand your aim and really appreciate your effort (as I said
before, it is much better than fully depending on SDP for any media
operation). However let me expose the following questions, and I would
be very grateful if you answer inline:

* SIP over WebSocket JS app running in the browser (so SIP signaling
is used in the wire).

* I send the initial INVITE with the SDP I retrieve from the local PC
(I am the JS app).

* Later I want to put the remote peer on hold, so I need to send a
re-INVITE with same SDP but some differences:

- Increased SDP version number.
- a=inactive in every m= sections.

* How to do that? As far as I can imagine:

- I need to keep the initial SDP or retrieve it again from the PC, so
I get a string blob. I can "expect" how such a string blob looks, but
I cannot be sure since the same SDP can be represented in multiple
ways.

- So I need to *parse* the SDP at JS level, right? and then I need to
mangle it (for increasing version number and adding a=inactive),
right?.

- And then I must pause/stop my local streams (via PC API call),
generate the re-INVITE with the mangled SDP, and send it to the
remote, right?

- Then the remote peer receives it. Since it is also a SIP JS app, it
must *parse* the SDP at JS level and realize that there are a=inactive
lines in every m= sections, right? Then it could notify the human user
that "the remote has put the call on hold".

- Then, should the remote JS app pass the SDP to its PC? I expect not
(just wondering).

- And finally, the remote peer (its JS SIP app) should also mangle its
initial SDP for increasing the version number and adding a=inactive or
a=recvonly in every m= sections, right? and then send it into a SIP
200 OK.

So, unless I'm fully wrong, a simple use case (hold/unhold application
so widely extended in SIP) requires:

* SDP parsing at JS.
* SDP mangling at JS.

And such a parsing and mangling must be done over a string blob that
can have multiple representations (which depends on each WebRTC
implementation). Even worse, some non-browser-WebRTC-devices may add
a=inactive/sendonly before the m= sections (global SDP attribute), so
my JS app must be ready to detect it, right?

Does it really look nice? IMHO the mechanism you propose makes WebRTC
easy for very-very-very-ultra-basic use cases (basically an
audio/video call with no media changes) and makes it really complex
for implementing any kind of media modification or media application
(i.e. "hold" / "unhold").

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?

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

* Magically I (the server) create the new SDP with the SSRC/MSID of
the new stream associated to the new participant, and send it into a
re-INVITE to every participant.

* Now a participant receives it and must be able to know what has been
modified (in order to render it in the HTML, i.e. by drawing a new
<video> element). Your draft states that those media modifications
(track additions) don't require re-sending a SDP, but in a SIP context
this must be done with a new SDP, so:

- The JS SIP app needs to *parse* the SDP at JS level, which is a
complex task. It must realize of the new SSRC/MSID (but it should also
detect whether an existing participant has leave the conference).

- Then it draws the new <video> element for showing the video of the
new participant.

- And some WebRTC events would be automatically fired in the remote JS
app due to the Track modifications, which is detected by the WebRTC
stack due to the presence of new SSRC/MSID in the RTP, right?

- And then the remote JS app must create a new SDP (a modified/mangled
version of the SDP in the initial SIP 200 OK response) with these
changes:

  - New version value.
  - Probably new lines/attributes due to the new SSRC/MSID (not sure about it).
  - And all of this at JS level by mangling the string blob.

- And send it back to the conference server in a SIP 200 response.

Well, IMHO this is the most tedious and error prune mechanism I've
ever seen. How to make it simpler?:

- WebRTC PC should not return a SDP (nor expect a SDP string), but
just a JS object with the required attributes.

- The JS app then builds a SDP (if it needs it due to the signaling
protocol as in the examples above).

- In this way the JS app has full control over the SDP associated to
the session and can safely modify it.

- And in 99% of WebRTC use cases (where no SIP is involved) the JS app
does not need to deal with a string blob retrieved from the
PeerConnection.

So, why not let the SDP-game for JS libraries? In this way, a
telco/provider/vendor could offer a JS app that does the required
magic to interop with its media gateways rather than leaving that
responsibility to browsers.

Please take a look to this article which claims more or less the same:

Regards.

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

---

From: Max Jonas Werner <[email-masked]>
Date: Tue, 18 Jun 2013 15:13:56 +0200

Hej Silvia,

> (You will notice that I am really naive wrt SDP, sorry!)

Do you really want to create a second "terminology world"? For people
who don't know what SSRC means (because they don't know RTP) it may seem
reasonable but to those who already know RTP you'd have to explain
"yeah, rtpflowId is actually SSRC." So the term SSRC would have to be
included in the spec anyway.

I'm not sure if having different names for the same thing would lead to
less confusion.

Max

---

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

Actually - have quick demos interop with some SIP device doesn't prove 
using SDP is a practical decision. All that proves is that it's good 
enough to whip up a quick demo. That 80-20 rule definitely applies here 
(i.e. 80% is easy and 20% is really hard or impossible).

It would be just as easy to package all that information up into your 
own "SDP" via a wrapper without having to incorporate SDP into the 
browser. There are serious long term consequences to using SDP.

I don't really here a single person saying SDP is good. The argument 
pro-SDP seems to be:
1) Easier for the JS developer
2) Compatibility with existing SIP devices
3) Too late - we've all agreed to do something bad so let's continue to 
do it badly

To my response:
1) Yes, if all you desire is a quick hack demo, sure, it's easier. But 
it's not really any harder if we have objects that allow control over 
all the properties too. Besides, it wouldn't be long before anything 
that was more complicated would be quickly wrapped and that issue 
completely goes away even if it were complicated. Besides, what is 
really needed? A list of codecs and a list of ICE candidates for basic 
interop? Really - is that truly "hard" to get a basic demo working?
2) I call bull. If anything, it makes it even more incompatible, not 
less since now we have each browser introducing it's own SDP with it's 
own version with its own feature sets. With a lower level API, you could 
control exactly what the produces/expects for SDP that you generate from 
JavaScript and you'd have greater compatibility. But the way it is now, 
we are moving towards a "SBCs will fix it" model.
3) That seems like a rather poor argument to me. There is not a single 
company reliant on this technology for it's income stream yet many 
looking forward to its potential. But we can't innovate much because the 
bottle neck is this SDP offer/answer model. This seems very short 
sighted. People dump old technology when the cost of moving forward with 
it is greater than the sum of replacing it. SDP offer/answer's future 
costs will be massive but it's hard to see because nobody is paying for 
it --- yet. Worst, the longer this persists the harder it will be to 
change because now it won't be just that we "agreed" but it will be that 
we "agreed, and now there is so much reliant upon it". There won't be 
any "fixing it later" as it "works for us". Unless people are willing to 
deprecate it now, this beast will be upon the world for the next 
generation of communications.

The arguments against SDP are strong:
1) Do everything monolithic exchange format - it's not an elegant API 
where all the knobs can be tweaked/controlled.
2) Each change requires a round trip to the remote party with a response 
before the next change can happen.
3) Simultaneous changes cause a conflict - according to the standard 
(regardless if it causes a real world errors or not)
4) Compatibility issues between SDPs will require parsing/rewriting of 
the SDPs anyway (it already happens CONSTANTLY in the SIP world already 
via SBCs)
5) Requests to "change" things are not simple API or property changes 
but instead serialized (and to the point above, a round trips for the 
SDP to the remote party too)
6) Unneeded + legacy
7) Breaks, hinders other models that do NOT require offer answer. It's 
clear by Microsoft they don't use offer/answer in Skype and I can say we 
do not use offer/answer in Open Peer and it's so much 
simpler/flexible/better because of it
8) Brittle - Simple changes in the SDP can break devices that are 
reliant on exact formatting
9) Creates silos - if we don't have compatible SDP, we can't communicate 
unless we introduce some arbitrator to fix it
... and I could go on and I've ranted on the subject before on webrtc.is ...

I'm sure anyone could try to argue a point here or there but the overall 
picture is that it's just BAD and really BAD long term. I'm not 
political which is why I don't post much. Frankly, the decision to use 
SDP made me not get involved much. What's the point in layer a bunch 
more features/specifications upon a bad foundation?

Wrapping an API around SDP to hide it still means that SDP offer/answer 
is at it's core and does little to fix the original problems (as they 
say, lipstick on a pig). Most of the problems still exist even if it 
were put inside a nicer API. We will be writing out own "nicer" API that 
dissects the SDP and extracts out of it and generates new ones on the 
remote side regardless if the browser does it for us, but it doesn't 
negate the problems of SDP -- needing true control over the RTC/media 
engines -- especially without offer/answer. If SDP has to be parsed, 
mangled, serialized or sent over the wire from JavaScript to do anything 
beyond the basic calling then it's the wrong choice. Offer/answer round 
tripping is equally bad (if not even worse).

SDP is clearly the WRONG technical choice. It was wrong from the start 
but I think there was a great misunderstanding that it was required or 
SIP wouldn't be compatible with WebRTC. Since the strong majority at the 
table were SIP guys because they are the "established" industry it 
became the 'way to do it' despite how horrible it is for the future. So 
here we are today...

-Robin

> Enrico Marocco <mailto:[email-masked]>
> 18 June, 2013 5:21 AM
>
> Iñaki Baz Castillo <mailto:[email-masked]>
> 18 June, 2013 4:31 AM
> 2013/6/18 Peter Thatcher<[email-masked]>:
>
>> That means the
> 18 June, 2013 1:27 AM
> On Mon, Jun 17, 2013 at 2:56 PM, Martin Thomson 
>     On 17 June 2013 12:26, Peter Thatcher <[email-masked]
>     <mailto:[email-masked]>> wrote:
> I don't thing we have to have two different sets of actions.  If a JS 
> app chooses, it could use createLocalStream and createRemoteStream for 
> all of its streams, and only use SDP for setting up the transport. 
>  For example, I could choose to write JS that would setup one 
> transport with one call to 
> createOffer/setLocalDescription/setRemoteDescription (ignore trickle 
> ICE and ICE restarts for them moment) and bundle all media over it. 
>  That means the SDP is really just used as a way to tell the browser 
> what ice ufrag, ice pwd, and DTLS fingerprint to use.  It would look 
> something like this (forgive me if I got the SDP slightly wrong;  it's 
> easy to get wrong):
>
> v=0
> remote).  The first set of streams has the same actions as the 100th 
> set of streams, if the JS chooses.
>
> 10 lines of SDP just to setup a transport isn't quite such an 
> abomination, is it?
>
>
> transports.  2.  To define the streams.  And once upon a time, there 
> was going to be 3.  To define the data channels.  We were able to 
> prevent #3 and just have data channel be defined in terms of 
> createDataChannel, and not in terms of SDP.  That was good, was it 
> not?  What I'm proposing is that we do something similar for audio and 
> video streams (#2).  That way, all that you need to use SDP for would 
> be #1 (to setup the transports).  And someday, we might be able to 
> improve that as well (perhaps a future .createTransport method).
>
>
> You're not forced to do SDP, except for the transports.  For defining 
> the streams, you can avoid SDP altogether.  As a WebRTC JS app 
> developer, I know I would find working with this API much better than 
> working with SDP munging.
>
>
> dictionaries like MediaStreamTrackDescription?  I would find that 
> somewhat ironic.  Or are you suggesting there's a way I can simplify 
> all the "description bits".  If there's a specific way I can simply it 
> to make it better, I'd lover to hear it.
>
>
> And, thanks for your feedback.  I hope my response about not requiring 
> SDP for the first streams helps clarify.
>
>
>     --Martin
>
>

---

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

2013/6/18 Robin Raymond <[email-masked]>

> SDP is clearly the WRONG technical choice. It was wrong from the start but
> I think there was a great misunderstanding that it was required or SIP
> wouldn't be compatible with WebRTC. Since the strong majority at the table
> were SIP guys because they are the "established" industry it became the
> 'way to do it' despite how horrible it is for the future. So here we are
> today...

Dear WG Chairs,

With all due respect, IMHO there is enough material to reopen the "SDP or
not SDP" debate so I would like to request it to the WG.

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 exposed in
this thread, that are nicely summarized in this mail:

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

Really thanks a lot.

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

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Tue, 18 Jun 2013 15:43:12 +0000

It isn't SDP that's the problem. It is the offer/answer semantics.

Here's a real simple example of the problem: If I have a web browser that can do RTP A/V, I should be able to send a form post or XHR to ask my security camera to start streaming me RTP video to a specific address and port. The browser doesn't need to do ICE connectivity tests, because it is only going to receive video.

I should be able to use a few lines of JavaScript to initialize the UDP/RTP receive port and wire it to a video window, set up the codec mapping, and ask it for its local address and port so I can tell the camera where to send things. But that isn't how it works at all. Instead I need to run, in JavaScript, the entire offer/answer exchange from the security camera's point of view, extract the relevant information from the SDP blob, and then send it off. (Never mind that I also need to have DTLS-SRTP added to my camera, even though I'm sending unencrypted RTP from it all over the rest of my LAN to other receivers that aren't browsers)

Same thing if I have a two-way radio system that can talk RTP and ICE and which has its own proprietary way of setting up connections... again, need to write a whole SDP parser *and* state machine to run the "fake" offer/answer exchange.

Pain. In. The. Ass.

Matthew Kaufman

________________________________
From: [email-masked] [[email-masked]] on behalf of Iñaki Baz Castillo [[email-masked]]
Sent: Tuesday, June 18, 2013 7:48 AM
To: [email-masked]
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

2013/6/18 Robin Raymond <[email-masked]<mailto:[email-masked]>>
SDP is clearly the WRONG technical choice. It was wrong from the start but I think there was a great misunderstanding that it was required or SIP wouldn't be compatible with WebRTC. Since the strong majority at the table were SIP guys because they are the "established" industry it became the 'way to do it' despite how horrible it is for the future. So here we are today...

Dear WG Chairs,

With all due respect, IMHO there is enough material to reopen the "SDP or not SDP" debate so I would like to request it to the WG.

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 exposed in this thread, that are nicely summarized in this mail:

Really thanks a lot.

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 18 Jun 2013 16:24:27 +0000

Hi,

The fact that you may not need ICE, or DTLS-SRTP, for your use-case is not related to SDP O/A, is it? SDP O/A itself doesn't mandate you to do ICE or DTLS-SRTP :)

Regards,

Christer

Lähettäjä: [email-masked] [mailto:[email-masked]] Puolesta Matthew Kaufman (SKYPE)
Lähetetty: 18. kesäkuuta 2013 18:43
Vastaanottaja: Iñaki Baz Castillo; [email-masked]
Aihe: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

Pain. In. The. Ass.

Matthew Kaufman

________________________________
From: [email-masked]<mailto:[email-masked]> [[email-masked]] on behalf of Iñaki Baz Castillo [[email-masked]]
Sent: Tuesday, June 18, 2013 7:48 AM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)
2013/6/18 Robin Raymond <[email-masked]<mailto:[email-masked]>>
SDP is clearly the WRONG technical choice. It was wrong from the start but I think there was a great misunderstanding that it was required or SIP wouldn't be compatible with WebRTC. Since the strong majority at the table were SIP guys because they are the "established" industry it became the 'way to do it' despite how horrible it is for the future. So here we are today...

Dear WG Chairs,

Really thanks a lot.

---

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

Matthew, please keep this thread focused on what we have proposed.   We're
proposing a way to (optionally if the JS chooses)
send and receive streams in way that doesn't require O/A or SDP.  The JS
can choose to use O/A for adding streams, but our proposal would give JS
more control and flexibilty for adding streams.  But replacing the
mechanism for establishing a transport is not part of what we are
proposing.  And blowing up all of the WebRTC API is explicity not part of
our proposal.  If you want to discuss that, please start another thread.

On Tue, Jun 18, 2013 at 8:43 AM, Matthew Kaufman (SKYPE) <
[email-masked]> wrote:

>  Here's a real simple example of the problem: If I have a web browser
> that can do RTP A/V, I should be able to send a form post or XHR to ask my
> security camera to start streaming me RTP video to a specific address and
> port. The browser doesn't need to do ICE connectivity tests, because it is
> only going to receive video.
>
>  I should be able to use a few lines of JavaScript to initialize the
> UDP/RTP receive port and wire it to a video window, set up the codec
> mapping, and ask it for its local address and port so I can tell the camera
> where to send things. But that isn't how it works at all. Instead I need to
> run, in JavaScript, the entire offer/answer exchange from the security
> camera's point of view, extract the relevant information from the SDP blob,
> and then send it off. (Never mind that I also need to have DTLS-SRTP added
> to my camera, even though I'm sending unencrypted RTP from it all over the
> rest of my LAN to other receivers that aren't browsers)
>
>  Same thing if I have a two-way radio system that can talk RTP and ICE
> and which has its own proprietary way of setting up connections... again,
> need to write a whole SDP parser *and* state machine to run the "fake"
> offer/answer exchange.
>
>  Pain. In. The. Ass.
>
>  Matthew Kaufman
>
>  ------------------------------
> *From:* [email-masked] [[email-masked]] on behalf of
> Iñaki Baz Castillo [[email-masked]]
> *Sent:* Tuesday, June 18, 2013 7:48 AM
> *To:* [email-masked]
> sources without encoding them in SDP)
>
>> but I think there was a great misunderstanding that it was required or SIP
>  With all due respect, IMHO there is enough material to reopen the "SDP
> or not SDP" debate so I would like to request it to the WG.
>
>  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
> exposed in this thread, that are nicely summarized in this mail:
>

---

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

While I appreciate your desires to see a cleaner API (such that a JS app
can choose not to use SDP), but I'd really like to keep this thread focused
on the proposal made: the addition of two methods to PeerConnection that
greatly improve the situation for adding streams.

We are not proposing eliminating SDP altogether.  While such a proposal and
discussion may have merit, that's not what we are proposing, so please
start a separate thread to discuss it.

---

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

2013/6/18 Peter Thatcher <[email-masked]>:
> While I appreciate your desires to see a cleaner API (such that a JS app can
> choose not to use SDP), but I'd really like to keep this thread focused on
> the proposal made: the addition of two methods to PeerConnection that
> discussion may have merit, that's not what we are proposing, so please start
> a separate thread to discuss it.

Yes Peter, you are right, sorry for that. I've opened a new thread.

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

---

From: Silvia Pfeiffer <[email-masked]>
Date: Wed, 19 Jun 2013 12:35:53 +1000

On Tue, Jun 18, 2013 at 10:25 PM, Max Jonas Werner <[email-masked]> wrote:
> Hej Silvia,
>
> On 18.06.2013 08:25, Silvia Pfeiffer wrote:> On Tue, Jun 18, 2013 at
> 4:17 PM, Emil Ivov <[email-masked]> wrote:

You can leave mention of SSRC to a comment in the spec next to rtpflowId.

> I'm not sure if having different names for the same thing would lead to

If SSRC is the name it's given in SDP and we want to get away from
SDP, this would be a first step, wouldn't it?

Silvia.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Jun 2013 14:33:17 +0200

> SDP, this would be a first step, wouldn't it?

SSRC is the name it's given in RTP, and we have (so far) had consensus 
on using RTP.

---

From: Silvia Pfeiffer <[email-masked]>
Date: Wed, 19 Jun 2013 22:37:06 +1000

On Wed, Jun 19, 2013 at 10:33 PM, Harald Alvestrand
<[email-masked]> wrote:
>>>>> not
> SSRC is the name it's given in RTP, and we have (so far) had consensus on
> using RTP.

Ah ok, I thought it was a SDP parameter.
S.

---

From: Sergio Garcia Murillo <[email-masked]>
Date: Wed, 19 Jun 2013 15:13:27 +0200

To be fair, that use case should already had been resolved much more 
easily long time ago:

<video src="rtsp://yourcameraip">

Best regards
Sergio

El 18/06/2013 17:43, Matthew Kaufman (SKYPE) escribió:
> that can do RTP A/V, I should be able to send a form post or XHR to 
> ask my security camera to start streaming me RTP video to a specific 
> address and port. The browser doesn't need to do ICE connectivity 
> tests, because it is only going to receive video.
>
> mapping, and ask it for its local address and port so I can tell the 
> camera where to send things. But that isn't how it works at all. 
> Instead I need to run, in JavaScript, the entire offer/answer exchange 
> from the security camera's point of view, extract the relevant 
> information from the SDP blob, and then send it off. (Never mind that 
> I also need to have DTLS-SRTP added to my camera, even though I'm 
> sending unencrypted RTP from it all over the rest of my LAN to other 
> receivers that aren't browsers)
>
> and which has its own proprietary way of setting up connections... 
> again, need to write a whole SDP parser *and* state machine to run the 
> "fake" offer/answer exchange.
>
> Pain. In. The. Ass.
>
> Matthew Kaufman
>
> ------------------------------------------------------------------------
> 2013/6/18 Robin Raymond <[email-masked] <mailto:[email-masked]>>
>
>     SDP is clearly the WRONG technical choice. It was wrong from the
>     start but I think there was a great misunderstanding that it was
>     required or SIP wouldn't be compatible with WebRTC. Since the
>     strong majority at the table were SIP guys because they are the
>     "established" industry it became the 'way to do it' despite how
>     horrible it is for the future. So here we are today...
>
>
>
> Dear WG Chairs,
>
> 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 exposed in this thread, that are nicely summarized in this mail:
>
> <[email-masked] <mailto:[email-masked]>>
>
>

---

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

On Mon, Jun 17, 2013 at 8:27 PM, Silvia Pfeiffer
<[email-masked]>wrote:

>
>
> On Tue, Jun 18, 2013 at 12:54 PM, Robin Raymond <[email-masked]>wrote:
>
>>
What we'd like is the same power as before (setting all these parameters)
without parsing SDP and serializing SDP.  My proposal allows (optionally)
for just that for MediaStreams, but not for transports.

> Agreed, that's what I'm after, but not as a library, but rather as part of

I think the best the WebRTC API can do is make a clean API at the "right"
abstraction level and then let libraries build on that.  For example, a
Jingle library or a p2p mesh library or a multiway video library.  We can't
expect the API to be all things to all people, nor can we expect it to be
so high level that it precludes many useful use cases.

> this would be a good time to help out, IMHO.

I think we can split the discussion of APIs into two separate parts: media
streams and transports.  For media streams, I think what I propose allows
for JS apps to handle MediaStreams without SDP and without O/A, while
working well with what we already have working.  It's not just pretty JSON.
 It gives what I consider a clean API at approximately the "right" level of
abstraction for MediaSteams.

The other half of the equation is transports.  I have some ideas on how
that could be done in a clean API at the "right" abstraction, but I haven't
proposed anything yet specifically because I don't want to blow everything
up at once.  I'd like to try and accomplish this incrementally.

---

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

> become a really useful API.

I hope so as well.  Unfortunately, Microsoft's input seems to be "our way
or the highway" and the input of others seems to be "SDP ought to be enough
for anybody".  My thinking is that we can make incremental improvements
toward a cleaner API without being so extreme at either end.  And I hope I
can find others that think similarly.

> nothing unless you understand SDP.

Actually, it helps some JS developer a lot.  It happens to be very good for
the JS I am writing :).

> they stand for and when a JS developer would actually change them?
I did my best with the names.   I passionate about good names for things,
but we have certain constraints we have to work within.  ssrc is an RTP
name that cannot be avoided.  "id" of a track is the same as the
MediaStreamTrack.id, so it's already well defined in the rest of the API.
 TransportId is a little more hairy, since there is no clean API for
transports, so it has to refer to the SDP.  I could have called it
transportSdpMid to be more clear what it is, but I doubt you would have
liked that name :).  Are there any others that you don't like?

> offer/answer),

MediaFlowDescription isn't using SDP underneath.  There would be no SDP
between the JS and the browser if MediaFlowDescription were used.  And, it
isn't offer/answer either (unless you implement offer/answer on top it,
obviously.  It's the JS's choice of what to do).

> but that's not actually my main goal. What I'm after is

For signalling, what's in MediaStreamTrackDescription must be serialized,
sent to the receiving side, and deserialized.  That is a pretty fundamental
requirement, and short of deciding all RTP parameters a priori, there's no
way to do RTC without doing so.  So, you at least will need to know how to
accomplish that.  Of course, a library on to of the WebRTC API may provide
you that signaling so you don't have to.  But the WG has, correctly,
decided to leave the decision of the signalling to the JS and not back it
into the API.

---

From: Robin Raymond <[email-masked]>
Date: Wed, 19 Jun 2013 11:59:25 -0400

Then why not move to a lower level API and do it as a shim (i.e. reverse 
polyfill)?

If provided a lower level API that works without SDP where the 
individual network/media component wiring/attributes can be controlled, 
we could create the same WebRTC API that exists today for people who 
think "SDP out to be enough for anybody" layered on top of it; They lose 
absolutely nothing (in fact they gain a lot since now they can tweak the 
logic to be even more compatible with their networks and dynamically 
update it as needed instead of waiting for the next browser "patch" to 
be deployed everywhere on all platforms). The only different is that 
it's an JavaScript implementation rather than written in C++. They get 
what they want but we get what we need.

That's the difference, they *want* this API as it "works/good enough for 
them", whereas many of *need* a lower level API to do anything 
sophisticated at all. As it stands, it makes many use cases for us who 
whom don't want to do basic SIP/SDP signaling extremely challenging, 
complex, ugly, brittle, if not outright impossible. I've explained many 
times why using SDP with offer/answer is horribly bad idea (and I can 
re-share those links if needed).

-Robin

> 19 June, 2013 11:15 AM
> I hope so as well.  Unfortunately, Microsoft's input seems to be "our 
> way or the highway" and the input of others seems to be "SDP ought to 
> be enough for anybody".  My thinking is that we can make incremental 
> improvements toward a cleaner API without being so extreme at either 
> end.  And I hope I can find others that think similarly.
>
>

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 19 Jun 2013 18:03:22 +0200

On 06/19/2013 05:15 PM, Peter Thatcher wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi Peter, all,
>
> Actually, it helps some JS developer a lot.  It happens to be very 
> good for the JS I am writing :).
>

And it might be really obvioius and come across as really condescending, 
but there's absolutely no way anyone can write sensible code to control 
the parameters of transmission or encoding without understanding how 
that controlling affects the transmission or encoding.

Thus, as long as one uses RTP, one needs to understand concepts like 
payload types, SSRCs, RTP sessions, RTCP feedback and so on - OR accept 
that one programs to a higher level abstraction where these attributes 
are not visible, and accept that one does not have control over them.

In some cases, interfaces can be made with "options" - so that if one 
doesn't care, one gets a sensible default, and if one does care, one can 
get detailed control - but sometimes, one has to pick the level of an 
interface.

I'd like to think that we recognize that these tradeoffs have to be made.

---

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

>
> If provided a lower level API that works without SDP where the individual
> network/media component wiring/attributes can be controlled, we could
> create the same WebRTC API that exists today for people who think "SDP out
> to be enough for anybody" layered on top of it; They lose absolutely
> nothing (in fact they gain a lot since now they can tweak the logic to be
> even more compatible with their networks and dynamically update it as
> needed instead of waiting for the next browser "patch" to be deployed
> everywhere on all platforms). The only different is that it's an JavaScript
> implementation rather than written in C++. They get what they want but we
> get what we need.
>

There are two separate things here: 1.  adding to the current API to allow
JS to avoid SDP.  2.  removing what is there that uses SDP.

You're saying you want to add new things and remove olds things.  But I
think really you just want to add what you want, and it would matter if
what you didn't want to use were still there.  So I think it's better to
talk about what we can add to the API to make it easier to work with rather
than talk about starting from scratch.  Removing the existing pieces would
not be nearly as easy as you make it sound.

> sophisticated at all.

You don't need a lower level API.  SDP munging can get you what you need.
 But what you want is to not have to do SDP munging.

My proposal is to add two methods to PeerConnection that, if optionally
used by JS, will give you what you want for media streams: the ability to
control what is sent and received without SDP munging.  It does not,
however, relieve you from SDP munging on the transport side.  But as I've
pointed out, that's limited to about 10 lines of SDP, so at least it's much
less SDP munging.  Later, once could consider more simple additions that
reduce the need for SDP munging further.

> As it stands, it makes many use cases for us who whom don't want to do
> basic SIP/SDP signaling extremely challenging, complex, ugly, brittle, if
> not outright impossible. I've explained many times why using SDP with
> offer/answer is horribly bad idea (and I can re-share those links if
> needed).
>
>
I think your dislike of SDP is sufficiently clear.

> or the highway" and the input of others seems to be "SDP ought to be
> enough for anybody".  My thinking is that we can make incremental
> improvements toward a cleaner API without being so extreme at either end.
>  And I hope I can find others that think similarly.
>
>
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 19 Jun 2013 13:17:45 -0400

> not be nearly as easy as you make it sound.
Let me approach this from a different angle: Do you think it is possible to
create an interoperable, re-implementable API based on SDP? Currently, SDP
format changes with each release in a way that breaks both SDP mungling
code and external connected end-points. What I want is an API that does not
rely on a string blog to encapsulate every new feature. New features should
be implemented via new methods. I need something standard enough that I can
have a stable application implementation. As it stands right now WebRTC
will not pass the W3C standard process, so we need either spend a lot more
time tying down SDP or create the API that avoids it. I think you
 underestimate the amount of effort needed to finalize SDP. At the current
rate I see this  process taking another 2-3 years. It also creates a
dependency on MMUSIC, which has its own priorities. So, if you want a
realistic API standard, you need to look for a way around SDP.

Also, using SDP just for transport is wasteful. All you need are 3 string
parameters which can be passed individually without parsing/creating a
string blog which carries another 5 things that carry no meaning for
transport (version, origin, etc).
_____________
Roman Shpount

---

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

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

> You don't need a lower level API.  SDP munging can get you what you need.  But what you want is to not have to do SDP munging.
>
> My proposal is to add two methods to PeerConnection that, if optionally used by JS, will give you what you want for media streams: the ability to control what is sent and received without SDP munging.  It does not, however, relieve you from SDP munging on the transport side.  But as I've pointed out, that's limited to about 10 lines of SDP, so at least it's much less SDP munging.  Later, once could consider more simple additions that reduce the need for SDP munging further.

You base your proposal on the fact that SDP is here forever and must
be used in WebRTC, and then propose some new API methods along with
*lot* of SDP JS parsing/mangling/hackery to mitigate the API
limitations.

While it could be the best we have for now, IMHO it is still a hack or
workaround to just circumvent the real problem and the real
limitation.

Things can be done much better if we remove SDP from the equation.

Best regards.

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

---

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

2013/6/19 Roman Shpount <[email-masked]>:
> string blog

> which carries another 5 things that carry no meaning for

Identical ICE candidates for each m= line when the fact is that we use
a single transport, the "backward compatibility" c=line, etc etc

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 19 Jun 2013 10:46:55 -0700

On 19 June 2013 08:15, Peter Thatcher <[email-masked]> wrote:
> Unfortunately, Microsoft's input seems to be "our way or the highway"

The good thing about this forum is that correcting gross
misrepresentation is as easy as it is to propagate it.

Microsoft's input is that Offer/Answer is difficult to remove without
also removing a reliance on SDP at the same time.  CU-RTC-Web is a
demonstration of one solution to that problem that we believe is
workable.  That proposal was input, not ultimatum.  We'd be happy to
consider other alternatives, but we don't believe that any attempt
that retains both O/A and SDP to be a worthwhile step.

The proposals I've seen for incremental refinement don't successfully
avoid the SDPNG trap.  Most increase the API surface area, often
dramatically, which burdens both browser implementations and API
users.  I personally don't believe it to be possible to avoid this
problem without tackling the core problem, which unfortunately
requires a little bit of courage.

---

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

On Wed, Jun 19, 2013 at 10:17 AM, Roman Shpount <[email-masked]> wrote:

>> There are two separate things here: 1.  adding to the current API to
>> allow JS to avoid SDP.  2.  removing what is there that uses SDP.
>>
> Let me approach this from a different angle: Do you think it is possible
> to create an interoperable, re-implementable API based on SDP? Currently,
> SDP format changes with each release in a way that breaks both SDP mungling

I think an API that allows JS to not have to do SDP munging it much better.
 That's why I proposed a step in that direction.

> transport (version, origin, etc).

Agreed.  I'd rather not have it, but I'm trying to make incremental
improvements here.   I don't want to blow up everything and start from
scratch.

---

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

> improvements here.   I don't want to blow up everything and start from 

My position is that there are no incremental improvements possible 
without removing the O/A state machine from the browser.

The whole point of JavaScript and the ability to manipulate objects is 
so that programmers can make the browser do things. Offer/Answer 
perverts that so significantly as to prevent reasonable JavaScript 
programming practice.

Matthew Kaufman

---

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

> misrepresentation is as easy as it is to propagate it.

I'll happily be wrong about my representation of Mircosoft's standpoint,
but Matthew just said "My position is that there are no incremental
improvements possible without removing the O/A state machine from the
browser."  That's pretty hardline, with no room for compromise.

But to be fair, I retract my comment of "Microsoft's input seems to be 'our
way or the highway'" and would like to replace it with
 "Microsoft's input seems to be 'no incremental improvements without
removing O/A from the browser'".  How's that?

> that retains both O/A and SDP to be a worthwhile step.

I'm fine with the goal of avoiding SDP and O/A.  My proposal that started
this thread does just that for media streams (but not transports).

It's the "no incremental improvements" part that I have issue with.  I
believe we can do this with incremental improvements.

> requires a little bit of courage.

I disagree.  My proposal eliminates at least half of the pain by only
adding two methods to PeerConnection (and a few dictionaries).  That does
add some burden to the browser, but relieves a lot of burden from the API
users.

---

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

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

> > You don't need a lower level API.  SDP munging can get you what you
> need.  But what you want is to not have to do SDP munging.
> >

Not quite.  I base my proposal on the fact that you can currently do
everything via SDP mangling, and I propose a simple addition that would
allow getting rid of a lot of that SDP munging.    There is still some,
which could theoretically be addressed with more future additions, but at
least the munging is greatly reduced with my proposal.

I also assume that blowing up everything and started over without SDP in
the browser isn't going to fly with the WG.  I'd be happy to be proven
wrong, but I'm trying to be realistic.

> workaround to just circumvent the real problem and the real

There are two parts to the real problem: transports and streams.  My
proposal solves one of them and leaves the other for future improvement.  I
thing it's better than just a hack or circumvention.

> Things can be done much better if we remove SDP from the equation.

I won't disagree, but I don't think it's realistic with the WG to remove
SDP from the API.  I think the best we can get is to allow SDP to choose
wether to use SDP or not.  Choose your battles.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 20 Jun 2013 00:37:26 +0200

2013/6/19 Peter Thatcher <[email-masked]>:
> I won't disagree, but I don't think it's realistic with the WG to remove SDP
> from the API

That would sound ever better if there was a real SDP based proposal
rather than a debate about how to deal with SDP (which is what we have
after two years).

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

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jun 2013 17:19:41 -0700

I do think No Plan represents progress toward containing the SDP monster in WebRTC 1.0, particularly for video scenarios. However, I also agree with Robin's arguments against SDP and O/ A, particularly for a server-side API (e.g. Node.js modules) where the current API makes no sense at all. So my perspective is to contain the monster in 1.0, then go with 2.0 first on server, then on the browser. 

On Jun 17, 2013, at 10:34 PM, "Peter Thatcher" <[email-masked]> wrote:

> I like your comparison to the data channels.  As I just pointed out in another email, I think it was good that we "contained the SDP monster", as you put it, with createDataChannel.  One of the purposes of createLocalStream/createRemoteStream is to allow a JS app, if it chooses, to "contain the SDP monster" when adding media streams.  It would still be needed for setting up the PeerConnection's transport (a monster container for a future day perhaps), but that's still significant progress in my book, and it does so with simple additions to the PeerConnection that don't attempt to blow up the WG.
> 
> 
> On Mon, Jun 17, 2013 at 5:14 PM, Bernard Aboba <[email-masked]> wrote:
>>  
>>  
>> "An unmanageable monster was created which currently stays in the way of developing new functionality (bundle), building applications (does not provide obvious ways to implement obvious tasks, like adding an extra stream without re-negotiating all the existing ones) and even interop with existing SIP endpoints (which was the original but now is complicated since it would require a non trivial set of constraints and subsequent SDP manipulation)."
>>  
>> [BA] Hard to argue with this, but I would point out that by far the ugliest part of the monster is the video hindquarters.  While one could argue that we have been living with the warts of SDP for audio and therefore know the workarounds, with video there are substantial interoperability issues, *even among vendors who utilize the same codec*, sometimes even in relatively basic scenarios (e.g. P2P video call with H.264/SVC).  So the "multivendor legacy of interop" just doesn't exist yet (at least, based on standards).
>>  
>> So as I see it, it does represent progress that we have contained the SDP monster's impact on the  the data channel, and I welcome Peter's effort to enable applications who don't care about SDP to minimize its usage even if it is not eliminated entirely.   
>>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jun 2013 17:29:12 -0700

On Jun 19, 2013, at 8:16 AM, "Peter Thatcher" <[email-masked]> wrote:

[BA] this isn't about Microsoft any more (if it ever was). This is about enabling developers, and not just on the browser. For example, WebRTC needs a story on the server and that surely isn't JSEP.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 26 Jun 2013 21:14:06 -0700

Robin said: 

"If provided a lower level API that works without SDP where the 
individual network/media component wiring/attributes can be controlled, 
we could create the same WebRTC API that exists today'
[BA] I wouldn't require a shim to provide "the same WebRTC API that exists today" because that API is very underspecified, so that it is not possible to produce a set of conformance tests for it without reverse engineering.  And of course, that reverse engineered specification would only remain valid until the next set of SDP hacks invalidated it. 
So while the shim might provide a "similar high level WebRTC API", holding WebRTC API 2.0 to a "bug for bug" compatibility standard is neither feasible nor desirable.   The goal of WebRTC API 2.0 should be to deprecate 1.0, not to increase the WebRTC API implementation barriers even further.

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 26 Jun 2013 22:01:33 -0700

If Node.js wants a cleaner API, it's can certainly create one.  It's not at
all constrained by what goes in the browser or what the WGs decide.  In
fact, that would be an interesting way to explore a cleaner API to see how
well it works.

On Wed, Jun 26, 2013 at 5:19 PM, Bernard Aboba <[email-masked]>wrote:

> I do think No Plan represents progress toward containing the SDP monster
> in WebRTC 1.0, particularly for video scenarios. However, I also agree with
> Robin's arguments against SDP and O/ A, particularly for a server-side API
> (e.g. Node.js modules) where the current API makes no sense at all. So my
> perspective is to contain the monster in 1.0, then go with 2.0 first on
> server, then on the browser.
>

---

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

FYI, after some further discussion with Martin and Matthew from Microsoft,
I came to a better understanding of their position.  I don't represent
them, but I understand it better to be "No SDP and no O/A in the API".   So
I was being a big too negative with my "highway" comment.  I apologize,
again, to my friends at Microsoft.

Also, I agree entirely that the goal should be to make the best API
possible, and that includes enabling developers.  But the server isn't at
all constrained by JSEP.  You can take the code from webrtc.org and build
use the lower-level pieces and ignore SDP and O/A altogether.  There's
nothing stopping you.  In fact, I'd be delighted if someone did just that
and made an open source WebRTC server implementation.  WebRTC (and
libjingle, as subset) are open source and patches are welcome :).

On Wed, Jun 26, 2013 at 5:29 PM, Bernard Aboba <[email-masked]>wrote:

> [BA] this isn't about Microsoft any more (if it ever was). This is about
> enabling developers, and not just on the browser. For example, WebRTC needs
> a story on the server and that surely isn't JSEP.

---

From: Robin Raymond <[email-masked]>
Date: Thu, 27 Jun 2013 01:09:45 -0400

You are absolutely correct, that it is an unobtainable goal to produce a 
shim 1-for-1 compatible without reverse engineering.

In the draft:
http://tools.ietf.org/id/draft-raymond-rtcweb-webrtc-js-obj-api-rationale-00.txt

We declare in section 5.4.8 "SIP/SDP and current WebRTC API shim 
compatibility statement" that it would not be the goal of this shim to 
do that. I think we have to work towards producing a shim that follows 
the spirit of the current WebRTC API rather than emulating the exact 
letter of every feature (and bug), especially since the feature 
definitions are vague. As any JS shim could be forked and modified, if a 
particular "feature/bug" needed to be emulated by someone it could be 
done by the developer needing the specialized behavior. Every JavaScript 
developer will have full control over the shim's code or which shim(s) 
to use.

-Robin

> Bernard Aboba <mailto:[email-masked]>
> 27 June, 2013 12:14 AM
> Robin said:
>
> individual network/media component wiring/attributes can be 
> controlled, we could create the same WebRTC API that exists today'
>
> [BA] I wouldn't require a shim to provide "the same WebRTC API that 
> exists today" because that API is very underspecified, so that it is 
> not possible to produce a set of conformance tests for it without 
> reverse engineering.  And of course, that reverse engineered 
> specification would only remain valid until the next set of SDP hacks 
> invalidated it.
>
> So while the shim might provide a "similar high level WebRTC API", 
> holding WebRTC API 2.0 to a "bug for bug" compatibility standard is 
> neither feasible nor desirable.   The goal of WebRTC API 2.0 should be 
> to deprecate 1.0, not to increase the WebRTC API implementation 
> barriers even further.

---

From: Robin Raymond <[email-masked]>
Date: Thu, 27 Jun 2013 01:16:56 -0400

True, node.js doesn't have to use the same code in their implementation 
and they are free to deviate from the WebRTC path. But it would be 
highly desirable if they could use the same API as it would ensure a 
greater level of compatibility between client and servers where common 
JS libraries can be used. Plus node JS can be used to produce not just 
server apps but HTML5 based applications, so having a compatible library 
for those kind of applications is valuable too.

-Robin

> 27 June, 2013 1:01 AM
> If Node.js wants a cleaner API, it's can certainly create one.  It's 
> not at all constrained by what goes in the browser or what the WGs 
> decide.  In fact, that would be an interesting way to explore a 
> cleaner API to see how well it works.
>
>
>
> 26 June, 2013 8:19 PM
> I do think No Plan represents progress toward containing the SDP 
> monster in WebRTC 1.0, particularly for video scenarios. However, I 
> also agree with Robin's arguments against SDP and O/ A, particularly 
> for a server-side API (e.g. Node.js modules) where the current API 
> makes no sense at all. So my perspective is to contain the monster in 
> 1.0, then go with 2.0 first on server, then on the browser.
>
> On Jun 17, 2013, at 10:34 PM, "Peter Thatcher" <[email-masked]

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 26 Jun 2013 22:21:57 -0700

On Wed, Jun 26, 2013 at 9:14 PM, Bernard Aboba <[email-masked]>wrote:

> Robin said:
>
> "If provided a lower level API that works without SDP where the individual
> create the same WebRTC API that exists today'
>
> [BA] I wouldn't require a shim to provide "the same WebRTC API that exists
> today" because that API is very underspecified, so that it is not possible
> to produce a set of conformance tests for it without reverse engineering.
>  And of course, that reverse engineered specification would only remain
> valid until the next set of SDP hacks invalidated it.
>

Once thing you *could* do (I'm not saying this is a good idea) is take an
open source browser (let's pick Chrome) implement a "WebRTC 2.0" API, and
then build the WebRTC 1.0 on top of it.  You could then port the WebRTC 1.0
SDP code (for reference, it's here:
https://code.google.com/p/libjingle/source/browse/trunk/talk/app/webrtc/webrtcsdp.cc)
on to the WebRTC 2.0 API.  At that point, you would have an "1.0 on 2.0"
API that is the same as the "original 1.0" API, or at least as close as
could possibly be done.  And at the same time, you'd have the 2.0 available
to JS to use.

Repeat that process for all (2) browsers that have implemented the WebRTC
1.0 API.  What could go wrong :)?

>
> So while the shim might provide a "similar high level WebRTC API", holding
> WebRTC API 2.0 to a "bug for bug" compatibility standard is neither
> feasible nor desirable.   The goal of WebRTC API 2.0 should be to deprecate
> 1.0, not to increase the WebRTC API implementation barriers even further.
>
>
>

---

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

Sorry.  I meant to say " implement a "WebRTC 2.0" API, and then build the
WebRTC 1.0 on top of it by porting" rather than "implement a "WebRTC 2.0"
API, and then build the WebRTC 1.0 on top of it.  You could then port".

On Wed, Jun 26, 2013 at 10:21 PM, Peter Thatcher <[email-masked]>wrote:

>> individual network/media component wiring/attributes can be controlled, we
>> could create the same WebRTC API that exists today'
>>
>> exists today" because that API is very underspecified, so that it is not
>> possible to produce a set of conformance tests for it without reverse
>> engineering.  And of course, that reverse engineered specification would
>> only remain valid until the next set of SDP hacks invalidated it.
>>
>
>> holding WebRTC API 2.0 to a "bug for bug" compatibility standard is neither

---

From: Peter Thatcher <[email-masked]>
Date: Wed, 26 Jun 2013 22:25:27 -0700

That's a good point about porting code from browser to node.js.  I hadn't
thought of that.

More great feedback from the JS developers!

On Wed, Jun 26, 2013 at 10:16 PM, Robin Raymond <[email-masked]> wrote:

> and they are free to deviate from the WebRTC path. But it would be highly
> desirable if they could use the same API as it would ensure a greater level
> of compatibility between client and servers where common JS libraries can
> be used. Plus node JS can be used to produce not just server apps but HTML5
> based applications, so having a compatible library for those kind of
> applications is valuable too.
>
> -Robin
>
> If Node.js wants a cleaner API, it's can certainly create one.  It's not
> at all constrained by what goes in the browser or what the WGs decide.  In
>   Bernard Aboba <[email-masked]>
>  26 June, 2013 8:19 PM

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 27 Jun 2013 05:26:37 +0000

If the current API course is followed, it is mandatory that it be possible to produce a 1-for-1 compatible shim without reference to anything but the W3C documentation and its normative references. Otherwise it cannot be a W3C specification.

Matthew Kaufman

From: [email-masked] [mailto:[email-masked]] On Behalf Of Robin Raymond
Sent: Wednesday, June 26, 2013 10:10 PM
To: Bernard Aboba
Cc: [email-masked]
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple sources without encoding them in SDP)

You are absolutely correct, that it is an unobtainable goal to produce a shim 1-for-1 compatible without reverse engineering.

In the draft:

We declare in section 5.4.8 "SIP/SDP and current WebRTC API shim compatibility statement" that it would not be the goal of this shim to do that. I think we have to work towards producing a shim that follows the spirit of the current WebRTC API rather than emulating the exact letter of every feature (and bug), especially since the feature definitions are vague. As any JS shim could be forked and modified, if a particular "feature/bug" needed to be emulated by someone it could be done by the developer needing the specialized behavior. Every JavaScript developer will have full control over the shim's code or which shim(s) to use.

-Robin

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Fri, 28 Jun 2013 22:28:57 +0000

On Jun 17, 2013, at 6:00 PM, Silvia Pfeiffer <[email-masked]> wrote:

> Having hit my
> feeling the pain.

Could you let us know the use cases of what it is you need an easy way to do ?

---

From: Peter Thatcher <[email-masked]>
Date: Fri, 28 Jun 2013 16:30:18 -0700

FYI, you might find some in this doc:

https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=0

About nine developers have listed what they are trying to do and what pain
they are running into, with SDP specifically.  Granted, it's only what can
fit in a single spreadsheet cell, but I'm sure you can ask for further
details if you are interested.  But at least one did mention how well SDP
is working for them, so there's input on both sides.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sat, 29 Jun 2013 08:23:21 +0200

Cullen, do you think that W3C would ever design a JS API that forces the
developer to deal with an unmanageable blob string? Can somebody point me
to an existing similar "API" in HTML5?

The problem is that telcos are much more used to IETF processes than Web
people and hence this WG is dominated by telcos proposing their first API
for the W3C, an API to satisfy their existing business model (the webphone).

It is time to leave Web experts to design a really useful API for WebRTC.

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

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 29 Jun 2013 06:24:42 -0700

> to an existing similar "API" in HTML5?
Well, the original WHATWG specification had more or less the same structure
of
having the PeerConnection emit an opaque SDP blob. I.e., this is a design
that originally comes from Ian Hickson.

-Ekr

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 29 Jun 2013 21:10:37 +0000

On Jun 28, 2013, at 11:23 PM, Iñaki Baz Castillo <[email-masked]>
 wrote:

> Cullen, do you think that W3C would ever design a JS API that forces the developer to deal with an unmanageable blob string? Can somebody point me to an existing similar "API" in HTML5?

Uh, the video tag seems pretty popular...

---

From: Robin Raymond <[email-masked]>
Date: Sat, 29 Jun 2013 23:28:22 -0400

You mean this HTML 5 video tag, right? This one:

<video  poster="movie.jpg"  controls>
         <source  src="movie.webm"  type='video/webm; codecs="vp8.0, vorbis"'/>
         <source  src="movie.ogg"  type='video/ogg; codecs="theora, vorbis"'/>
         <source  src="movie.mp4"  type='video/mp4; codecs="avc1.4D401E, mp4a.40.2"'/>
         <p>This is fallback content</p>
</video>

Versus this SDP blob that many of us must parse/mangle/generate from our 
code if we want to go beyond a basic demo:

v=0
o=- 3572342242 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio data
a=msid-semantic: WMS
m=audio 54680 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126
c=IN IP4 97.213.43.112
a=rtcp:54680 IN IP4 97.213.43.112
a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host 
generation 0
a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host 
generation 0
a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host 
generation 0
a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host 
generation 0
a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx 
raddr 192.168.17.159 rport 54680 generation 0
a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx 
raddr 192.168.17.159 rport 54680 generation 0
a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx 
raddr 192.168.17.214 rport 57626 generation 0
a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx 
raddr 192.168.17.214 rport 57626 generation 0
a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host 
generation 0
a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host 
generation 0
a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host 
generation 0
a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host 
generation 0
a=ice-ufrag:zFLN0q7y22aeZBhg
a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS
a=ice-options:google-ice
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=application 54680 RTP/SAVPF 101
c=IN IP4 97.213.43.112
a=rtcp:54680 IN IP4 97.213.43.112
a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host 
generation 0
a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host 
generation 0
a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host 
generation 0
a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host 
generation 0
a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx 
raddr 192.168.17.159 rport 54680 generation 0
a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx 
raddr 192.168.17.159 rport 54680 generation 0
a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx 
raddr 192.168.17.214 rport 57626 generation 0
a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx 
raddr 192.168.17.214 rport 57626 generation 0
a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host 
generation 0
a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host 
generation 0
a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host 
generation 0
a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host 
generation 0
a=ice-ufrag:zFLN0q7y22aeZBhg
a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS
a=ice-options:google-ice
a=sendrecv
a=mid:data
b=AS:30
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80 
inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID
a=rtpmap:101 google-data/90000
a=ssrc:2838167882 cname:X00v2LuQqKzLnkBs
a=ssrc:2838167882 msid:messaging messaging
a=ssrc:2838167882 mslabel:messaging
a=ssrc:2838167882 label:messaging

Please clarify if I misunderstand you.

-Robin

> Cullen Jennings (fluffy) <mailto:[email-masked]>
> 29 June, 2013 5:10 PM
> 29 June, 2013 2:23 AM
> Cullen, do you think that W3C would ever design a JS API that forces 
> the developer to deal with an unmanageable blob string? Can somebody 
> point me to an existing similar "API" in HTML5?
>
> The problem is that telcos are much more used to IETF processes than 
> Web people and hence this WG is dominated by telcos proposing their 
> first API for the W3C, an API to satisfy their existing business model 
> (the webphone).
>

---

From: Stefan Håkansson LK <[email-masked]>
Date: Sun, 30 Jun 2013 05:23:45 +0000

> https://docs.google.com/spreadsheet/ccc?key=0AuaKXw3SkHMSdHlZdV9RN0xSWFhybVl4anJLRkVPV0E#gid=0

I think it would be very helpful if people could provide some more 
detailed info about what modifications to the SDP they have been trying 
to do and why.

That would give some guidance for what API functions that should be 
provided.

>
> About nine developers have listed what they are trying to do and what
> pain they are running into, with SDP specifically.  Granted, it's only
> what can fit in a single spreadsheet cell, but I'm sure you can ask for
> further details if you are interested.  But at least one did mention how
> well SDP is working for them, so there's input on both sides.
>
>
>
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>     On Jun 17, 2013, at 6:00 PM, Silvia Pfeiffer

---

From: "Roy, Radhika R CIV USARMY (US)" <[email-masked]>
Date: Sun, 30 Jun 2013 13:41:54 +0000

Classification: UNCLASSIFIED
Caveats: NONE

Is it not the comparison of multi-dimensional intelligence (XML-script) vs.
one-dimensional intelligence (Binary) in expressing the description of a
"multimedia session?"

If it so, why are we waiting for as we know in the very beginning of the
technical debate between H.323 (H.245) and SIP (SDP) where H.245 can
negotiate and evolve a call between the two parties where media bridging is
not needed to a multi-party call that includes the media bridging
automatically (while SDP cannot do so dynamically - that has been another
important limitations of SDP)?

Best regards,
Radhika

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Robin Raymond
Sent: Saturday, June 29, 2013 11:28 PM
To: Cullen Jennings (fluffy)
Cc: <[email-masked]>
Subject: Re: [rtcweb] Proposal for a JS API for NoPlan (adding multiple
sources without encoding them in SDP)

        <source src="movie.mp4" type='video/mp4; codecs="avc1.4D401E,
mp4a.40.2"'/>

v=0
o=- 3572342242 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio data
a=msid-semantic: WMS
m=audio 54680 RTP/SAVPF 111 103 104 0 8 107 106 105 13 126 c=IN IP4
97.213.43.112
a=rtcp:54680 IN IP4 97.213.43.112
a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host
generation 0
a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host
generation 0
a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host
generation 0
a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host
generation 0
a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx raddr
192.168.17.159 rport 54680 generation 0
a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx raddr
192.168.17.159 rport 54680 generation 0
a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx raddr
192.168.17.214 rport 57626 generation 0
a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx raddr
192.168.17.214 rport 57626 generation 0
a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host
generation 0
a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host
generation 0
a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host
generation 0
a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host
generation 0 a=ice-ufrag:zFLN0q7y22aeZBhg a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS
a=ice-options:google-ice
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=recvonly
a=mid:audio
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:107 CN/48000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:126 telephone-event/8000
a=maxptime:60
m=application 54680 RTP/SAVPF 101
c=IN IP4 97.213.43.112
a=rtcp:54680 IN IP4 97.213.43.112
a=candidate:4099047770 1 udp 2113937151 192.168.17.159 54680 typ host
generation 0
a=candidate:4099047770 2 udp 2113937151 192.168.17.159 54680 typ host
generation 0
a=candidate:1965854185 1 udp 2113937151 192.168.17.214 57626 typ host
generation 0
a=candidate:1965854185 2 udp 2113937151 192.168.17.214 57626 typ host
generation 0
a=candidate:954187465 1 udp 1845501695 97.213.43.112 54680 typ srflx raddr
192.168.17.159 rport 54680 generation 0
a=candidate:954187465 2 udp 1845501695 97.213.43.112 54680 typ srflx raddr
192.168.17.159 rport 54680 generation 0
a=candidate:3114381946 1 udp 1845501695 97.213.43.112 57626 typ srflx raddr
192.168.17.214 rport 57626 generation 0
a=candidate:3114381946 2 udp 1845501695 97.213.43.112 57626 typ srflx raddr
192.168.17.214 rport 57626 generation 0
a=candidate:3134291370 1 tcp 1509957375 192.168.17.159 49802 typ host
generation 0
a=candidate:3134291370 2 tcp 1509957375 192.168.17.159 49802 typ host
generation 0
a=candidate:1001353497 1 tcp 1509957375 192.168.17.214 49803 typ host
generation 0
a=candidate:1001353497 2 tcp 1509957375 192.168.17.214 49803 typ host
generation 0 a=ice-ufrag:zFLN0q7y22aeZBhg a=ice-pwd:KGoEmNSd9a5eRgSa9Whh7qaS
a=ice-options:google-ice
a=sendrecv
a=mid:data
b=AS:30
a=rtcp-mux
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:9aibUYmy/+AhPzg3nsbrKO7YFLBs0ekn0h8hTFID
a=rtpmap:101 google-data/90000
a=ssrc:2838167882 cname:X00v2LuQqKzLnkBs
a=ssrc:2838167882 msid:messaging messaging
a=ssrc:2838167882 mslabel:messaging
a=ssrc:2838167882 label:messaging

-Robin

<mailto:[email-masked]> 

	Cullen, do you think that W3C would ever design a JS API that forces
the developer to deal with an unmanageable blob string? Can somebody point
me to an existing similar "API" in HTML5?

	The problem is that telcos are much more used to IETF processes than
Web people and hence this WG is dominated by telcos proposing their first
API for the W3C, an API to satisfy their existing business model (the
webphone).

	It is time to leave Web experts to design a really useful API for
WebRTC.

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

Classification: UNCLASSIFIED
Caveats: NONE