IETF Logo Mail Archive

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

Roman Shpount <roman@telurix.com> Wed, 02 May 2012 15:40 UTC

Return-Path: <roman@telurix.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 A58D421F842E for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 08:40:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.801
X-Spam-Level:
X-Spam-Status: No, score=-2.801 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 E8-LJqn7hAaa for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 08:40:13 -0700 (PDT)
Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6E18721F8566 for <rtcweb@ietf.org>; Wed, 2 May 2012 08:40:13 -0700 (PDT)
Received: by wibhj6 with SMTP id hj6so3901376wib.13 for <rtcweb@ietf.org>; Wed, 02 May 2012 08:40:12 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=h8HRbKa2yRZTnVxqOsBMjLml7/BSTvRl9K3unnowcVU=; b=GjUkkOeF0lHSTUax+Gycix/RUBgsDjHr5QqpAvwITY/HjERXX08ig0Y+O1u9z1GGGC u7R1A6g1yVgNbHeUsvsHItzpWWQATSBWuCrGKqKQSL6XAXB69RNu2tKOX2UUKYtr1Vps 8J+h7p3d5014znCow0oedBqRPr84RqoGGb3vowRhY6VzVQFGOx4hziuIiRBSdT42DlVb b5cFmLlbFe04ObSYxao9kVwH/L180VqGuI0BUfTMRYVnwygPIR8fb4PoNJSOqCrIQWBh j2+1nIJa7Yw2OV8qc1KbI1hHkwVEX05ugvOBTw+zw2n2tvYh+Xlve3lCNGn+T80QQvBh Ej9Q==
Received: by 10.180.101.8 with SMTP id fc8mr15389718wib.12.1335973212560; Wed, 02 May 2012 08:40:12 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by mx.google.com with ESMTPS id o2sm7676200wiv.11.2012.05.02.08.40.10 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 02 May 2012 08:40:11 -0700 (PDT)
Received: by bkty8 with SMTP id y8so720700bkt.31 for <rtcweb@ietf.org>; Wed, 02 May 2012 08:40:09 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.204.153.21 with SMTP id i21mr4125645bkw.38.1335973209512; Wed, 02 May 2012 08:40:09 -0700 (PDT)
Received: by 10.205.117.146 with HTTP; Wed, 2 May 2012 08:40:09 -0700 (PDT)
In-Reply-To: <4FA13816.6050003@alvestrand.no>
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>
Date: Wed, 02 May 2012 11:40:09 -0400
Message-ID: <CAD5OKxsOAeTRdCgj2g4BY8maeG1n9nzCv29g8kaFPVZ4tf8C5w@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: multipart/alternative; boundary="0015175cd100951a0004bf0f808e"
X-Gm-Message-State: ALoCoQmjTVn/M+M19Au/eIiEK9NnBR0mBsjjjIuyQd19coHPolEMFNsUT7CEMutmkrMgWVXNQYP8
Cc: 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 15:40:14 -0000

On Wed, May 2, 2012 at 9:35 AM, Harald Alvestrand <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.

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.
_____________
Roman Shpount

v2.23.0 | Report a Bug | By Email