IETF Logo Mail Archive

Re: [MMUSIC] ICE and RTCP host components

Christer Holmberg <christer.holmberg@ericsson.com> Sat, 24 October 2015 16:05 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 574771A1BE9 for <mmusic@ietfa.amsl.com>; Sat, 24 Oct 2015 09:05:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
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 j0j4v10pTTlP for <mmusic@ietfa.amsl.com>; Sat, 24 Oct 2015 09:05:32 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6DED1A1BE6 for <mmusic@ietf.org>; Sat, 24 Oct 2015 09:05:31 -0700 (PDT)
X-AuditID: c1b4fb2d-f79626d000004282-c0-562bac49a4a9
Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.125]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.96.17026.94CAB265; Sat, 24 Oct 2015 18:05:29 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.61]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Sat, 24 Oct 2015 18:05:29 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] ICE and RTCP host components
Thread-Index: AdELMspQZuqUGadKR+G+TYSjfMsEiQAD2YwAAAOWggAAFqtCgAAzaz0AAEo9F4AAARHigAABBwEAAAa9xZYAH2sjAAAFVm8AAAdGd4A=
Date: Sat, 24 Oct 2015 16:05:28 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B37B8CAC6@ESESSMB209.ericsson.se>
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>
In-Reply-To: <562B96CA.2090609@alum.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.150]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM+Jvra7nGu0wg4UflS2mLn/MYrFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj38G4gsUiFSufzWdrYFwl0MXIySEhYCJx um8tO4QtJnHh3nq2LkYuDiGBo4wS879dY4FwFjNKzDz1EMjh4GATsJDo/qcN0iAi4Cvx7PFt NhBbWMBIYtqlP0wQcWOJfYeeskLYZRJz1iwCW8AioCrx6etHsBpeoN7WRX8ZIeZfZpFY8roF rIFTQEdi7rJ+sCJGoIu+n1oDZjMLiEvcejKfCeJSAYkle84zQ9iiEi8f/2OFsJUkVmy/xAhR ryOxYPcnNghbW2LZwtfMEIsFJU7OfMIygVF0FpKxs5C0zELSMgtJywJGllWMosWpxcW56UbG eqlFmcnFxfl5enmpJZsYgXFycMtv3R2Mq187HmIU4GBU4uF9sFYrTIg1say4MvcQowQHs5II 7/IF2mFCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeVuYHoQKCaQnlqRmp6YWpBbBZJk4OKUaGKfJ yb/YedJilZvT7pDXl/0OxzlcbTJQvic6hefX4il2vOfzzOfWTZrhWrOVS9744cssm2v3p6w1 PWpi+bgv+5Cri8zsWdL1iesFA9bkBrZnfJp41/Ml+/Izz7+IXZU9rKl35Wm9kZLeTEeWvsn+ f+cLVfo17jgSY/7GWvhJztve54tny3Y+favEUpyRaKjFXFScCABHx3kyjwIAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/Wg2iSGUTKRU52AyhS7sLnWJ7cDc>
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 16:05:34 -0000

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.

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