Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
Robin Raymond <robin@hookflash.com> Fri, 08 March 2013 13:22 UTC
Return-Path: <robin@hookflash.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 56B6221F8659 for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 05:22:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-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 mSzdZ2DGjsbb for <rtcweb@ietfa.amsl.com>; Fri, 8 Mar 2013 05:22:29 -0800 (PST)
Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E9C3421F85FD for <rtcweb@ietf.org>; Fri, 8 Mar 2013 05:22:28 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id x8so1012466wey.6 for <rtcweb@ietf.org>; Fri, 08 Mar 2013 05:22:20 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=58xGihizB8B7qTmiVlBOk9y7avgJvwa+334APIg+jMU=; b=adUUdj7rGC7tQ77n6EdrGhLWZNpi2YIak0gONvNcqHbl0titG8gPxbf03Ugpk+Mpz8 2U0ofhPjuHz1cjp87yHXre2JmTX3psfwON5QmMoH9V1PkOt3U/BTGR2673YYXSDPkYOi KK6iMoQjdPMQMQuc0brkvS2ZMqlK+moEksZ56PniPGqySYzw3KY+Kcgw9isZ45Wq9YYY dd0Qwyp+/cYym9VW9Y97qm1S4wSlyd8BhC8w3RfzDtjV9WATuUh5RpVnXzCvWsTj6VVZ 0dj/XsMfhYykKu1F5g3CH0LPNVwUYrBJ5q/sOA6te1oxkjfB4Hab99fWToZqp+6qLvyH QAFQ==
MIME-Version: 1.0
X-Received: by 10.194.83.105 with SMTP id p9mr3787493wjy.56.1362748940132; Fri, 08 Mar 2013 05:22:20 -0800 (PST)
Received: by 10.194.57.35 with HTTP; Fri, 8 Mar 2013 05:22:20 -0800 (PST)
Date: Fri, 08 Mar 2013 08:22:20 -0500
Message-ID: <CAADs5MoG=9v5Aeeq2byYGz4hNdHOng96Z0SXCLUJd4MKGw=vPg@mail.gmail.com>
From: Robin Raymond <robin@hookflash.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: multipart/alternative; boundary="047d7bb04ed67eb87c04d769b625"
X-Gm-Message-State: ALoCoQmaXV7/3YZmy9SN8z7RyWcdjm7LxdkIwSWNlcl3jd9j+fyvsEYAXwrAvh5iSMwOd+9NDYdh
Subject: Re: [rtcweb] Proposed Plan for Usage of SDP and RTP - Lower level API minus SDP
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: Fri, 08 Mar 2013 13:22:31 -0000
Without going into tremendous details (which believe me, I could), I'm going to summarize the reasons why I believe it's a bad idea to include SDP: - increases incompatibilities - support nightmare (whose to blame when the format introduces problems and features are injected into SDP along the way) - bad user experience (protocol will be brittle) - non predictable behavior, i.e. not an API-contract (receiving side can't predict or control implied logic, behaviours, etc) - forces SDP to be standard on all future protocols (not advisable or too dangerous to parse SDP but some will have to in order to send as alternative format and then reassemble) - offer / answer actually breaks other concepts of state machines - offer / answer forces problems that don’t need to exist when done differently (roll back, simultaneous negation cross over, SSRC clashes, knowledge of remote party's state) - does not really solve legacy compatibility (would likely increase legacy incompatibility IMHO) - truly is not needed - initially simpler for some programmers but at the cost of tremendous pain forever for others - forever hamper future technologies and burden them with SIP issues - make browsers much more difficult to innovate - make new protocols much more difficult to innovate - will cause the introduction of SBCs to sanitize the SDPs mid point to correct compatibility issues - cause rollouts of new browser versions with even the tiniest of SDP changes to break countless existing devices I have to strongly reiterate. It's not just the format. It's the concept. I know there is the argument "we need some data to be exchanged and this is close to what we need". Absolutely, we need data but it can be at the split by only what each component actually needs rather than one big monolithic thing. Many parts of the information are the relationships between media. I strongly prefer to assemble relationships with code control than with monolithic blobs. Again, it's not necessary to have the blob at all. Take CR-RTCWEB for example, they have objects that each independently take the information for each component and then you wire the components together. Is it perfect? No, but that's the kind of API that would make future stuff much more possible/better. (Not pushing them, just using as an example.) Would a JSONified version be better? Perhaps. It could be treated as one big function call with JSONified arguments. The format is certainly nicer. But I think that will cause a large amount of arguments as to what that should be and in order to make it flexible. I would be happier I suppose, especially if it got rid of offer/answer but I don't think all the problems are truly solved. Perhaps if that's all that we could "win" it might be better but I'm not sure it won't introduce new problems either. I completely agree with Erik's suggestion: Expose a lower layer stream API, without SDP and without offer/answer and then create a library (perhaps entirely JS) that mimics the behavior of the current drafts on top of the lower layers. The SIP people get exactly what they want and think they need and those that need lower to innovate new stuff get what they absolutely need. Benefits: Both sides win and nobody loses. This should not be any harder to make since all that logic is layered internally this way anyway (it must be). Better still, Microsoft/IE can be brought back into the mix and the proposals can be reunited. Perhaps I'm an idealist though with rose coloured glasses. If we lock into SDP, the long-term implications will be very bad for WebRTC (IMHO). Ultimately, whatever is imposed, I will adopt and adapt. In our case, we'll have to make a really tough choice of how we will have to mess with SDP or make wonky work-arounds for the problems SDP introduces. If forced to use SDP, are any others willing to work on a common JS library with us for the sender/receiver that extracts the SDP from the browsers into informational structures, manipulates the data (completely outside of the browser APIs which tie it to real streams), and sanitizes/normalizes the SDP behaviours to make it more contractual/predictable in behaviour? I really don't like this idea but if we are forced to use SDP then at least it would be better to have a common library to handle the pain of manipulating the SDP for those who can't avoid it. I'd prefer not introduce yet another set of incompatibilities between all of us that will need to do it.
- [rtcweb] Proposed Plan for Usage of SDP and RTP -… Robin Raymond
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Hadriel Kaplan
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Martin Thomson
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Mary Barnes
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Eric Rescorla
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Roman Shpount
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Eric Rescorla
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Mary Barnes
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Erik Lagerway
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Iñaki Baz Castillo
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Iñaki Baz Castillo
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Iñaki Baz Castillo
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Roman Shpount
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Matthew Kaufman
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Iñaki Baz Castillo
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Matthew Kaufman
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Timothy B. Terriberry
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Silvia Pfeiffer
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Timothy B. Terriberry
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Harald Alvestrand
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Stefan Håkansson LK
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Robin Raymond
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Stefan Håkansson LK
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Stefan Håkansson LK
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Stefan Håkansson LK
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Peter Thatcher
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Matthew Kaufman (SKYPE)
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Matthew Kaufman (SKYPE)
- [rtcweb] Division of labor (Re: Proposed Plan for… Harald Alvestrand
- Re: [rtcweb] Division of labor (Re: Proposed Plan… Matthew Kaufman
- Re: [rtcweb] Proposed Plan for Usage of SDP and R… Justin Uberti
- [rtcweb] Separating stream manipulation from the … Harald Alvestrand
- Re: [rtcweb] Separating stream manipulation from … Peter Thatcher
- Re: [rtcweb] Separating stream manipulation from … Stefan Håkansson LK
- Re: [rtcweb] Separating stream manipulation from … Harald Alvestrand
- Re: [rtcweb] Separating stream manipulation from … Ted Hardie
- Re: [rtcweb] Separating stream manipulation from … Martin Thomson
- Re: [rtcweb] Separating stream manipulation from … Silvia Pfeiffer
- Re: [rtcweb] Separating stream manipulation from … Suhas Nandakumar
- Re: [rtcweb] Separating stream manipulation from … Silvia Pfeiffer
- Re: [rtcweb] Separating stream manipulation from … Harald Alvestrand
- Re: [rtcweb] Separating stream manipulation from … Dale R. Worley