Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 02 May 2012 16:17 UTC

Return-Path: <christer.holmberg@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 6FE2621E802D for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 09:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.112
X-Spam-Level:
X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 e1e-rhjnLOLe for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 09:17:48 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 752C921E802A for <rtcweb@ietf.org>; Wed, 2 May 2012 09:17:48 -0700 (PDT)
X-AuditID: c1b4fb25-b7b18ae000000dce-18-4fa15e2b74fd
Authentication-Results: mailgw2.ericsson.se x-tls.subject="/CN=esessmw0184"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0184", Issuer "esessmw0184" (not verified)) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 82.FA.03534.B2E51AF4; Wed, 2 May 2012 18:17:47 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0184.eemea.ericsson.se ([10.2.3.53]) with mapi; Wed, 2 May 2012 18:17:47 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Harald Alvestrand <harald@alvestrand.no>, Roman Shpount <roman@telurix.com>
Date: Wed, 2 May 2012 18:13:17 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0oe85kMh7Ss+MlQNqivaIPuZ50agAAq2+j
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se>
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.com> <CA+rAfUMfZBHxAjR0zmwhSxftQbPK0X3sNuxu4UV6bnMvnJ_9xA@mail.gmail.com> <CAOJ7v-3K=NK6zCLr-E-aSHDKVv2hMqnUhZKroX0YoBTo6-nQ+Q@mail.gmail.com> <6F428EFD2B8C2F49A2FB1317291A76C1136029362A@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <4FA13816.6050003@alvestrand.no> <CAD5OKxsOAeTRdCgj2g4BY8maeG1n9nzCv29g8kaFPVZ4tf8C5w@mail.gmail.com>, <4FA15898.1040204@alvestrand.no>
In-Reply-To: <4FA15898.1040204@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
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, 02 May 2012 16:17:49 -0000

Hi,

I thought that we had more or less agreed on the fact that, eventhough we would support forking, we would only support one "active" remote location - and typically that would be the location from where you got the previous answer.

So, if you receive an answer from R1, that becomes "active". Then, if you receive an answer from R2, that becomes "active".

Then, if you receive an UPDATE from R1, you would reject it, since R2 is "active".

...or, alternatively you could switch back to R1, and accept the UPDATE. That is implementation dependent, and nothing we need to specify.

Do people think that is not enough, and that we would need to support multiple remote locations simultanously (no matter whether it's implemented using cloning or something else)?

Regards,

Christer



________________________________
From: rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand [harald@alvestrand.no]
Sent: Wednesday, May 02, 2012 6:54 PM
To: Roman Shpount
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

On 05/02/2012 05:40 PM, Roman Shpount wrote:

On Wed, May 2, 2012 at 9:35 AM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:
Especially, I am worried about what the state of the peerconnection has to be before it is cloned, what the state of the peerconnection is after it is cloned, which peerconnection owns the various resources allocated (ports are the obvious part of it), and which peerconnection any streams (local or remote) attached to the peerconnection before the clone are attached to after the clone.


I thought there was a discussion on this list about using the same set of ports, ICE candidates and turn connection across multiple peerconnections. I am actually curious if there is ever a down side of using the same set of ICE candidates for all the streams within the all peerconnections for a given web session. It should be possible to disambiguate those streams based on remote IP/port and SSRC.
It does mean that the implementation will have to do reference counting to know when it can close the port - if one clones the socket and binds the clones to different remote ports, I think the OS will take care of it on Unix, I'm not sure how it goes for other OSes.

Does someone know what the semantic of bind() is here - whether one needs to have an unbound port to fork from in order to bind to different remote addresses? I've not tried this myself.

In the case of hardware codecs that must be allocated to a specific stream .... if one supports forking, which connection (if any) gets the codec? The first one to start using it? What happens to the second one?


The state that must to be replicated with the peerconnection is the latest offer information. It would probably be less disruptive if peerconnection has some sort of clone method instead of using a factory. It should be possible to clone the connection between the time offer is generated and the final answer is received.
I kind of think it's less disruptive to the people who don't want to fork stuff if you must instantiate a different object in order to support forking. Then implementations that don't support forking can simply not offer a constructor for that object.