Re: [rtcweb] draft-alvestrand-one-rtp ICE usage (and multi-stream interactions)

Harald Alvestrand <harald@alvestrand.no> Fri, 26 August 2011 11:53 UTC

Return-Path: <harald@alvestrand.no>
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 77F9A21F8B33 for <rtcweb@ietfa.amsl.com>; Fri, 26 Aug 2011 04:53:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.489
X-Spam-Level:
X-Spam-Status: No, score=-106.489 tagged_above=-999 required=5 tests=[AWL=4.109, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 T47wfZmI44cq for <rtcweb@ietfa.amsl.com>; Fri, 26 Aug 2011 04:53:21 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id C727A21F8B23 for <rtcweb@ietf.org>; Fri, 26 Aug 2011 04:53:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 72C4439E119; Fri, 26 Aug 2011 13:53:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ngi6Ftx8P2ws; Fri, 26 Aug 2011 13:53:19 +0200 (CEST)
Received: from [192.168.1.54] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTPS id EB09639E03C; Fri, 26 Aug 2011 13:53:18 +0200 (CEST)
Message-ID: <4E57897B.2020500@alvestrand.no>
Date: Fri, 26 Aug 2011 13:54:35 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.18) Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
To: Bernard Aboba <bernard_aboba@hotmail.com>
References: <BLU152-W2E8C02FB7B9370169BA0193100@phx.gbl>
In-Reply-To: <BLU152-W2E8C02FB7B9370169BA0193100@phx.gbl>
Content-Type: multipart/alternative; boundary="------------050801040509070209040703"
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] draft-alvestrand-one-rtp ICE usage (and multi-stream interactions)
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, 26 Aug 2011 11:53:22 -0000

On 08/25/11 21:26, Bernard Aboba wrote:
> The ICE offerer needs to be prepared to receive media on the ports 
> indicated in the offer.  After all, it doesn't know whether the answer 
> will indicate support for TOGETHER or not.  As a result, without any 
> a-priori knowledge, it seems to me that normal behavior with respect 
> to gathering candidates and preparing to receive media should apply.  
> Once an answer is returned that indicates TOGETHER support, then the 
> offerer will know that media won't be received on the ports indicated 
> in the m-lines other than the first.
>
> In general, we'd probably like to conclude the ICE exchange as quickly 
> as possible, so that setting ports to zero in all but the first 
> m-line and then going through another offer-answer exchange is 
> probably non-optimal.
>
> One concern that hasn't been mentioned so far is the interaction of 
> TOGETHER with other multi-stream work now in progress, including CLUE 
> and draft-westerlund-avtcore-multistream-and-simulcast  .  Do we 
> understand how these might interact?

I do not know, but have sent the draft to both MMUSIC and AVTCORE, 
pointing at MMUSIC (in the absence of other advice) as the place for 
further discussion of the draft.

Magnus has been on vacation for a while, so I don't think he's seen it yet.

>
>
> Paul Kyzivat said:
>
> 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.
> (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.)
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb