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

"Ravindran, Parthasarathi" <pravindran@sonusnet.com> Wed, 09 May 2012 06:34 UTC

Return-Path: <pravindran@sonusnet.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 DE85521F85D1 for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 23:34:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.521
X-Spam-Level:
X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 LSJ-FBqnVyFW for <rtcweb@ietfa.amsl.com>; Tue, 8 May 2012 23:34:46 -0700 (PDT)
Received: from na3sys010aog101.obsmtp.com (na3sys010aog101.obsmtp.com [74.125.245.70]) by ietfa.amsl.com (Postfix) with ESMTP id AC6D921F85D2 for <rtcweb@ietf.org>; Tue, 8 May 2012 23:34:39 -0700 (PDT)
Received: from USMA-EX-HUB2.sonusnet.com ([69.147.176.212]) (using TLSv1) by na3sys010aob101.postini.com ([74.125.244.12]) with SMTP ID DSNKT6oP/3DK1ivgG4S2pxZPquIOa6bRx0Ta@postini.com; Tue, 08 May 2012 23:34:39 PDT
Received: from INBA-HUB02.sonusnet.com (10.70.51.87) by USMA-EX-HUB2.sonusnet.com (66.203.90.17) with Microsoft SMTP Server (TLS) id 14.2.247.3; Wed, 9 May 2012 02:34:49 -0400
Received: from INBA-MAIL01.sonusnet.com ([fe80::8d0f:e4f9:a74f:3daf]) by inba-hub02.sonusnet.com ([fe80::80b9:dc60:caf7:7dfc%11]) with mapi id 14.01.0355.002; Wed, 9 May 2012 12:04:34 +0530
From: "Ravindran, Parthasarathi" <pravindran@sonusnet.com>
To: Justin Uberti <juberti@google.com>, Christer Holmberg <christer.holmberg@ericsson.com>
Thread-Topic: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
Thread-Index: Ac0mnx+EQrlVrvWDRey+KwUxgcHWewALSsOAABK1rwAAF0kPAAAxgqEAAARcP4AAAHvUAAAArGiAAAB9ngAAAAq7AAAIW/WAAAB4jQAAAR30gAASfQ4AABLNEwAAA128gAAErXWAAAIxoAAAASAKgAAAF7EAAAAvPYAAAIyrgAAAaVoAAACEBgAA7qbDAAArq6qQ
Date: Wed, 9 May 2012 06:34:33 +0000
Message-ID: <387F9047F55E8C42850AD6B3A7A03C6C160337F1@inba-mail01.sonusnet.com>
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> <CAOJ7v-1Ue=q4MAh0csiDLvRFfMGaJ4vWrDxhir-S-OjSTsymaw@mail.gmail.com>
In-Reply-To: <CAOJ7v-1Ue=q4MAh0csiDLvRFfMGaJ4vWrDxhir-S-OjSTsymaw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.70.54.99]
Content-Type: multipart/alternative; boundary="_000_387F9047F55E8C42850AD6B3A7A03C6C160337F1inbamail01sonus_"
MIME-Version: 1.0
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: Wed, 09 May 2012 06:34:47 -0000

Hi Justin,

Sorry for the delay in reply. There are two issues associated with this scenario:

Issue 1) SIP Forking : This is solved by peerconnection cloning

Issue 2)  UPDATE support within SIP early dialog in the non-forking scenario. Here, the cloning will not solve issue as the answerer originated the new offer during SDP_PRANSWER state . Issue 2 is the title of this mail thread.

IMO, SDP_PRANSWER will complicate the offer/answer state machine.

Thanks
Partha



From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Justin Uberti
Sent: Tuesday, May 08, 2012 8:40 PM
To: Christer Holmberg
Cc: Randell Jesup; rtcweb@ietf.org
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP

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<mailto: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<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb