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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 04 October 2012 18:21 UTC

Return-Path: <christer.holmberg@ericsson.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 D0A9521F8661 for <rtcweb@ietfa.amsl.com>; Thu, 4 Oct 2012 11:21:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.808
X-Spam-Level:
X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, RCVD_IN_DNSWL_MED=-4]
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 VPZilUFeHBEi for <rtcweb@ietfa.amsl.com>; Thu, 4 Oct 2012 11:21:26 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CA58C11E80E1 for <rtcweb@ietf.org>; Thu, 4 Oct 2012 11:21:24 -0700 (PDT)
X-AuditID: c1b4fb25-b7f046d00000644c-b4-506dd3a339aa
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B4.0A.25676.3A3DD605; Thu, 4 Oct 2012 20:21:23 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.99]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Thu, 4 Oct 2012 20:21:23 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>, Harald Alvestrand <harald@alvestrand.no>
Date: Thu, 4 Oct 2012 20:21:22 +0200
Thread-Topic: [rtcweb] JSEP: Relaxing SDP O/A rules?
Thread-Index: Ac2iWjXSYW+MEZhGQze7n9Bl7WSeEAAAGpH2
Message-ID: <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>
In-Reply-To: <CABkgnnUgHRw4dtihk2fZppmzVWuV4hpvWtXt70N1HWQpJ+KsZw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvre7iy7kBBnMPmVsc6+tis7h25h+j xdp/7ewOzB5XJlxh9dg56y67x5IlP5kCmKO4bFJSczLLUov07RK4Mrb8n8Nc8FSwYsabkAbG ZXxdjJwcEgImEnfO/WWFsMUkLtxbz9bFyMUhJHCKUWLRxn5WCGc2o8SdnzOBMhwcbAIWEt3/ tEEaRAQiJY4cOcsOYjMLqEvcWXwOzGYRUJFof9HLCGILCxhLdH4+xgRRbyKxZscaFgjbSGLV jIlgNbwC4RKrjm+AWjybWWLRjg6wIk6BQImjy56ADWUEuu77qTVMEMvEJW49mc8EcbWAxJI9 55khbFGJl4//sULUi0rcaV/PCFGvI7Fg9yc2CFtbYtnC18wQiwUlTs58wjKBUWwWkrGzkLTM QtIyC0nLAkaWVYzCuYmZOenlRnqpRZnJxcX5eXrFqZsYgfF0cMtv1R2Md86JHGKU5mBREue1 3rrHX0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAPj/JLOPz+3yZ9+s91Fg60mzWmnmYKowLwP byyf8XzeYcWSOoND2ZTJLiiPecfNvuqrTyO3HP4op3VStHTRZB4j4xXTM43PXrY9wpnMIZMm HpdTL11Z43yt94JxztK38pr5qjNyd6fOP7Pr28vpX1WcA/Z1n9vWVvbgYN/0hnCppm3h85Ot 2hKUWIozEg21mIuKEwH7+jnRdQIAAA==
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:21:28 -0000

Hi,

>> 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.
>
>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.

I don't think the reason for PRANSWER comes from SDP O/A as such. It's more about supporting serial forking.

>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.

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

>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.

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).

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

You have one in mind? ;)

Regards,

Christer