Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-signaling)

Iñaki Baz Castillo <ibc@aliax.net> Tue, 18 October 2011 11:19 UTC

Return-Path: <ibc@aliax.net>
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 A4C1621F8B54 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 04:19:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.632
X-Spam-Level:
X-Spam-Status: No, score=-2.632 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 9eqFPkRIXQgN for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 04:19:01 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A3C621F8B53 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 04:19:01 -0700 (PDT)
Received: by vws5 with SMTP id 5so283506vws.31 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 04:19:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.25.75 with SMTP id a11mr1901344vdg.1.1318936739922; Tue, 18 Oct 2011 04:18:59 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 04:18:59 -0700 (PDT)
In-Reply-To: <4E9D5E9A.7090308@alvestrand.no>
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <CAD5OKxvE77Fia1hVRhdmqnfsOExpdJq=J2VMwtsfB_7ztEYtLA@mail.gmail.com> <4E9D43D2.9010804@alvestrand.no> <CALiegfnaE4OX6QHkkr1k5+Ux2WUOixB+4=e52_+gpphM4HKi6w@mail.gmail.com> <4E9D5E9A.7090308@alvestrand.no>
Date: Tue, 18 Oct 2011 13:18:59 +0200
Message-ID: <CALiegfkPk=o0YvmUCocmUOeL_hp37UogeYkv9vE=KQqQESRcKg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: Jonathan Rosenberg <jonathan.rosenberg@skype.net>, rtcweb@ietf.org, public-webrtc@w3.org
Subject: Re: [rtcweb] API options for supporting fork with ROAP (Re: SDP Offer/Answer draft-jennings-rtcweb-signaling)
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: Tue, 18 Oct 2011 11:19:01 -0000

2011/10/18 Harald Alvestrand <harald@alvestrand.no>;:
>> Said that, I strongly like your option 2 "Creating a new
>> PeerConnectionFactoryWithOffer". If I understand it properly, when a
>> RTCweb environment allows media forking, the RTCweb client should
>> create a PeerConnectionFactoryWithOffer object rather than a
>> PeerConnection. Then it sends the offer over the wire. Upon receipt of
>> each response with different ROAP/SDP answer, the object would
>> internally generate different PeerConnection objects (but the state of
>> all of them are governed by the PeerConnectionFactoryWithOffer
>> object). Am I right?
>
> Yes, that's right.
>
> One advantage of this approach is that the new class comes in addition to
> the normal PeerConnection class, so the interface for this functionality
> does not clutter up the interface for applications that don't want to deal
> with forking; they just never create such objects, and will reply to
> subsequent answers with "ERROR" (as they're always free to do).

I like the idea.



> There are a number of additional details that need specification before this
> can be implemented, of course; we might want to delay that functionality
> beyond the first wave of releases.

As you noted, the point is that this advanced feature can be added
later over the existing stack. So I support this proposal.


Regards.




-- 
Iñaki Baz Castillo
<ibc@aliax.net>;