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

Bernard Aboba <> Thu, 25 August 2011 19:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7DDAA21F8BE5 for <>; Thu, 25 Aug 2011 12:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.853
X-Spam-Status: No, score=-101.853 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hLSX1nZ1b2x0 for <>; Thu, 25 Aug 2011 12:24:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D74D421F8BDC for <>; Thu, 25 Aug 2011 12:24:57 -0700 (PDT)
Received: from BLU152-W2 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Aug 2011 12:26:11 -0700
Message-ID: <BLU152-W2E8C02FB7B9370169BA0193100@phx.gbl>
Content-Type: multipart/alternative; boundary="_45d92119-f67f-4b93-9e04-7ce8cf29201f_"
X-Originating-IP: []
From: Bernard Aboba <>
To: <>
Date: Thu, 25 Aug 2011 12:26:10 -0700
Importance: Normal
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Aug 2011 19:26:11.0234 (UTC) FILETIME=[D8CCC020:01CC635C]
Subject: Re: [rtcweb] draft-alvestrand-one-rtp ICE usage (and multi-stream interactions)
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, 25 Aug 2011 19:24:59 -0000

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