IETF Logo Mail Archive

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

Christer Holmberg <christer.holmberg@ericsson.com> Wed, 02 May 2012 16:31 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 CC58411E8088 for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 09:31:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.116
X-Spam-Level:
X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, 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 smHRPZlyQlCk for <rtcweb@ietfa.amsl.com>; Wed, 2 May 2012 09:31:47 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A68411E808C for <rtcweb@ietf.org>; Wed, 2 May 2012 09:31:46 -0700 (PDT)
X-AuditID: c1b4fb2d-b7b76ae0000063d8-67-4fa1616bc5cb
Authentication-Results: mailgw1.ericsson.se x-tls.subject="/CN=esessmw0191"; auth=fail (cipher=AES128-SHA)
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client CN "esessmw0191", Issuer "esessmw0191" (not verified)) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 81.69.25560.C6161AF4; Wed, 2 May 2012 18:31:40 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0191.eemea.ericsson.se ([153.88.115.84]) with mapi; Wed, 2 May 2012 18:31:39 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Date: Wed, 02 May 2012 18:28:32 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0ogHSgvJMuob7cRgKJl8G8+8zPnAAACjMA
Message-ID: <7F2072F1E0DE894DA4B517B93C6A05852C4400132C@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> <7F2072F1E0DE894DA4B517B93C6A05852C44001329@ESESSCMS0356.eemea.ericsson.se>, <CAD5OKxsbTSpMPg30P4DSN6UasCx6na43tpZ5yT2ct6SLMpd9xQ@mail.gmail.com>
In-Reply-To: <CAD5OKxsbTSpMPg30P4DSN6UasCx6na43tpZ5yT2ct6SLMpd9xQ@mail.gmail.com>
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==
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:31:47 -0000

Hi,

>> 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)?
>
> I never thought that was enough if we are to interop with anything that support forking. Latest example from > Partha shows that this is indeed the case.
>
> I actually think that adding support for forking is trivial (order of magnitude less complcated then DTLS-
> SRTP or identity) and would simplify interop as well as enable numerous additional calling scenarios.

It's not about forking as such - I also agree we need to support that.

The question is whether we need to *simultanously* need to support multiple remote locations, or whether we only have one "active" remote location, but we allow switching from one to another (based on where the previous answer can from, or whatever policy).

Regards,

Christer

v2.27.8 | Report a Bug | By Email | System Status