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

Harald Alvestrand <harald@alvestrand.no> Wed, 19 October 2011 08:21 UTC

Return-Path: <harald@alvestrand.no>
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 971CF21F848A for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 01:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.558
X-Spam-Level:
X-Spam-Status: No, score=-110.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 pUNx5QV8MkQ6 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 01:21:01 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id B1FA421F8484 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 01:21:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 68D5939E162 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 10:20:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfQAvzzhjrPf for <rtcweb@ietf.org>; Wed, 19 Oct 2011 10:20:42 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id CFE4E39E0D2 for <rtcweb@ietf.org>; Wed, 19 Oct 2011 10:20:42 +0200 (CEST)
Message-ID: <4E9E885A.1030108@alvestrand.no>
Date: Wed, 19 Oct 2011 10:20:42 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
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> <4E9E81B3.10404@ericsson.com>
In-Reply-To: <4E9E81B3.10404@ericsson.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 08:21:01 -0000

On 10/19/11 09:52, Stefan Håkansson wrote:
> 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.
Actually my current understanding is that in all cases, all video 
components of all MediaStreams would use the same RTP session, and all 
audio components of all MediaStreams would use the same RTP session.

If the TOGETHER extension (draft-alvestrand-one-rtp) or BONDING 
extension (next version of 
draft-holmberg-mmusic-sdp-multiplex-negotiation; the name changed) is 
supported, both media types would be sent across one RTP session.

The word "multiplexing" is awfully confusing; at least Holmberg and I 
have concluded that it's better for communication if we don't use it.
>
> 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.
With a caveat  ....

note that the parameters passed to the constructor of PeerConnection 
(STUN/TURN server) will affect the candidate sets, so if those change, 
the cached candidates cannot be used.

>
> 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
>>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>