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

Roman Shpount <roman@telurix.com> Thu, 03 May 2012 21:01 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 D353521F86AB for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 14:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.87
X-Spam-Level:
X-Spam-Status: No, score=-2.87 tagged_above=-999 required=5 tests=[AWL=0.106, 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 hsFofgBmE-nN for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 14:01:54 -0700 (PDT)
Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0CB21F86A8 for <rtcweb@ietf.org>; Thu, 3 May 2012 14:01:54 -0700 (PDT)
Received: by dadz9 with SMTP id z9so2971587dad.39 for <rtcweb@ietf.org>; Thu, 03 May 2012 14:01:54 -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=Bf66hbtP1DgWr+RGJ6PzToA4fPcPZQhbY7WN1LOfKc8=; b=XZArQsfjxAc98/3V1bdlciN8zjTagyd/8Uk6G9j7JPt6/lKpXJDtS34QzDLvnKXqiI 4nJ6ccQrlgC2PjCIFXWn8TSTjCk8inqW8GbC30QmuPz0q4b1C99h3oeOugQmOOE4bf/o YAAPhfCOUQDzsAOEdTjnFLcAqU71yNG2yb9BauiQ/KDtCaAT1jhUQ5wiojUoHFzks1iK 4qo6S4pN2riVzlfrMSnaF7R67kvC8LeihTkskdpPObo37C8OxsmHLVDK2O5eCUJIz5+s EY0GN1mQaOjGaOBcGIoK0EDRVIxSai1+jFpgklCBJZ4/fbEHsLzLmZWO47OcBB6os35v nR/A==
Received: by 10.68.221.10 with SMTP id qa10mr11253064pbc.139.1336078914013; Thu, 03 May 2012 14:01:54 -0700 (PDT)
Received: from mail-pz0-f52.google.com (mail-pz0-f52.google.com [209.85.210.52]) by mx.google.com with ESMTPS id vd5sm1033873pbc.34.2012.05.03.14.01.52 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 14:01:53 -0700 (PDT)
Received: by dadz9 with SMTP id z9so2971532dad.39 for <rtcweb@ietf.org>; Thu, 03 May 2012 14:01:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.68.224.195 with SMTP id re3mr988902pbc.90.1336078912327; Thu, 03 May 2012 14:01:52 -0700 (PDT)
Received: by 10.68.134.168 with HTTP; Thu, 3 May 2012 14:01:52 -0700 (PDT)
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852C44001339@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>
Date: Thu, 3 May 2012 17:01:52 -0400
Message-ID: <CAD5OKxvFYy-9XAE5GG0n58xX2HKRX3o5qkTZ2o6rugakaM77Ew@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary=e89a8ff24a9bf60e3e04bf281c1b
X-Gm-Message-State: ALoCoQmQU7omtfo2QfBYd9542wrjoyBFqsziwMC6dn0tpKa+/69oG55mm5ZSPX/4Ok9XPBXX0p6N
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: Thu, 03 May 2012 21:01:54 -0000

On Thu, May 3, 2012 at 4:50 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.
_____________
Roman Shpount