Re: [MMUSIC] ICE and RTCP host components

[Harald Alvestrand <[e-mail]>]

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".