Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls)

Hi,

I don't think the question is about changing the ICE spec.

You are correct in that ICE as such allows establishment of sessions with non-ICE peers, but I don't think anyone is questioning that.

The question is whether we shall specify that the browser must use "Require:ICE" (speaking in SIP terms :), in order to fulful some security requirement.

So, in my opinion we shall focus on the requirement, and whether we need to mandate the usage of some mechanism (ICE or something else) in order to solve that requirement.

...or whether the requirement should be dropped or relaxed.

Regards,

Christer

________________________________
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: 27. syyskuuta 2011 18:06
To: Harald Alvestrand
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls)

Let's see:

4.1.4. Choosing Default Candidates

A candidate is said to be default if it would be the target of media
from a non-ICE peer; that target is called the DEFAULT DESTINATION.
If the default candidates are not selected by the ICE algorithm when
communicating with an ICE-aware peer, an updated offer/answer will be
required after ICE processing completes in order to "fix up" the SDP
so that the default destination for media matches the candidates
selected by ICE. If ICE happens to select the default candidates, no
updated offer/answer is required.

An agent MUST choose a set of candidates, one for each component of
each in-use media stream, to be default.

5.1. Verifying ICE Support

If this condition is not met, the agent MUST process the SDP based on
normal RFC 3264 procedures, without using any of the ICE mechanisms
described in the remainder of this specification...

6.1. Verifying ICE Support

The logic at the offerer is identical to that of the answerer as described in Section 5.1, with the exception that an offerer would not ever generate a=ice-mismatch attributes in an SDP.

My interpretation of this always was that ICE enabled end point MUST generate an offer that will be understood by a non-ICE end point, properly process on offer from a non-ICE enabled end point, and properly process an answer from a non-ICE end point. So if we want RTC to be ICE complaint we should be able to communicate with non-ICE end points, or define a new specification.
_____________
Roman Shpount

On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand <harald@alvestrand.no<mailto:harald@alvestrand.no>> wrote:
On 09/26/11 20:48, Roman Shpount wrote:
You can determine that end point is not behind symmetric NAT using older STUN specification and list discovered IP as a default contact address in SDP, if you are not behind NAT, you can list the relayed address of the TURN server as the default address. If you do this, together with the offer that lists ICE candidates, you would be able to traverse NAT and communicate with non-ICE end points.

I think discussion in this thread is not whether ICE needs to be supported or implemented. I would say that ICE without a doubt should be supported. It is about changing ICE specification as it stands right now, and force the RTC end point only to communicate with end points that respond with ICE compliant answer and complete ICE hand shake. This is actually against the ICE specification as it is defined in RFC 5245, where answerer actually can refuse to support ICE but still establish a call.
Roman,

Which part of RFC 5245 are you referring to with this statement?

Please describe the sections you think will be invoked when an SDP OFFER contains ICE candidates, the answerer does not want to use ICE, what the OFFER and ANSWER would look like, and which section of RFC 5245 is invoked when processing the ANSWER.

Details are good.

               Harald

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb