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

Martin Thomson <martin.thomson@gmail.com> Thu, 04 October 2012 18:43 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 62DC721F86DE for <rtcweb@ietfa.amsl.com>; Thu, 4 Oct 2012 11:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.479
X-Spam-Level:
X-Spam-Status: No, score=-3.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, 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 wx0mEfGeg7In for <rtcweb@ietfa.amsl.com>; Thu, 4 Oct 2012 11:43:56 -0700 (PDT)
Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAF021F86DC for <rtcweb@ietf.org>; Thu, 4 Oct 2012 11:43:56 -0700 (PDT)
Received: by mail-we0-f172.google.com with SMTP id u46so593129wey.31 for <rtcweb@ietf.org>; Thu, 04 Oct 2012 11:43:55 -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=puGXgGkVg9JITjouOp5/wz984UDuh2pgGUxO5VAyNcw=; b=yLJLH9BTTr3s4mf7kTDvZaYmraUvdl2aveC3h/xOorv2yGoDEbSPai/whghxXjDbh2 raAb8b0hIwY4MpHqjHU9N1rjpdiRFJlBwcWYQBNdp9pc111cLgq2ICmAeHyButreFevm msIb2x4/yljcug99rnzV9KzztO6W7mpaGwXknobf2MYbLwDm5pRKNjD218rbKEo8YHiN 3p8qmNogb+Y3OSRqQVDBl8qV6iqTiUHgNN0P6hwChuh57M8r6THuKR/+WTT61G+/VV6q omKgXzoJdlFM0rVi3LvH/Tr+vUoW0rta7QnzDyi4Pw5uKJOnNHvsO/TzgMCIIKgSarP9 Si2A==
MIME-Version: 1.0
Received: by 10.216.141.16 with SMTP id f16mr4153669wej.130.1349376235326; Thu, 04 Oct 2012 11:43:55 -0700 (PDT)
Received: by 10.180.96.9 with HTTP; Thu, 4 Oct 2012 11:43:55 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se>
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> <CABkgnnUgHRw4dtihk2fZppmzVWuV4hpvWtXt70N1HWQpJ+KsZw@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05853409FF2FDF@ESESSCMS0356.eemea.ericsson.se>
Date: Thu, 4 Oct 2012 11:43:55 -0700
Message-ID: <CABkgnnV+jHWF3t8s3t37pbQyXJEP9N_MyHWd3SsfoNrhMU=NXw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: text/plain; charset=UTF-8
Cc: "rtcweb@ietf.org" <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:43:57 -0000

On 4 October 2012 11:21, Christer Holmberg
<christer.holmberg@ericsson.com> wrote:
> I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.

Not my point.  My point is that the desired functionality (apply the
answer without invalidating the offer) cannot be easily provided using
SDP O/A.  Most scenarios leave the possibility that the offerer sends
the (provisional) answerer stuff that the answerer doesn't want.

> If you want to support parallel forking, you need to be able to simultanously perform ICE etc with all remote peers.

Right.  You can almost get that by pretending that it's just one
remote peer with lots of candidates.  You can at least get to the
consent point by doing that.  But you aren't going to nominate more
than one pair.  Similarly, this will only generate a single DTLS
session.

Media is a complete mess if you manage to get that far.  Unless you
like scenarios were A and hear B and C, but B and C can't hear each
other and other such joys (there's a consent issue too, but it's a
minor issue of scale).

>>Both of these complicate the API significantly.  I'd rather see the
>>complexity pushed to the applications that need this complexity.
>
> I want to be able to support forking. Exactly HOW it's done can be discussed.

One approach is to create as many RTCPeerConnection objects as you
feel might be needed.  Then it becomes YOUR problem, not our problem.
And those are the sorts of problem I like ;)  (I might be interested
in forking too, but I'm happy to keep my problems private.)

> Also, I can live without support of parallel forking, and I don't really care if serial forking support is provided using cloning or being able to update the remote descriptor (using PRANSWER, or something else).

Serial forking is potentially far easier to support by doing a series
of O/A exchanges:
10: setLocal(offer)
20: get next answer
30: setRemote(answer)
40: goto 10
There's the small matter of having no guarantee that the offer will
set successfully, but I'd consider that an unlikely scenario in
practice.

>>That is, unless you are willing to consider a better API that makes
>>these issues SEP.
>
> You have one in mind? ;)

I am not at liberty to disclose that information.