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

Randell Jesup <> Thu, 03 May 2012 19:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F316221F85FD for <>; Thu, 3 May 2012 12:55:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.335
X-Spam-Status: No, score=-2.335 tagged_above=-999 required=5 tests=[AWL=0.264, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ZhKmbPFjDI48 for <>; Thu, 3 May 2012 12:55:16 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 589AC21F851B for <>; Thu, 3 May 2012 12:55:16 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1SQ27P-0001pR-RQ for; Thu, 03 May 2012 14:55:15 -0500
Message-ID: <>
Date: Thu, 03 May 2012 15:54:12 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120420 Thunderbird/12.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <> <> <> <> <> <>, <> <7F2072F1E0DE894DA4B517B93C6A05852C44001337@ESESSCMS0356.eemea.erics>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
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 19:55:17 -0000

On 5/3/2012 2:51 PM, Christer Holmberg wrote:
>>>      (Another option, if we want to support parallel forking, would of
>>>      course be to create a completely new PeerConnection, with a *new*
>>>      local IP address:port. But, you would of course then have to provide
>>>      that information to the remote peer.)
>>> This would probably do absolutely nothing to SIP interop. And if we do
>>> not need SIP interop we can live without forking (at the cost of being
>>> slightly less efficient in some call setup scenarios).
>> Ignoring SIP interop, this might work as an equivalent to cloning, but
>> requiring an extra O/A exchange (and adding considerable chance of
>> clipping on a second fork being activated).
> Assuming you have to perform the ICE procedures anyway, I don't think it would cause clipping. It probably would cause some additinoal call setup delay, though, as you need to perform that extra O/A exchange before the ICE procedures can start.

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

Randell Jesup