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

Roman Shpount <> Tue, 27 September 2011 15:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58BF921F8E3D for <>; Tue, 27 Sep 2011 08:03:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.827
X-Spam-Status: No, score=-1.827 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Zlrji05rlGVE for <>; Tue, 27 Sep 2011 08:03:43 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8382F21F8DF8 for <>; Tue, 27 Sep 2011 08:03:43 -0700 (PDT)
Received: by yxt33 with SMTP id 33so6738569yxt.31 for <>; Tue, 27 Sep 2011 08:06:28 -0700 (PDT)
Received: by with SMTP id o65mr7566830yhk.73.1317135988666; Tue, 27 Sep 2011 08:06:28 -0700 (PDT)
Received: from ( []) by with ESMTPS id z15sm34030807yhg.21.2011. (version=TLSv1/SSLv3 cipher=OTHER); Tue, 27 Sep 2011 08:06:26 -0700 (PDT)
Received: by ywa6 with SMTP id 6so6753159ywa.31 for <>; Tue, 27 Sep 2011 08:06:26 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id c9mr37131799pbf.88.1317135986166; Tue, 27 Sep 2011 08:06:26 -0700 (PDT)
Received: by with HTTP; Tue, 27 Sep 2011 08:06:26 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Tue, 27 Sep 2011 11:06:26 -0400
Message-ID: <>
From: Roman Shpount <>
To: Harald Alvestrand <>
Content-Type: multipart/alternative; boundary="bcaec52154c5938e4504aded9edc"
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE for RTC calls)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Sep 2011 15:03:44 -0000

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
Roman Shpount

On Tue, Sep 27, 2011 at 4:14 AM, Harald Alvestrand <>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