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

Harald Alvestrand <harald@alvestrand.no> Tue, 27 September 2011 08:12 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 4634A21F85EF for <rtcweb@ietfa.amsl.com>; Tue, 27 Sep 2011 01:12:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.938
X-Spam-Status: No, score=-108.938 tagged_above=-999 required=5 tests=[AWL=1.661, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id q4PUrCk4yslA for <rtcweb@ietfa.amsl.com>; Tue, 27 Sep 2011 01:12:08 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no []) by ietfa.amsl.com (Postfix) with ESMTP id 947BA21F84BB for <rtcweb@ietf.org>; Tue, 27 Sep 2011 01:12:08 -0700 (PDT)
Received: from localhost (localhost []) by eikenes.alvestrand.no (Postfix) with ESMTP id E36AC39E0E7 for <rtcweb@ietf.org>; Tue, 27 Sep 2011 10:14:52 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([]) by localhost (eikenes.alvestrand.no []) (amavisd-new, port 10024) with ESMTP id EsNEnA5F3k+R for <rtcweb@ietf.org>; Tue, 27 Sep 2011 10:14:52 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com []) by eikenes.alvestrand.no (Postfix) with ESMTPS id 83ABA39E051 for <rtcweb@ietf.org>; Tue, 27 Sep 2011 10:14:52 +0200 (CEST)
Message-ID: <4E8185FC.8000906@alvestrand.no>
Date: Tue, 27 Sep 2011 10:14:52 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAD5OKxtNjmWBz92bRuxka7e-BUpTPgVUvr3ahJGpmZ-U5nuPbQ@mail.gmail.com> <CAD6AjGSmz5T_F+SK2EoBQm6T-iRKp7dd4j8ZAF5JKdbbyomZQA@mail.gmail.com> <CALiegfmO54HC+g9L_DYn4jtXAAbLEvS++qxKa6TNrLDREs9SeA@mail.gmail.com> <4E80984A.903@skype.net> <CALiegfmyvTb57WVooKryS-ubfcg+w5gZ+zfO1zzBLn3609AzaA@mail.gmail.com> <4E809EE6.2050702@skype.net> <2E239D6FCD033C4BAF15F386A979BF510F1087@sonusinmail02.sonusnet.com> <CAD5OKxviJaGvA-0AW=sAxSYm8hL+t8Xgr+4Ma+QBL0HWmZf_6g@mail.gmail.com>
In-Reply-To: <CAD5OKxviJaGvA-0AW=sAxSYm8hL+t8Xgr+4Ma+QBL0HWmZf_6g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2011 08:12:09 -0000

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.

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.