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> Wed, 19 October 2011 10:05 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 A6C0421F8B67 for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 03:05:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.199
X-Spam-Level:
X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.100, 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 3v2-FYKEJwWt for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 03:05:04 -0700 (PDT)
Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by ietfa.amsl.com (Postfix) with ESMTP id CDA8121F8B5C for <rtcweb@ietf.org>; Wed, 19 Oct 2011 03:05:03 -0700 (PDT)
X-AuditID: c1b4fb39-b7bfdae000005125-4e-4e9ea0cec499
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id EA.7B.20773.EC0AE9E4; Wed, 19 Oct 2011 12:05:02 +0200 (CEST)
Received: from [150.132.142.226] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.137.0; Wed, 19 Oct 2011 12:05:02 +0200
Message-ID: <4E9EA0CE.3020205@ericsson.com>
Date: Wed, 19 Oct 2011 12:05:02 +0200
From: =?ISO-8859-1?Q?Stefan_H=E5kansson_LK?= <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: 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> <4E9E885A.1030108@alvestrand.no>
In-Reply-To: <4E9E885A.1030108@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
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 10:05:04 -0000

On 10/19/2011 10:20 AM, Harald Alvestrand wrote:
> 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.

That's right.

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