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

Roman Shpount <> Thu, 03 May 2012 20:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3FFB21F8549 for <>; Thu, 3 May 2012 13:26:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.863
X-Spam-Status: No, score=-2.863 tagged_above=-999 required=5 tests=[AWL=0.113, 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 XVkLPUxUB6kT for <>; Thu, 3 May 2012 13:26:28 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4B5B021F853E for <>; Thu, 3 May 2012 13:26:28 -0700 (PDT)
Received: by dadz9 with SMTP id z9so2908025dad.39 for <>; Thu, 03 May 2012 13:26:28 -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=sL2m8kbY5ixv1G5l9woJuTdyXvblcS9Xmkpr6rySPnc=; b=hnAs0mBrgYxFA8csuuE81V4/bPOm2dcpJvuhBT/k2vOMDJqr3GK/BwCFdS7Si5dZQD SPLjT+GsaI8XumbMRQt3UoH3ucxJXSaE/bve3aNT03vSE5KtjpnfQeaKkuk3fbE/uXxS 6SmY9C9cW9EIIkgPofTz+z0xPmgo2obh7QolrOCrP2bKK+Qw+SSVovuF3/2gdpxh6F3y gopVEglBfXvw56trGdoC+YA5WWN0v5PjXHOuX37vFzHBybds1DWk93Ps1weuxL9A/rxU N7D6GX34BUqSodACFbjgsek9YYc+Kh/HjmDwKgSklP5ZfEukTfbuYKxedviC6Z1fG45v 2g+Q==
Received: by with SMTP id wa7mr11300970pbc.7.1336076788025; Thu, 03 May 2012 13:26:28 -0700 (PDT)
Received: from ( []) by with ESMTPS id i1sm6237300pbv.49.2012. (version=TLSv1/SSLv3 cipher=OTHER); Thu, 03 May 2012 13:26:27 -0700 (PDT)
Received: by pbcwy7 with SMTP id wy7so3002720pbc.31 for <>; Thu, 03 May 2012 13:26:25 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id vm5mr8879975pbc.132.1336076785925; Thu, 03 May 2012 13:26:25 -0700 (PDT)
Received: by with HTTP; Thu, 3 May 2012 13:26:25 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 03 May 2012 16:26:25 -0400
Message-ID: <>
From: Roman Shpount <>
To: Randell Jesup <>
Content-Type: multipart/alternative; boundary="047d7b3392e937c06604bf279e6a"
X-Gm-Message-State: ALoCoQnbqKde6FwecBUwMdf0TXEKUFL/N4jwPWjbx6bECmCBG8Dtfhtc/RlFX1tkpURFOT3o7Mf1
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, 03 May 2012 20:26:29 -0000

On Thu, May 3, 2012 at 3:54 PM, Randell Jesup <>wrote:

> Call setup delay causes clipping, unless you in some manner use feedback
> to the answerer to hold them off from talking.  The classic problem you
> probably all know is "pickup receiver, say "hello" - if call setup takes
> (or media is clipped by) more than a couple hundred ms, the clipping is
> audible to the caller.  And it gets worse (100ms or perhaps even less) for
> "click-to-answer".  The only thing to help you there is possible visual
> indication that it's not connected yet to encourage the answerer to wait
> before talking, and in some uses that's not possible or isn't sufficiently
> obvious.  (audio-only connections, especially in a context where you're
> paying attention to other things as well (game, VR conference, etc)).

Unfortunately this is unavoidable with ICE. Once you have ICE setup enabled
you normally end up with at least a RTT delay. If this is a call from east
to west coast in US, this typically means that about 100 ms worth of media
is clipped (pretty much means no initial hello). If you add DTLS setup on
top of this, you end up with more then half a second worth of audio
clipped, so this typically means people saying hello several times to see
if there is a person on the other side. All of this for the calls in
continental US. If you are talking to somebody over a satellite link,
situation is much worse. The way I've seen dealt with this was playing some
sort of audio and media to the answering party until call is actually
connected to prevent them from speaking.
Roman Shpount