IETF Logo Mail Archive

Re: [MMUSIC] ICE and RTCP host components

Paul Kyzivat <pkyzivat@alum.mit.edu> Sat, 24 October 2015 23:22 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C60A1A87DE for <mmusic@ietfa.amsl.com>; Sat, 24 Oct 2015 16:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cf3igenK_ngh for <mmusic@ietfa.amsl.com>; Sat, 24 Oct 2015 16:22:05 -0700 (PDT)
Received: from resqmta-po-11v.sys.comcast.net (resqmta-po-11v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:170]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 561001A87DB for <mmusic@ietf.org>; Sat, 24 Oct 2015 16:22:05 -0700 (PDT)
Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-11v.sys.comcast.net with comcast id ZBMu1r0025E3ZMc01BN4Yi; Sat, 24 Oct 2015 23:22:04 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-18v.sys.comcast.net with comcast id ZBN41r0013Ge9ey01BN4on; Sat, 24 Oct 2015 23:22:04 +0000
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <7594FB04B1934943A5C02806D1A2204B37B7AC27@ESESSMB209.ericsson.se> <56266954.3080206@alum.mit.edu> <CAD5OKxtxHwjdaDnmK9LORM9M0YqQQb+-h66dV8C8Lgy8a6WYiA@mail.gmail.com> <56271989.5010509@alum.mit.edu> <CAD5OKxtW_3Ucq4X=wjhkT17tsxedc1JjEC2KYCchQF=_3uDX7g@mail.gmail.com> <562A64CF.200@alvestrand.no> <CAD5OKxvVDRFOSHB1S3Qodtqvm1Y4nSAMo41JmmsBTWw5CP=FpA@mail.gmail.com> <562A72E2.7090400@alum.mit.edu> <CAD5OKxuitU1paSGPn=wFmYG7+rWoY_tnG=u8hN7OjGnQEaVemg@mail.gmail.com> <562A83DE.4040602@alum.mit.edu> <562B72F8.2000909@alvestrand.no> <562B96CA.2090609@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B37B8CAC6@ESESSMB209.ericsson.se>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <562C129A.9030305@alum.mit.edu>
Date: Sat, 24 Oct 2015 19:22:02 -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: <7594FB04B1934943A5C02806D1A2204B37B8CAC6@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1445728924; bh=sZ0XjPvHeQ5Dmr9ul8tZwCsIgh//demqO3AIbfCcpxo=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=AjF7AVs02a+0wMym1k5tBT5XhxyLehk3eTofPvcdcEbC5Szip351IHrDVqSC1ETwo CVGQ1GgUHNPcW4+N3OZMPwKVp3CKvbB37+4qy/kF43HneU56xEIww5Aq0oqJAR8KiR d3VS/vAFfe+XYvnOB9teu9xd9Xmqji9VdQflTlE7bpcscQQ5u0UxncKl2VZ9b0n589 lRkgYuN2a2xWaXWC0oXJGdc9enBuY+3VIwDCwOEOWvk+hyD2mF1z8hMJthL3XH7/F+ 6QaaFMHXFoytdcxX/icKJYEIJfGALx15fk68BNe04UU6KdRTdml0AkotStqJ3FH2qB BZjwuCkAhP3NQ==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/5IRQsMYsIXHEMrJm8cTH7IdgRUA>
Subject: Re: [MMUSIC] ICE and RTCP host components
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Oct 2015 23:22:06 -0000

On 10/24/15 12:05 PM, Christer Holmberg wrote:
> Hi,
>
>> 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.
>
> I would not like to take that step yet. There ARE deployments that do ICE (or, at least ICE lite), but that do NOT do rtcp-mux.

Fine. Can you find another way out of this problem?

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
> 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
>>>> 0.0.0.0 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
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>

v2.23.0 | Report a Bug | By Email