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

Stefan Håkansson <stefan.lk.hakansson@ericsson.com> Wed, 19 October 2011 07:52 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 EA16921F8B3B for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 00:52:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.179
X-Spam-Level:
X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, 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 J-u1n5mLvdGP for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 00:52:36 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id 3073F21F8B6E for <rtcweb@ietf.org>; Wed, 19 Oct 2011 00:52:36 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-de-4e9e81b4cb89
Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 50.AC.20773.4B18E9E4; Wed, 19 Oct 2011 09:52:21 +0200 (CEST)
Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 09:52:20 +0200
Message-ID: <4E9E81B3.10404@ericsson.com>
Date: Wed, 19 Oct 2011 09:52:19 +0200
From: =?ISO-8859-1?Q?Stefan_H=E5kansson?= <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: Roman Shpount <roman@telurix.com>
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> <4E9D85CB.6030503@ericsson.com> <CAD5OKxtRygfzAYviKPyDxeZGt2ajXFQHr9WGdqiR24MbC3j2Cw@mail.gmail.com>
In-Reply-To: <CAD5OKxtRygfzAYviKPyDxeZGt2ajXFQHr9WGdqiR24MbC3j2Cw@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; 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: Wed, 19 Oct 2011 07:52:37 -0000

On 10/18/2011 06:07 PM, Roman Shpount wrote:
> On Tue, Oct 18, 2011 at 9:57 AM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com
> <mailto:stefan.lk.hakansson@ericsson.com>> wrote:
>
>     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.
>
>
> What would happen if new PeerConnection has a different set of
> codecs/media streams? Do we just add/remove local candidates based on
> how many different streams are needed?

Now we're getting into the stuff that is not my home turf :). But as I 
understand it, the current assumption is that the browser would in fact 
only open one port which all RTP streams use. In most cases all streams 
would be multiplexed over the same 5-tuple, but the other end (if it is 
not a browser) could open separate ports for each RTP stream, if it 
(read legacy) would like to avoid multiplexing.

This means that when the first PeerConnection is set up it would gather 
candidates (host, srflx, ...) for one port only; my idea is that these 
candidates would be re-used if a second PeerConnection is created.

Codecs and media streams would be negotiated per PeerConnection.

I hope this is roughly right, not my home turf as said.

>
> Overall I do like this idea since it not only addresses the forking
> issue, but suggest a good resource usage policy.
> _____________
> Roman Shpount
>