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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Tue, 18 October 2011 13:57 UTC

Return-Path: <stefan.lk.hakansson@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 DFD5421F8AD9 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 06:57:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
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 uQAPGiJJZLJM for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 06:57:34 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1F10221F84FA for <rtcweb@ietf.org>; Tue, 18 Oct 2011 06:57:33 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-a2-4e9d85cd2a71
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DF.BB.20773.DC58D9E4; Tue, 18 Oct 2011 15:57:33 +0200 (CEST)
Received: from [150.132.141.126] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.137.0; Tue, 18 Oct 2011 15:57:33 +0200
Message-ID: <4E9D85CB.6030503@ericsson.com>
Date: Tue, 18 Oct 2011 15:57:31 +0200
From: =?UTF-8?B?U3RlZmFuIEjDpWthbnNzb24gTEs=?= <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110922 Lightning/1.0b2 Thunderbird/3.1.15
MIME-Version: 1.0
To: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
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> <CALiegfkPk=o0YvmUCocmUOeL_hp37UogeYkv9vE=KQqQESRcKg@mail.gmail.com> <4E9D7019.2020303@ericsson.com> <CALiegf=3dHhC1gt=YEH-=7mdi33cjKx74OMa65CxVDvsgRwUdQ@mail.gmail.com>
In-Reply-To: <CALiegf=3dHhC1gt=YEH-=7mdi33cjKx74OMa65CxVDvsgRwUdQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.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 13:57:35 -0000

On 10/18/2011 03:30 PM, Iñaki Baz Castillo wrote:
> 2011/10/18 Stefan Håkansson LK<stefan.lk.hakansson@ericsson.com>;:
>> Our idea is basically that whenever you create a new PeerConnection in
>> the same context as you have already created one or more
>> PeerConnection's, the same local candidates should be re-used. Of course the
>> 5-tuple must remain unique so that different connections don't collapse into
>> one, but this is quite simple to resolve.
>>
>> For clarity, the above would be requirements on the implementation (in
>> browsers).
>>
>> This means that support of forking would be simple as the IP+port's to
>> send media to (for the remote end) remains also for the new PeerConnection.
>>
>> Another advantage is that creating new PeerConnections will be faster as new
>> candidates does not need to be gathered.
>>
>> I think this is quite a clean solution since there is no need for API
>> changes, or any additional factory layer.
>
>
> Hi Stefan, that looks nice, but could you explain what does it mean
> "in the same context as you have already created one or more
> PeerConnection's"?

What I mean is: if this web app has already created a PeerConncection, 
and is about to open another one (e.g. for a new fork), the new 
PeerConnection should use the same local candidates as the one already 
created collected.

>
> Could you please translate it into a theorical JS API?

Even better, I can point to the current API proposal: 
<http://dev.w3.org/2011/webrtc/editor/webrtc-20111017.html>;. I think no 
changes would be required to the API per se, but some text on how the 
user agent should act need to be added.

(I'm sure I've overlooked some aspect, but hopefully it would be 
possible to fix)

Br,
Stefan

>
> Regards.
>
>