Re: [rtcweb] draft-alvestrand-one-rtp-00.txt ICE usage

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 12 August 2011 17:56 UTC

Return-Path: <pkyzivat@alum.mit.edu>
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 15F8A11E8080 for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 10:56:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.547
X-Spam-Level:
X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599]
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 tq3wViMXy8+I for <rtcweb@ietfa.amsl.com>; Fri, 12 Aug 2011 10:56:20 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [76.96.62.24]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBBD21F86DD for <rtcweb@ietf.org>; Fri, 12 Aug 2011 10:56:20 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta02.westchester.pa.mail.comcast.net with comcast id KVrH1h0021GhbT852Vwy9i; Fri, 12 Aug 2011 17:56:58 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta07.westchester.pa.mail.comcast.net with comcast id KVwy1h0010tdiYw3TVwyiB; Fri, 12 Aug 2011 17:56:58 +0000
Message-ID: <4E456968.7070101@alum.mit.edu>
Date: Fri, 12 Aug 2011 13:56:56 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E43BDB3.8000504@alvestrand.no> <4E4423A7.2000501@alum.mit.edu> <4E44CC15.3030004@alvestrand.no> <4E453EE9.7030102@alum.mit.edu> <4E4544C9.6010304@alvestrand.no> <4E454D5A.1080909@alum.mit.edu> <4E4565C8.9010104@jesup.org>
In-Reply-To: <4E4565C8.9010104@jesup.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] draft-alvestrand-one-rtp-00.txt ICE usage
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: Fri, 12 Aug 2011 17:56:21 -0000

On 8/12/11 1:41 PM, Randell Jesup wrote:
> On 8/12/2011 11:57 AM, Paul Kyzivat wrote:
>
>> Trimming, and changing subject
>> On 8/12/11 11:20 AM, Harald Alvestrand wrote:
>>> There are 2 possible things to do for the offerer:
>>> - Start ICE procedure on all ports when sending the offer
>>> - Wait until the answer comes back, and either start ICE procedure on
>>> one port (if the responder understood TOGETHER), or start the ICE
>>> procedure on all ports (if the responder did not understand TOGETHER)
>>> The first alternative is a number of milliseconds faster, but others
>>> should chime in on whether that's significant or not.
> 1/2 RTT is significant especially on slower/longer-distance connections,
> since I think all the other setup stuff we're talking about adds up.
> We have to make sure that we don't have the "...lo?" problem when
> answering an incoming connection. (Setup delay of more than a couple
> hundred ms causes first syllables to be lost.) It might even be worse on a
> computer if the person has a headset on or answers in speakerphone mode
> with
> a button press - you don't have the natural delay of bringing a receiver to
> face.

Note that this matters if the extra signaling happens after the callee 
answers. If it happens *before* the answer, then it just extends the 
"ring time" but doesn't cause clipping.

>> (I don't know much about ICE, so just call me on it if I say something
>> stupid)
>> IIUC, there are some aspects of ICE that MUST be done before sending the
>> offer. Specifically that involved gathering the candidate list, which
>> may involve assignment of multiple local ports, interactions with a TURN
>> server, etc. I don't think everything can be deferred until the answer
>> is received.
> Right; one assumes you've done them.
>
>> (I suppose one approach would be for the initial offer to set the port
>> to zero in all but the first m-line. Then, once the first answer is
>> received, indicating whether TOGETHER is supported, another offer can be
>> generated, using appropriate ICE based on whether using TOGETHER or not.
>> But that does start to get complex.)
> That forces a full extra RTT plus overhead... Ouch.

Again, if the extra round trip happens during "alerting" it may not be 
objectionable.

Also, if the first m-line is audio, it can get going sooner, with the 
video to follow with a slight lag.

But I agree this isn't the nicest of solutions. I'm just putting out 
some candidates to consider.

	Thanks,
	Paul