Re: [rtcweb] JSEP: Relaxing SDP O/A rules?

Martin Thomson <martin.thomson@gmail.com> Thu, 04 October 2012 18:00 UTC

Return-Path: <martin.thomson@gmail.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 B6F2721F8648 for <rtcweb@ietfa.amsl.com>; Thu, 4 Oct 2012 11:00:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.224
X-Spam-Level:
X-Spam-Status: No, score=-3.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KM3Rz7EHOzTl for <rtcweb@ietfa.amsl.com>; Thu, 4 Oct 2012 11:00:55 -0700 (PDT)
Received: from mail-wg0-f42.google.com (mail-wg0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id E6F5721F8605 for <rtcweb@ietf.org>; Thu, 4 Oct 2012 11:00:54 -0700 (PDT)
Received: by mail-wg0-f42.google.com with SMTP id fm10so2184154wgb.1 for <rtcweb@ietf.org>; Thu, 04 Oct 2012 11:00:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=w4CpyFw1OJs/Q/qto5uw8tY+DlHCAsX5oXL+9QMtWAM=; b=WpnfGmhJ/IthP0OnTT+txymiSPxhnajiIRUv4qbITNa4eZbeovT73hU27Xp+G+QdSc s46a7xoHBXizp+z8g784GgiDE4cZD2C7mZMrqIj9wIK0L3bNjFLQp7Jo87CKPYAxRPzW K6f9ASu9cu/WL9iHdr+uN3ylSeWltvoxdPzv0PojNbAsBFItzE/zC5F82TxCoJvpsrEm X3Z+9FN+1933TLb+uYKBw16KjsZqWwbzCpMm2c3mebtVcr9IeShlRhpZcmo3uzL9wKdx f9pUenQJzcZgMZalA8t9vr2QMDDKNhbJt+GSP9eHPSzejHkjZrkKj5VZVa/rl66BrlXE MSGA==
MIME-Version: 1.0
Received: by 10.180.73.76 with SMTP id j12mr14629457wiv.11.1349373653964; Thu, 04 Oct 2012 11:00:53 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Thu, 4 Oct 2012 11:00:53 -0700 (PDT)
In-Reply-To: <506D4F7A.5020109@alvestrand.no>
References: <7F2072F1E0DE894DA4B517B93C6A0585340A1E3AB1@ESESSCMS0356.eemea.ericsson.se> <CABkgnnUFvw_J2+tvVBoHrzR9ZRkPT-6LhXvbaz_U1P7gqtJ4xw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A0585340A7BC848@ESESSCMS0356.eemea.ericsson.se> <CABkgnnV6NcTeh=L_fpkpLv5UpkUSuacmQUtYwNKKwAfcb5+JQA@mail.gmail.com> <506D4F7A.5020109@alvestrand.no>
Date: Thu, 4 Oct 2012 11:00:53 -0700
Message-ID: <CABkgnnUgHRw4dtihk2fZppmzVWuV4hpvWtXt70N1HWQpJ+KsZw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=UTF-8
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] JSEP: Relaxing SDP O/A rules?
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: Thu, 04 Oct 2012 18:00:55 -0000

On 4 October 2012 09:57, Harald Alvestrand <harald@alvestrand.no> wrote:
> For the Web use case, I think PRANSWER is an unnecessary distraction; if
> we're writing both initiator and responder, multiple O/A rounds, or use of
> multiple PeerConnections, is a much cleaner solution for the use cases I can
> wrap my head around.

I'd remove that qualifier.  We currently have a draft that describes
both cloning AND PRANSWER, both of which are more cleanly addressed by
either multiple O/A rounds or multiple independent sessions.

The two things that these provide is

PRANSWER:
The ability to describe a session that includes receipt capabilities
that are a superset of send capabilities.  SDP O/A doesn't really
provide a way for me to describe this because the default assumption
is that items not appearing in the answer are no longer needed.
With something like bundle involved, we could split m= lines into
sendonly and recvonly portions to allow for this case to be provided.

CLONING:
The ability to use the same transport primitives to interact with
multiple peers.  Ostensibly, this is to prepare for a session, with
only one continuing to completion, mainly to reduce clipping.
By adding candidates from all serial offenders to the same answer, you
can get ICE setup, though I doubt that DTLS handshakes will be able to
complete unless we permit multiple a=fingerprint lines and a few other
things.  I'm still disinclined to support this feature.  Let the
forkers have clipping.

Both of these complicate the API significantly.  I'd rather see the
complexity pushed to the applications that need this complexity.

That is, unless you are willing to consider a better API that makes
these issues SEP.