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

[Robin Raymond <[e-mail]>]

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

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

-Robin


> Matthew Kaufman <mailto:[e-mail]>
> 19 June, 2013 2:18 PM
> On 6/19/2013 11:05 AM, Robin Raymond wrote:
> That's a great question. Have you read the CU-RTCWEB proposal? Is it 
> any closer to what you imagined the RTCWEB API might be?
>
> Matthew Kaufman
> Robin Raymond <mailto:[e-mail]>
> 19 June, 2013 2:05 PM
>
> Why aren't we using the JavaScript object model for control of 
> components instead of serializing our control requests via 
> SDP/whatever format and hoping that it worked?
>
> -Robin
>
>
> Peter Thatcher <mailto:[e-mail]>
> 19 June, 2013 12:49 PM
> I asked "is there something that can't be done without sufficient SDP 
> munging"?  You answered "I have something that can be done with 
> sufficient SDP munging".   OK.  But do you have something that *can't* 
> be done with SDP munging?
>
> If there's nothing that can't be done with SDP munging, then this 
> whole thread boils down to "give us an API that has the same amount of 
> control as the current one, but without requiring SDP munging to do 
> advanced things".  And if that's is what is desired, then at least it 
> can be clear and concise.
>
>
>
>
>
> Matthew Kaufman <mailto:[e-mail]>
> 19 June, 2013 12:36 PM
> I provided a use case that, unless one wants to write a bunch of 
> SDP-munging JS state machine cannot be done.
>
> The problem is that such use cases are either 1) ignored or 2) 
> dismissed because of course if one writes said JS, they are possible 
> with the current API
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 19, 2013, at 9:28 AM, Peter Thatcher <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> I might be wrong, but I tried reading and understanding your whole 
>> email, and it seems to come down to "I don't want to use SDP or a 
>> different (JSON) form of SDP".  That's a fine thing to request, but 
>> why don't you just say that?  It would save everyone a lot of reading 
>> and confusion to be more concise.
>>
>> Or, if you have specific things you'd like to do but can't, what are 
>> they?  I think that would help me, and others, understand more 
>> easily.  Use cases would be helpful.
>>
>> On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>>
>>     The trouble is not that we can choose to send whatever we want
>>     over the wire. I know we can. If the WebRTC API is left with SDP
>>     as it stands, I'll dissect the SDP from the browser, reinterpret
>>     and reconstruct on the SDP on the remote side. That is NOT the issue.
>>
>>     The summary of what I want/believe:
>>     1) I want as close to raw access to RTP/ICE streams, media,
>>     sources, outputs, codecs as viable. Obviously doing the actual
>>     transmission, encoding/decoding from JS is not feasible (yet),
>>     nor is secure [ICE must occur for mutual agreement to exchange
>>     data between peers], but having controls for how these components
>>     are wired together is extremely feasible from JS and would allow
>>     immensely powerful apps to be produced from JS.
>>
>>
>> What would you like to do that you can't do via SDP right now?  You 
>> said this isn't just about working through SDP.  But I don't see 
>> anything concrete you can't do right now with sufficient SDP 
>> parsing/building/munging/hackery.
>>
>>     2) I don't want my primary interface to control media/RTP engines
>>     to be via obtaining or providing SDPs to the browser (or any
>>     alternative serialized format); especially given that SDP
>>     requires a round trip offer/answer to the remote party to affect
>>     change (e.g. it's entirely possible to do that stateless and
>>     one-sided). The SPD interface API is a monolithic do-everything
>>     serialized format to control an engine but extremely
>>     badly/poorly/short sighted (regardless if it is SDP or whatever
>>     instead), and it's wholly unneeded.
>>
>>
>> Short summary: "I don't want to use SDP".  Right?
>>
>>     3) I don't want a replacement for SDP with another more "pretty"
>>     format like JSON.
>>
>>
>> Short summary: "I don't want to use SDP or a different syntax for 
>> SDP".  Right?
>>
>>     4) I want no specified requirement from the browser to have any
>>     particular form of media negotiation API requirement what-so-ever
>>     (regardless if I can opt to substitute with my own format on the
>>     wire or not)
>>
>>
>> Short summary: "I don't want to use SDP or a different syntax for 
>> SDP".  Right?
>>
>>     5) Using SDP with offer/answer build into the browser binary is a
>>     horribly BAD technical choice (even for SIP folks) and must be
>>     stopped, see:
>>     http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html
>>
>>
>> Short summary: "I don't want to use SDP".  Right?
>>
>>
>>
>>     I too want to understand the rational for keeping something as
>>     bad as SDP with offer/answer as the primary mechanism for
>>     controlling the media components and interaction to those
>>     component and more importantly, I'd too would like to open debate
>>     to agreeing or not to provide a lower layer API rather than a
>>     media negotiation API as a complete substitute alternative to SDP
>>     with offer/answer.
>>
>>     If we can agree that it's far superior to have a lower level
>>     media/RTC component API rather than a media negotiation API, then
>>     we can propose what that API could look like (and there are
>>     people who have already have starting proposals). I'd throw my
>>     hat in the ring to propose such and API if necessary as I've
>>     written such engines from scratch before. But I don't want to
>>     waste time proposing ore reviewing such an API which will be
>>     summarily dismissed because people are so stuck on requiring a
>>     media negotiation API built into the browser binary, and
>>     specifically SDP with offer/answer in this case.
>>
>>
>>
>> The WG may dislike and reject your proposal, but there's a bit of 
>> truth to the old mathematically incorrect sports adage "you miss 100% 
>> of the shots you don't take".
>>
>>
>>     Anyone who argues that they need/want that simple SDP media
>>     negotiation API must understand that a lower level API would
>>     allow a wrapper API to produce the same WebRTC API the have today
>>     but be built entirely from JavaScript
>>
>>
>> That depends on how low-level you go.  If you go too low-level, it 
>> becomes infeasible to do things correctly and performantly in JavaScript.
>>
>>     upon a lower level API. Thus they can have their "just add-milk"
>>     baking API. But those of us who need control of the raw
>>     ingredients beyond the "just add milk" can still innovate.
>>
>>     -Robin
>>
>>
>>>     <compose-unknown-contact.jpg>
>>>     Peter Thatcher <mailto:[e-mail]>
>>>     19 June, 2013 2:49 AM
>>>     Correct my if I'm wrong, but the API already leaves what goes
>>>     over the wire completely up to the JS app.  So we couldn't
>>>     re-open a debate of "SDP or not SDP" for the wire format,
>>>     because there's nothing to debate.  We already decided it would
>>>     be left to the JS to decide.  The only thing left to debate is
>>>     the API.
>>>
>>>     Or am I wrong?
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     rtcweb mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>>     <compose-unknown-contact.jpg>
>>>     Christer Holmberg <mailto:[e-mail]>
>>>     19 June, 2013 2:34 AM
>>>     Hi,
>>>     We need to be very clear what we talk about, or some people are
>>>     always going to be confused :)
>>>     So, AFAIK, the discussion is about SDP O/A usage in the API,
>>>     only in the API, and nowhere but the API.
>>>     Whatever people us on the wire is outside the scope.
>>>     Right?
>>>     Regards,
>>>     Christer
>>>
>>>
>>>     Sent from */Windows/* using *TouchDown* (www.nitrodesk.com
>>>     <http://www.nitrodesk.com>)
>>>
>>>     -----Original Message-----
>>>     *From:* Peter Thatcher [[e-mail]
>>>     <mailto:[e-mail]>]
>>>     *To:* Martin Thomson [[e-mail]
>>>     <mailto:[e-mail]>]
>>>     *CC:* [e-mail] <mailto:[e-mail]> [[e-mail]
>>>     <mailto:[e-mail]>]
>>>     *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be
>>>     re-opened
>>>     Martin, you're right; that was overly harsh of me.  Adam, I
>>>     apologize.  I'll be civil in the future.
>>>
>>>
>>>
>>>     _______________________________________________
>>>     rtcweb mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>>     <compose-unknown-contact.jpg>
>>>     Peter Thatcher <mailto:[e-mail]>
>>>     19 June, 2013 1:36 AM
>>>     Martin, you're right; that was overly harsh of me.  Adam, I
>>>     apologize.  I'll be civil in the future.
>>>
>>>
>>>
>>>     _______________________________________________
>>>     rtcweb mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>>     <compose-unknown-contact.jpg>
>>>     Martin Thomson <mailto:[e-mail]>
>>>     18 June, 2013 6:25 PM
>>>     I agree with Peter, except for this bit:
>>>
>>>     Adam is much harder to confuse than you think, or than he professes.
>>>
>>>     Speaking of burning it all down and starting over. If you want a
>>>     house-related analogy, that's not quite correct. It's refusing to
>>>     build an extension because the old house, while legally fit for
>>>     habitation, is falling down around your ears. Since you only need
>>>     foundations, it's not that big a job (though I'll grant you that
>>>     it's
>>>     bigger than many people realize, even with that smaller scope).
>>>     _______________________________________________
>>>     rtcweb mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>>     <compose-unknown-contact.jpg>
>>>     Peter Thatcher <mailto:[e-mail]>
>>>     18 June, 2013 6:16 PM
>>>     Adam, I think you're confused.  As Ted pointed out, there are
>>>     two different uses of SDP: 1.  as a control surface, 2. as a
>>>     message format for signalling.  SDPNG was trying to replace SDP
>>>     for #2.  While I believe this thread was started entirely
>>>     focused on #1.  So you're talking about different things.
>>>
>>>     So far the only time spent on trying to replace or avoid SDP for
>>>     #1 has been "comment 22", and to a lesser extent the proposal I
>>>     just made for adding 2 methods to PeerConnection
>>>     (createLocalStream and createRemoteStream).   I think it's
>>>     incorrect to conclude that we should never try to improve #1
>>>     just because other in the past failed to replace #2.  They're
>>>     very different.
>>>
>>>     I also don't think we should burn down WebRTC and start over,
>>>     but despite what some seem to think, we don't have to choose
>>>     between "burn it down" and "never improve it".  There are many
>>>     options other than the two extremes.
>>>
>>>
>>>
>>>     By the way, a gentle reminder: SDP is not the only way to do #2.
>>>      I work on a rather large system almost entirely build around
>>>     Jingle, without a hint of SDP, and it works just fine.  Much
>>>     better than SDP would have, I think.  Just because SDPNG didn't
>>>     work out doesn't mean there will never be any way other to do
>>>     signalling than SDP.
>>>
>>>
>>>
>>>
>>>     _______________________________________________
>>>     rtcweb mailing list
>>>     [e-mail] <mailto:[e-mail]>
>>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/rtcweb
> Peter Thatcher <mailto:[e-mail]>
> 19 June, 2013 12:28 PM
> I might be wrong, but I tried reading and understanding your whole 
> email, and it seems to come down to "I don't want to use SDP or a 
> different (JSON) form of SDP".  That's a fine thing to request, but 
> why don't you just say that?  It would save everyone a lot of reading 
> and confusion to be more concise.
>
> Or, if you have specific things you'd like to do but can't, what are 
> they?  I think that would help me, and others, understand more easily. 
>  Use cases would be helpful.
>
> On Wed, Jun 19, 2013 at 6:58 AM, Robin Raymond <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     The trouble is not that we can choose to send whatever we want
>     over the wire. I know we can. If the WebRTC API is left with SDP
>     as it stands, I'll dissect the SDP from the browser, reinterpret
>     and reconstruct on the SDP on the remote side. That is NOT the issue.
>
>     The summary of what I want/believe:
>     1) I want as close to raw access to RTP/ICE streams, media,
>     sources, outputs, codecs as viable. Obviously doing the actual
>     transmission, encoding/decoding from JS is not feasible (yet), nor
>     is secure [ICE must occur for mutual agreement to exchange data
>     between peers], but having controls for how these components are
>     wired together is extremely feasible from JS and would allow
>     immensely powerful apps to be produced from JS.
>
>
> What would you like to do that you can't do via SDP right now?  You 
> said this isn't just about working through SDP.  But I don't see 
> anything concrete you can't do right now with sufficient SDP 
> parsing/building/munging/hackery.
>
>     2) I don't want my primary interface to control media/RTP engines
>     to be via obtaining or providing SDPs to the browser (or any
>     alternative serialized format); especially given that SDP requires
>     a round trip offer/answer to the remote party to affect change
>     (e.g. it's entirely possible to do that stateless and one-sided).
>     The SPD interface API is a monolithic do-everything serialized
>     format to control an engine but extremely badly/poorly/short
>     sighted (regardless if it is SDP or whatever instead), and it's
>     wholly unneeded.
>
>
> Short summary: "I don't want to use SDP".  Right?
>
>     3) I don't want a replacement for SDP with another more "pretty"
>     format like JSON.
>
>
> Short summary: "I don't want to use SDP or a different syntax for 
> SDP".  Right?
>
>     4) I want no specified requirement from the browser to have any
>     particular form of media negotiation API requirement what-so-ever
>     (regardless if I can opt to substitute with my own format on the
>     wire or not)
>
>
> Short summary: "I don't want to use SDP or a different syntax for 
> SDP".  Right?
>
>     5) Using SDP with offer/answer build into the browser binary is a
>     horribly BAD technical choice (even for SIP folks) and must be
>     stopped, see:
>     http://www.ietf.org/mail-archive/web/rtcweb/current/msg07873.html
>
>
> Short summary: "I don't want to use SDP".  Right?
>
>
>
>     I too want to understand the rational for keeping something as bad
>     as SDP with offer/answer as the primary mechanism for controlling
>     the media components and interaction to those component and more
>     importantly, I'd too would like to open debate to agreeing or not
>     to provide a lower layer API rather than a media negotiation API
>     as a complete substitute alternative to SDP with offer/answer.
>
>     If we can agree that it's far superior to have a lower level
>     media/RTC component API rather than a media negotiation API, then
>     we can propose what that API could look like (and there are people
>     who have already have starting proposals). I'd throw my hat in the
>     ring to propose such and API if necessary as I've written such
>     engines from scratch before. But I don't want to waste time
>     proposing ore reviewing such an API which will be summarily
>     dismissed because people are so stuck on requiring a media
>     negotiation API built into the browser binary, and specifically
>     SDP with offer/answer in this case.
>
>
>
> The WG may dislike and reject your proposal, but there's a bit of 
> truth to the old mathematically incorrect sports adage "you miss 100% 
> of the shots you don't take".
>
>
>     Anyone who argues that they need/want that simple SDP media
>     negotiation API must understand that a lower level API would allow
>     a wrapper API to produce the same WebRTC API the have today but be
>     built entirely from JavaScript
>
>
> That depends on how low-level you go.  If you go too low-level, it 
> becomes infeasible to do things correctly and performantly in JavaScript.
>
>     upon a lower level API. Thus they can have their "just add-milk"
>     baking API. But those of us who need control of the raw
>     ingredients beyond the "just add milk" can still innovate.
>
>     -Robin
>
>
>>     Peter Thatcher <mailto:[e-mail]>
>>     19 June, 2013 2:49 AM
>>     Correct my if I'm wrong, but the API already leaves what goes
>>     over the wire completely up to the JS app.  So we couldn't
>>     re-open a debate of "SDP or not SDP" for the wire format, because
>>     there's nothing to debate.  We already decided it would be left
>>     to the JS to decide.  The only thing left to debate is the API.
>>
>>     Or am I wrong?
>>
>>
>>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>     Christer Holmberg <mailto:[e-mail]>
>>     19 June, 2013 2:34 AM
>>     Hi,
>>     We need to be very clear what we talk about, or some people are
>>     always going to be confused :)
>>     So, AFAIK, the discussion is about SDP O/A usage in the API, only
>>     in the API, and nowhere but the API.
>>     Whatever people us on the wire is outside the scope.
>>     Right?
>>     Regards,
>>     Christer
>>
>>
>>     Sent from */Windows/* using *TouchDown* (www.nitrodesk.com
>>     <http://www.nitrodesk.com>)
>>
>>     -----Original Message-----
>>     *From:* Peter Thatcher [[e-mail]
>>     <mailto:[e-mail]>]
>>     *To:* Martin Thomson [[e-mail]
>>     <mailto:[e-mail]>]
>>     *CC:* [e-mail] <mailto:[e-mail]> [[e-mail]
>>     <mailto:[e-mail]>]
>>     *Subject:* Re: [rtcweb] Requesting "SDP or not SDP" debate to be
>>     re-opened
>>     Martin, you're right; that was overly harsh of me.  Adam, I
>>     apologize.  I'll be civil in the future.
>>
>>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>     Peter Thatcher <mailto:[e-mail]>
>>     19 June, 2013 1:36 AM
>>     Martin, you're right; that was overly harsh of me.  Adam, I
>>     apologize.  I'll be civil in the future.
>>
>>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>     Martin Thomson <mailto:[e-mail]>
>>     18 June, 2013 6:25 PM
>>     I agree with Peter, except for this bit:
>>
>>     Adam is much harder to confuse than you think, or than he professes.
>>
>>     Speaking of burning it all down and starting over. If you want a
>>     house-related analogy, that's not quite correct. It's refusing to
>>     build an extension because the old house, while legally fit for
>>     habitation, is falling down around your ears. Since you only need
>>     foundations, it's not that big a job (though I'll grant you that it's
>>     bigger than many people realize, even with that smaller scope).
>>     _______________________________________________
>>     rtcweb mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>>     Peter Thatcher <mailto:[e-mail]>
>>     18 June, 2013 6:16 PM
>>     Adam, I think you're confused.  As Ted pointed out, there are two
>>     different uses of SDP: 1.  as a control surface, 2. as a message
>>     format for signalling.  SDPNG was trying to replace SDP for #2.
>>      While I believe this thread was started entirely focused on #1.
>>      So you're talking about different things.
>>
>>     So far the only time spent on trying to replace or avoid SDP for
>>     #1 has been "comment 22", and to a lesser extent the proposal I
>>     just made for adding 2 methods to PeerConnection
>>     (createLocalStream and createRemoteStream).   I think it's
>>     incorrect to conclude that we should never try to improve #1 just
>>     because other in the past failed to replace #2.  They're very
>>     different.
>>
>>     I also don't think we should burn down WebRTC and start over, but
>>     despite what some seem to think, we don't have to choose between
>>     "burn it down" and "never improve it".  There are many options
>>     other than the two extremes.
>>
>>
>>
>>     By the way, a gentle reminder: SDP is not the only way to do #2.
>>      I work on a rather large system almost entirely build around
>>     Jingle, without a hint of SDP, and it works just fine.  Much
>>     better than SDP would have, I think.  Just because SDPNG didn't
>>     work out doesn't mean there will never be any way other to do
>>     signalling than SDP.
>>
>>
>>
>>
>>     _______________________________________________
>>     rtcweb mailing list
>>     [e-mail] <mailto:[e-mail]>
>>     https://www.ietf.org/mailman/listinfo/rtcweb
>
>