Re: [MMUSIC] ICE and RTCP host components

Paul Kyzivat <> Sat, 24 October 2015 14:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5665F1B3662 for <>; Sat, 24 Oct 2015 07:33:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.635
X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, J_CHICKENPOX_14=0.6, SPF_SOFTFAIL=0.665] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sgVZT6ZC2GRo for <>; Sat, 24 Oct 2015 07:33:48 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:37]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD0A61B3661 for <>; Sat, 24 Oct 2015 07:33:47 -0700 (PDT)
Received: from ([]) by with comcast id Z2Z51r0032N9P4d012ZnZ5; Sat, 24 Oct 2015 14:33:47 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id Z2Zm1r00M3Ge9ey012ZmLB; Sat, 24 Oct 2015 14:33:47 +0000
References: <> <> <> <> <> <> <> <> <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Sat, 24 Oct 2015 10:33:46 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1445697227; bh=vO2KVmFgKbsBxsv3LKXLShe8s5Vb9tLv7RxfgFI+JfU=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=uRErhDEYeAnYoyGfOXTqzB2RN894BrJICF1GzDMG+teQ9XbKdFkp65xMkqSAklomq hIkbcs4eHPvyUGCyEUo/PAU9mPQH0YSK2UPN+ifz39mLBojdZd6znMaIpUwqZmFTl+ OkMe1pB29d0Z7boYwRg3OLZl1CfgagpsJ+Ky8xABjCzp5TKZKbpxHTAtAeyh0ykTGl SYli0XRooDh4PJWQizfrgpnZsHDaMc+R7rhHCvEg0DolClD0BIwO7fBmiX7QsoNYqu ehAM+RD3MXmV1iRY1PdifmO/oL7bZRVaZYfQduRhxD/xsd7nje39RDLL/iI3bb5tyR ZQ3/B7u2qTIxg==
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 14:33:50 -0000

Note that on a separate thread we are concluding that if you do bundle 
you must to rtcp-mux.

If we don't already have a problem with legacy ICE, I think it might 
also make sense to require that if you do ICE you must to rtcp-mux.

For compatibility with non-ICE, it would be ok to offer ICE and and 
rtp-mux, or ICE and a=rtcp, as fallbacks for answers that refuse ICE.

I think that would provide as much legacy compatibility as is feasible.


On 10/24/15 8:00 AM, Harald Alvestrand wrote:
> 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".
> _______________________________________________
> mmusic mailing list