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

Justin Uberti <juberti@google.com> Tue, 08 May 2012 15:10 UTC

Return-Path: <juberti@google.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 81E0E21F85C0 for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 08:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.41
X-Spam-Level:
X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.566, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 IdfBQRRAsuq3 for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 08:10:30 -0700 (PDT)
Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3F97021F85A3 for <rtcweb@ietf.org>; Tue, 8 May 2012 08:10:20 -0700 (PDT)
Received: by qcsq13 with SMTP id q13so1875810qcs.31 for <rtcweb@ietf.org>; Tue, 08 May 2012 08:10:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record; bh=32PEfjFKpsxTSMpKs5a6HU251aVkN2FQEfSjqfs+m/4=; b=AeE9vpkRckB+zgSW2ngaPb4wUmBJpR5CEik5PSJHoUoOOm1rgRiLAKYR7aXico0Qa8 onJtQTXjA6odtWBNE5yggLaLf54mi3COjrg4a0XPSO7W0B9O4ldaYWfBx6gleb0bXYk8 xocDq8lucsym44sFi6KA63v59Qgwo9252mSEVjxAk7CzsJVNfQzAnSke4xagef5EhdX5 6Y8aqMqeQjZ5g8nGmVw46BQjoE7+/C9bAfU3+Ye9hNCixTYQxXkEhrPV1I27yxIbVaRX +Lm+XLeVbYVo0ZR2cV8sHGQtOzmRbIabP7FX728lhYi2R3HC4ligOE+rUmk1+zBPVwnj r3Jg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:x-system-of-record:x-gm-message-state; bh=32PEfjFKpsxTSMpKs5a6HU251aVkN2FQEfSjqfs+m/4=; b=eENnRdFM9Y8LCNJZOqMkhjnORLsJCHtoorsghFu1bdoWhBToor6hXUM1gMAUYR+F8O Bh2iFSkp4iqtfueWMxGLsaaAXfnueaTfS5lZba1/BR85cbVTCqKw6HmbR1vxLAuQjCoa O3pb6xy2YvFf3e1Y9rTZlynldk5gJu1WmUxh/GiJlwK43Jdn1kyo0IXeEMcuQA3Wkt2a RBpTOraxEaBYWa9zTR8hiGdltgJ6WTkX8vP4x7wx1XNzWpZL2YeceP32KEUvH2EE9sOC FmkA/205ZZACnOOgXHPxZgMgUyu9P/gDuva02iV7HmnpKDb5iWPVDckN/zc0r81MBO1h 3YGg==
Received: by 10.224.215.135 with SMTP id he7mr25824526qab.48.1336489819691; Tue, 08 May 2012 08:10:19 -0700 (PDT)
Received: by 10.224.215.135 with SMTP id he7mr25824504qab.48.1336489819565; Tue, 08 May 2012 08:10:19 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.229.217.129 with HTTP; Tue, 8 May 2012 08:09:58 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se>
References: <387F9047F55E8C42850AD6B3A7A03C6C0E23B102@inba-mail01.sonusnet.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> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.ericsson.se> <4FA2E264.4040207@jesup.org> <CAD5OKxs3AqvbookWYPDgOuAkjPZGVUdSEhqz6P_p9E4h_ZHJGQ@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001338@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxuq14_DfSJuFEHq_ZEubbOYt7NFTcXWpLND8ggAr37QhA@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C44001339@ESESSCMS0356.eemea.ericsson.se> <CAD5OKxvFYy-9XAE5GG0n58xX2HKRX3o5qkTZ2o6rugakaM77Ew@mail.gmail.com> <7F2072F1E0DE894DA4B517B93C6A05852C4400133A@ESESSCMS0356.eemea.ericsson.se>
From: Justin Uberti <juberti@google.com>
Date: Tue, 8 May 2012 11:09:58 -0400
Message-ID: <CAOJ7v-1Ue=q4MAh0csiDLvRFfMGaJ4vWrDxhir-S-OjSTsymaw@mail.gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=20cf300513f6f0f06604bf87c89e
X-System-Of-Record: true
X-Gm-Message-State: ALoCoQkS9qw1BNshBOn1aJxd3bEjEqt7w8Phl7k1hlFNKgNSlslRqPZEHeBWVq4Dk68Z6izQKnaib2JMsE8l/jqiQA6hjofFXkRxPNI8eKcskHHGZJ/NRWeY6BNOjAV0MgL/ReiNhCru
Cc: Randell Jesup <randell-ietf@jesup.org>, "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: Tue, 08 May 2012 15:10:31 -0000

The conclusion on this thread seems to be that the right way to address
this problem is via PeerConnection cloning, and that no changes are needed
to the JSEP state machine. I'll work with Richard to figure out how we
should extend JSEP to support cloning.

On Thu, May 3, 2012 at 5:16 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> Hi,
>
> >>>>You could also choose not to alert the remote user until the ICE
> procedures have finished - more or less using ICE with preconditions.
> >>>>
> >>>> Of course, that is going to trigger actions in STUN/TURN servers,
> even if the called party won't accept the call, but at least from a user
> >>>> experience perspective that is still better than lifting the hook,
> and having to wait for whatever-time-it-takes-for-ICE-to-finish seconds
> before one can start to talk.
> >>>
> >>> This also has a downside of disclosing user's IP to the caller without
> the user confirmation. For a lot of applications this can be serious
> security flaw.
> >>
> >> The client can still log when ICE procedures occur.
> >>
> >> Because, even if I wait until your phone starts to ring, most likely I
> would still get your IP address without user confirmation (speaking in SIP
> terms, phones normally don't ask for user permission before they send 18x
> with SDP), eventhough you would easier be made aware of that it happens.
> >
> > Another alternative is of course to do ICE with an SBC, and/or having an
> SBC doing ICE on behalf of you :)
> >
> >
> > This is true for SIP but was as far as I know was specifically designed
> around in WebRTC. WebRTC signaling server acts as B2BUA so any type of
> ringing notification goes through the web server and does not need to carry
> any type of client address information. The client address information is
> only provided
> > when SDP answer is sent or ICE negotiation is started.
>
> Assuming you are only going to make user confirmation (read: accept calls)
> in cases where you absolutely sure that the caller isn't someone trying to
> get your IP address.
>
> But, never the less, having a solution where I first have to give user
> confirmation, and then wait until I can start to talk, is probably
> something most people want to avoid. Depending upon, of course, how long
> the waiting time is.
>
> Regards,
>
> Christer
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>