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

Peter Thatcher <pthatcher@google.com> Wed, 19 June 2013 16:50 UTC

Return-Path: <pthatcher@google.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE00621F9D47 for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 09:50:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.713
X-Spam-Level:
X-Spam-Status: No, score=-1.713 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03paLDrhiJmo for <rtcweb@ietfa.amsl.com>; Wed, 19 Jun 2013 09:50:31 -0700 (PDT)
Received: from mail-pd0-f181.google.com (mail-pd0-f181.google.com [209.85.192.181]) by ietfa.amsl.com (Postfix) with ESMTP id 887C121F9D69 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 09:50:31 -0700 (PDT)
Received: by mail-pd0-f181.google.com with SMTP id 14so5222108pdj.40 for <rtcweb@ietf.org>; Wed, 19 Jun 2013 09:50:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Cfjurd0gpNwbHm8DbzItF2FlJWtzCkrk5ArFdl+0zEw=; b=pFdqg7dH1BWIfNygzovIcI4p6dK8qvMg0v583R94BkLzLLDorq76uOUPdn455+9vVC n0gVOQ5wmB1B0l7nD3sgUxPAvSrTV5h/VUgGve6nYJiMic6uBoQFyyETVYl1AY1ptjln iP9oilQw51aknAGNpaU3mwbjtLctbeeWgWO6thIlnPxzyaraO1j41o7PylX7UydgEDJl rN1usVR3kpy33pIbnBI+OicYcyVl1ztcpFopPt9fP6m5FGEfbOjv2TdZOo1OKFrEeLJ9 MVf/+pzFpLif2M2GpOna4ZDnOLROjedqWf2+N+h6PCckeAQhGL4vP26aH1Ll4JW0F1b9 QkjA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-gm-message-state; bh=Cfjurd0gpNwbHm8DbzItF2FlJWtzCkrk5ArFdl+0zEw=; b=Tb/v8FiNNyTidKB6M1nGQBk1dThrpL1hvxP2Iw5XQQBURptFRv590n/mBO8YZomseY BHX7N/SBBi8NjckzBr9WiJ5kqGeloEreNlc4Bog2JIURm9lqQYOfCCyd0Z/0osrwQl7H fRpc7GWj1yu4FzMsITEtei3B2DtuJELOg+Rxb9coIoIVs6JGnypN92tzfpI1cXeG8qai J4SHNSaySFixExSeY57/nR8WMk8PyRzJMjRxIvp0Q6JbY4uiWYEEWcVvjZEKtoSlz4EU NjSkZeD028YzQoR2nM89pbHFfeZBlcY5toEYi8k/LlFDGA0vMeKMcdHM9bB9DqWrx348 UQqg==
X-Received: by 10.68.69.108 with SMTP id d12mr3612823pbu.187.1371660628367; Wed, 19 Jun 2013 09:50:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.66.88.8 with HTTP; Wed, 19 Jun 2013 09:49:48 -0700 (PDT)
In-Reply-To: <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at>
References: <CALiegfkajJPxWZTzjYssP91VW+StStLpxoxGCkjOLKDMUWc0rA@mail.gmail.com> <CA+9kkMDk2L3SBPC08WU_5RcL16-Wzv8Mocj3-Qzmxz2E24ERGg@mail.gmail.com> <51C0C1A0.9010107@nostrum.com> <CAJrXDUGqSvsosZJhcRR-kCwEX1g_wvPnSZPmmcNwggk+Z9WNCA@mail.gmail.com> <CABkgnnWfV=5xBaRqAddqUURThs9J4T4+0HK4Ux07VA51r5oC3Q@mail.gmail.com> <CAJrXDUFNGKvWHw-yqeApEdTeuqMNPTDxvdKZ2DuzANmcR2y2CQ@mail.gmail.com> <7594FB04B1934943A5C02806D1A2204B1C3AE500@ESESSMB209.ericsson.se> <CAJrXDUHCkQSLab2UuY_vWP3Gr8uh+++c9mDq5f4sCpuaK5aeLQ@mail.gmail.com> <51C1B907.8060508@hookflash.com> <CAJrXDUG06jvPvhfNwZ6Puzxj7E4XxELG_fU=S7B_c=tnC9eoNQ@mail.gmail.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at>
From: Peter Thatcher <pthatcher@google.com>
Date: Wed, 19 Jun 2013 09:49:48 -0700
Message-ID: <CAJrXDUGOYc_Z_qWD7J0ZzVdfwYOacH_p5PjZEg5aP1LUetffMA@mail.gmail.com>
To: Matthew Kaufman <matthew@matthew.at>
Content-Type: multipart/alternative; boundary=0015174989ee81d1ce04df84a0b3
X-Gm-Message-State: ALoCoQl1UOwrbZ/d398LGS7gK9fkNiFWn+3Hb/ZNtdGtry5kXAQPF+I94xOqcRtLqZ1cQKtMaVJ3fWoh9RxznxInpabcQGnXyN21E3hW+76aUz4xY1Z3rZg99I114n1+YozUTLF0mMMUQaLWEwMl+sTQ/i+34YOa7RY5l/8qhwLjEVn7C1Dg4aFYyXx0mw70VTITO54HouSs
Cc: "rtcweb_ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Requesting "SDP or not SDP" debate to be re-opened
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 16:50:37 -0000

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

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




On Wed, Jun 19, 2013 at 9:36 AM, Matthew Kaufman <matthew@matthew.at> wrote:

> I provided a use case that, unless one wants to write a bunch of
> SDP-munging JS state machine cannot be done.
>
> The problem is that such use cases are either 1) ignored or 2) dismissed
> because of course if one writes said JS, they are possible with the current
> API
>
> Matthew Kaufman
>
> (Sent from my iPhone)
>
> On Jun 19, 2013, at 9:28 AM, Peter Thatcher <pthatcher@google.com> 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 <robin@hookflash.com>wrote;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 <pthatcher@google.com>
>>  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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>  <compose-unknown-contact.jpg>
>>  Christer Holmberg <christer.holmberg@ericsson.com>
>>  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)
>>
>> -----Original Message-----
>> *From:* Peter Thatcher [pthatcher@google.com]
>> *To:* Martin Thomson [martin.thomson@gmail.com]
>> *CC:* rtcweb@ietf.org [rtcweb@ietf.org]
>> *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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>  <compose-unknown-contact.jpg>
>>  Peter Thatcher <pthatcher@google.com>
>>  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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>   <compose-unknown-contact.jpg>
>>  Martin Thomson <martin.thomson@gmail.com>
>>  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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>   <compose-unknown-contact.jpg>
>>  Peter Thatcher <pthatcher@google.com>
>>  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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>