Re: [MMUSIC] ICE and RTCP host components

Harald Alvestrand <> Sat, 24 October 2015 12:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 37AD41B33BC for <>; Sat, 24 Oct 2015 05:01:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6AcaDLSmyuhI for <>; Sat, 24 Oct 2015 05:01:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 9C49C1B33BA for <>; Sat, 24 Oct 2015 05:01:00 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 195DE7C0BCF for <>; Sat, 24 Oct 2015 14:00:59 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id S90wF5BJASCI for <>; Sat, 24 Oct 2015 14:00:58 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:1:bcbf:15b1:a4c0:94d3] (unknown [IPv6:2001:470:de0a:1:bcbf:15b1:a4c0:94d3]) by (Postfix) with ESMTPSA id 2959B7C04D5 for <>; Sat, 24 Oct 2015 14:00:58 +0200 (CEST)
References: <> <> <> <> <> <> <> <> <> <>
From: Harald Alvestrand <>
Message-ID: <>
Date: Sat, 24 Oct 2015 14:00:56 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [MMUSIC] ICE and RTCP host components
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 24 Oct 2015 12:01:03 -0000

On 10/23/2015 09:00 PM, Paul Kyzivat wrote:
> On 10/23/15 2:25 PM, Roman Shpount wrote:
>> The normal use case for ICE are large numbers of end points deployed
>> behind NAT sending media directly to each other.
> "Normal" changes over time. I think what you mean here is "current".
> As ICE becomes more mature and people understand it better, it will be
> used more broadly, for things that have legacy components.
> In any case, I think there will be much use of webrtc as one end of a
> session with the other end being a legacy sip device.
>> Deploying a lot of end
>> points without some sort of consent to send media mechanism creates a
>> perfect platform for denial of service attacks. ICE solves this issue if
>> legacy support is disabled. Furthermore, legacy end points without SDP
>> rtcp attribute support end up sending RTCP to completely wrong place.
>> Best solution for anything ICE enabled is to set c= line address to IP4
>> and provide real RTP and RTCP in ICE candidates. Legacy will not
>> work, but no traffic to unexpected destinations will be generated.
> Don't break interworking. Certainly this will require at least a
> signaling gateway. In general that will require a media gateway too.
> But anything that can be done to reduce the load on such a media
> gateway is good. It may need to do ICE. It may need to do the consent
> on behalf of the ultimate device. 
If "legacy" = "does not support ICE": Not "may". "will".

RTCWEB is designed to not start working unless ICE is present, and to
stop working if consent (which also requires ICE) isn't performed.

If the problem is "interwork with WebRTC devices", there's a class of
legacy devices that is "someone else's problem".