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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 03 May 2012 18:55 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 539F421F866E for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 11:55:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.133
X-Spam-Level:
X-Spam-Status: No, score=-6.133 tagged_above=-999 required=5 tests=[AWL=0.116, 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 N9buGibPCbqa for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 11:55:50 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 92E8E21F866B for <rtcweb@ietf.org>; Thu, 3 May 2012 11:55:50 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-73-4fa2d4b4648b
Authentication-Results: mailgw7.ericsson.se x-tls.subject="/CN=esessmw0197"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0197", Issuer "esessmw0197" (not verified)) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id EA.92.26681.5B4D2AF4; Thu, 3 May 2012 20:55:49 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 3 May 2012 20:55:48 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Date: Thu, 3 May 2012 20:51:23 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0pSy9uyFZgrYh+TFeIIxIfDOFlqwAEo043
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericsson.se>
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.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> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxsbTSpMPg30P4DSN6UasCx6na43tpZ5yT2ct6SLMpd9xQ@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@ESESSCMS0356.eemea.ericsson.se> <6F428EFD2B8C2F49A2FB1317291A76C1136047B753@USNAVSXCHMBSA1.ndc.alcatel-lucent.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400132F@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxuy8_Ras3X-8tcY1qaLRTVJ-z-JuXQaf0NKaRwN_dU18Q@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C442AC0DA@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxuv7T6YrEXEeVECKbGtRg4feoRYTgvC57yqWXTBK43ypg@mail.gmail.com>, <4FA2B447.7010504@jesup.org>
In-Reply-To: <4FA2B447.7010504@jesup.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
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: Thu, 03 May 2012 18:55:51 -0000

Hi,

>>     (Another option, if we want to support parallel forking, would of
>>     course be to create a completely new PeerConnection, with a *new*
>>     local IP address:port. But, you would of course then have to provide
>>     that information to the remote peer.)
>>
>>
>> This would probably do absolutely nothing to SIP interop. And if we do
>> not need SIP interop we can live without forking (at the cost of being
>> slightly less efficient in some call setup scenarios).
>
> Ignoring SIP interop, this might work as an equivalent to cloning, but
> requiring an extra O/A exchange (and adding considerable chance of
> clipping on a second fork being activated).

Assuming you have to perform the ICE procedures anyway, I don't think it would cause clipping. It probably would cause some additinoal call setup delay, though, as you need to perform that extra O/A exchange before the ICE procedures can start.


>>     I have no strong feeling on whether we want to do cloning, but do
>>     people agree that, for a given PeerConnection, we only need to
>>     support a single remote peer (which can be modified, though)?
>>
>>
>> I think if we do cloning we will only need to support a single remote
>> peer per PeerConnection. Strictly speaking even updates due to
>> provisional responses would not be necessary, since you can always clone
>> the connection and provide a new answer to it instead.
>
> I believe that's correct.

Sure. But, that would also mean that you would have to clone the PeerConnection mid-session, if the remote entity changes.

Regards,

Christer