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

Roman Shpount <roman@telurix.com> Sat, 22 June 2013 00:08 UTC

Return-Path: <roman@telurix.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 748CF21F9DBB for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 17:08:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.862
X-Spam-Level:
X-Spam-Status: No, score=-1.862 tagged_above=-999 required=5 tests=[AWL=0.115, 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 8POHOzWHOu61 for <rtcweb@ietfa.amsl.com>; Fri, 21 Jun 2013 17:08:06 -0700 (PDT)
Received: from mail-we0-x234.google.com (mail-we0-x234.google.com [IPv6:2a00:1450:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id 85EAC21F9DC0 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 17:08:05 -0700 (PDT)
Received: by mail-we0-f180.google.com with SMTP id w56so6942259wes.11 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 17:08:04 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZzfrKMHmO/5fayQazuiasrgOJpnKrf1WnkgYRQNR1yA=; b=AD4JEE6Nn3zlj/+nne/VRfqCH7mzRO6AlBGk4joSUEyP5ihzzi3j80mNcb3URTyn1N 7HhKZsYM1/1gNprCbPnk9NK4NSapswqh5o1JkRzlb4dIX2aS567PGfKPNsP8j63EgK8X R+rhogqnnZu5LiZE8+/VPRjAoZmm9fBojjjHsFbmkv4IgjnUBpS88J/gR2YyAbryqSKu ksrKDDIaSlu7p94Mjm4bOef4JowwcQvgWtzf/wuvn9CgC0A0BJlKDDt9HPHx6odjVRJV vm2F8LgJU+/HmgNYUstxUHQztS7evNB8V/HBOnJPsNsPr+pgAtExxIaEZklZmNr+wmEY 6B+g==
X-Received: by 10.194.2.79 with SMTP id 15mr10879525wjs.42.1371859684689; Fri, 21 Jun 2013 17:08:04 -0700 (PDT)
Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [2a00:1450:400c:c05::22a]) by mx.google.com with ESMTPSA id b20sm841204wiw.4.2013.06.21.17.08.03 for <rtcweb@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 17:08:03 -0700 (PDT)
Received: by mail-wi0-f170.google.com with SMTP id ey16so1184866wid.3 for <rtcweb@ietf.org>; Fri, 21 Jun 2013 17:08:02 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.85.6 with SMTP id d6mr306980wiz.47.1371859682743; Fri, 21 Jun 2013 17:08:02 -0700 (PDT)
Received: by 10.216.221.202 with HTTP; Fri, 21 Jun 2013 17:08:02 -0700 (PDT)
In-Reply-To: <CAHp8n2=DxMrs+FNjTegNMkihkqQuZHSA3EN4r9dxf+_ti7gDdQ@mail.gmail.com>
References: <CALiegfkajJPxWZTzjYssP91VW+StStLpxoxGCkjOLKDMUWc0rA@mail.gmail.com> <78192824-A516-4376-8D4F-3B052ED47A0C@matthew.at> <CAJrXDUGOYc_Z_qWD7J0ZzVdfwYOacH_p5PjZEg5aP1LUetffMA@mail.gmail.com> <51C1F2E9.20405@hookflash.com> <51C1F5ED.9090308@matthew.at> <51C20FAA.4050701@hookflash.com> <CABkgnnWw9anT+h_hnF14nBChS73qpTb31hSM=p2KnGrcRPGRJA@mail.gmail.com> <51C3209B.1030501@alvestrand.no> <CALiegfkEpwxNZL8TU0ofCzRB_Gza+NoSnZpGcM=tuYBOXmHsZQ@mail.gmail.com> <51C335F9.4000900@alvestrand.no> <CALiegfk_wwvdSixFYWpBBdUNfXxmcOwCnRsjyS6J3M9WG_dJCg@mail.gmail.com> <51C38356.3020402@jitsi.org> <CALiegfm1xYpAnmrg=4vx_06RZQTo_RS2nFJoidpoQtjg2kn=Vw@mail.gmail.com> <1371807600.23131.YahooMailNeo@web171301.mail.ir2.yahoo.com> <CALiegfmPV=E2qh_E-v_eBiSj9iK7Un2JLDtELF7xnYARHy5B3g@mail.gmail.com> <9F33F40F6F2CD847824537F3C4E37DDF115D4A59@MCHP04MSX.global-ad.net> <CAD5OKxtYeDP-O_YfT3G=+mHPfPKAthJVuoYtNaa3R97yFU-ZoA@mail.gmail.com> <4337C1D6-5D1E-4316-A96B-E6FBA2E647E7@siemens-enterprise.com> <51C48F4A.9070707@hookflash.com> <CAHp8n2=DxMrs+FNjTegNMkihkqQuZHSA3EN4r9dxf+_ti7gDdQ@mail.gmail.com>
Date: Fri, 21 Jun 2013 20:08:02 -0400
Message-ID: <CAD5OKxtwZRca6PN_WEg5CKNFVgyW8K0iAGDRgrvf9kXSbCMDyQ@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Content-Type: multipart/alternative; boundary="f46d0442808e125cd504dfb2f9c6"
X-Gm-Message-State: ALoCoQmpJ6CxrJZd0EEI9JlKMwqrb+AGgfM5cmyN4r4rWXw7/GTEi61NYDe1ciPNXAbXS+d8rrig
Cc: diopmamadou@doubango.org, "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: Sat, 22 Jun 2013 00:08:06 -0000

On Fri, Jun 21, 2013 at 7:54 PM, Silvia Pfeiffer
<silviapfeiffer1@gmail.com>wrote:

> Is it possible to continue using SDP but not do o/a ?
>

Neither SDP not O/A belongs in API.

The issue with SDP is that it creates an API surface which is using a
string blob. To make such API a standard you need to standardize the blob
format. Also, every time you add features you need to update the SDP format
and all the parsers that are dealing with it. Not sustainable long term.
Finally, SDP mixes multiple unrelated data items together, ie it specifies
transport parameters and media parameters at the same time. For a normal
API flow you need to control those separately.

O/A implies one model to negotiate media and transport parameters and
forces them to be negotiated at the same time. One other thing to keep in
mind that O/A compliant end points are not O/A internally. For instance you
can change the sending codec or sending codec parameters (like bitrate)
without going through offer/answer exchange. So, normally end points expose
offer/answer to the network, but use a different API internally to control
transport and media settings based on data received from O/A exchanges,
user input, and other factors (like detecting high packet loss and reducing
bandwidth or changing codec).
_____________
Roman Shpount