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

Roman Shpount <> Thu, 10 May 2012 16:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18F8321F8645 for <>; Thu, 10 May 2012 09:40:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.89
X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hLycdC2xEN7t for <>; Thu, 10 May 2012 09:40:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 03F0B21F84FD for <>; Thu, 10 May 2012 09:40:26 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so2232149pbc.31 for <>; Thu, 10 May 2012 09:40:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=XYBUQix3eYI5pz4IVUCdgUWaZyr8Y/NHF8kSAkQBaD0=; b=a8EssEJ++iv84XE4LfKKyWquIC2sYAcO2tqnMOhgWFi492HQ3QIIIHHzBukvrKY7V0 y5gbLzsGKcxWv9OK/Sg0PfIDJYvLs5wAYfEx1/EdcQb/l3Lz4cDX3v+6bNowfkjqA3LM 2fc5UnP/zwezk+8bSR+59zdXtjSg1L5pXjtYk6bufeC1D5Rmpld/fiFLMYxDlcuad+pE akrKYZzpK9Fypu/7y3QZIKEvnCZKme7n2QweguxAzQO8ICsO3KZt4Z4i9Qu5wk4BgNWt PlEUgtxXW/BVJF42UhiXMX+pdNORRFotp14C+3QyDKco3HqcUahlVIKHWc8/f1/vlpKs WN8w==
Received: by with SMTP id ot7mr1100995pbb.59.1336668026608; Thu, 10 May 2012 09:40:26 -0700 (PDT)
Received: from ( []) by with ESMTPS id rj4sm9978172pbc.30.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 10 May 2012 09:40:23 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so2232054pbc.31 for <>; Thu, 10 May 2012 09:40:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id tv6mr21611526pbc.153.1336668022066; Thu, 10 May 2012 09:40:22 -0700 (PDT)
Received: by with HTTP; Thu, 10 May 2012 09:40:21 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 10 May 2012 12:40:21 -0400
Message-ID: <>
From: Roman Shpount <>
To: Cullen Jennings <>
Content-Type: multipart/alternative; boundary="047d7b33d550a34e5b04bfb146c5"
X-Gm-Message-State: ALoCoQl4kp8c+6QIJ+++xa/aAu2RYXLQAuxobOJSZN//5WHz7uheS9/IbWAWxPDUkDzfYQ3h3rsh
Cc: Randell Jesup <>, "" <>
Subject: Re: [rtcweb] SDP_PRANSWER followed by SDP_OFFER scenario in JSEP
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 May 2012 16:40:28 -0000

On Thu, May 10, 2012 at 10:13 AM, Cullen Jennings <> wrote:

> On May 3, 2012, at 2:34 PM, Roman Shpount wrote:
> > On Thu, May 3, 2012 at 4:29 PM, Christer Holmberg <
>> wrote:
> > 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 initial media flow could be forced to provide only relay ICE
> candidates to help mitigate this. (I think we decided awhile back that was
> one of the things we would provide support for in the API). Later with the
> user answers or consents in same way, the ICE can move the media to a non
> relay flow.
> Just to make this clear, in this scenario, once application receives the
offer, it will generate a provisional answer with only relay candidates,
send this answer to the calling party, completes the ICE process on the
called party side, and then alert the called party. Once called user
accepts the call, application will send the final answer with relay,
reflexive and local candidates. This can also be implemented with final
answer with only relay candidates by the called party before user accepts
the the call, and O/A in the opposite direction once the call is accepted.
There is still a slight chance of clipping the media from the calling party
towards the called party since the answer might not arrive to the calling
party or ICE process from the calling party to the called party might not
complete before the called party answers. To avoid this, application will
need to send a separate message via signaling or data channel once the ICE
process on the calling side completes and only alert the called party once
this signaling message is received. What it boils down to is that
application should setup the media channel (provide relay candidates only
from the called side, if IP privacy is a concern), send a separate
signaling message when it is done, and then alert the user. This will
significantly slow down the actual call setup and will use a bunch of extra
resources, but will solve the clipping problem.
Roman Shpount