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

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 03 May 2012 20:50 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 7118421F8686 for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 13:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.139
X-Spam-Level:
X-Spam-Status: No, score=-6.139 tagged_above=-999 required=5 tests=[AWL=0.110, 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 Dzemd6y5pqmm for <rtcweb@ietfa.amsl.com>; Thu, 3 May 2012 13:50:08 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B2A1121F8675 for <rtcweb@ietf.org>; Thu, 3 May 2012 13:50:07 -0700 (PDT)
X-AuditID: c1b4fb30-b7b07ae000006839-ab-4fa2ef7e78ef
Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 64.D8.26681.E7FE2AF4; Thu, 3 May 2012 22:50:06 +0200 (CEST)
Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.64]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Thu, 3 May 2012 22:50:06 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Roman Shpount <roman@telurix.com>
Date: Thu, 03 May 2012 22:50:05 +0200
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0pbCCcBZjsQCL4S7el2wpWmQIS2gAAMpdN
Message-ID: <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>
In-Reply-To: <CAD5OKxuq14_DfSJuFEHq_ZEubbOYt7NFTcXWpLND8ggAr37QhA@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: 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 20:50:08 -0000

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 :)

Regards,

Christer