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

"Ravindran Parthasarathi" <> Tue, 27 September 2011 18:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 51CBD21F8B2D for <>; Tue, 27 Sep 2011 11:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.496
X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MtaCDDXQp01Q for <>; Tue, 27 Sep 2011 11:32:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 41BD421F8A64 for <>; Tue, 27 Sep 2011 11:32:04 -0700 (PDT)
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p8RIZHXc003161; Tue, 27 Sep 2011 14:35:17 -0400
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 27 Sep 2011 14:34:34 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC7D44.18E120A9"
Date: Wed, 28 Sep 2011 00:04:29 +0530
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE forRTC calls)
Thread-Index: Acx9Jwt3HG9q88SrSzKIKQVNnduBbwAATJ/AAAXUNhA=
References: <><><><><><><><><><> <>
From: Ravindran Parthasarathi <>
To: Christer Holmberg <>, Roman Shpount <>, Harald Alvestrand <>
X-OriginalArrivalTime: 27 Sep 2011 18:34:34.0579 (UTC) FILETIME=[1AAE7230:01CC7D44]
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE forRTC 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 18:32:12 -0000

Hi Roman,


My understanding is same as Christer.  In case your aim is to interop
with PSTN gateway, Umpteen number of changes has to be done in current
RTCWeb and we may end-up in SIP with current standard for IP based
real-time interaction. IMO, ICE selection is not the only stopping
factor for PSTN interop and anyhow, you need RTCWeb server to PSTN
gateway which shall perform media gateway functionality as well. So,
Please don't reject ICE for PSTN or SIP trunk interop.  


In the another mail thread, there is a discussion that lot of operators
and Enterprise SIP implementation does not support ICE and so, RTCWeb
should support interop with non-ICE peer. The point to be noted is that
the default media destination is known in specific deployment, ICE
process shall be skipped. Lot of the deployment will not have NAT before
Customer premise Equipment and so, ICE is overhead . Also, SBC handles
NAT issue in a smarter way than ICE for few deployment.  So, ICE is not
required in lot of existing deployment. 


Depreciated STUN RFC has lot of loss end which results in the current
STUN, TURN, and ICE. Current STUN Indication may solve couple of NAT
issues but not all.


NAT and security consideration of RTCWeb forces us to look for mandating
ICE. In case you have alternative mechanism or any other technical
reason for not to mandate ICE, Please let us know.





From: [] On Behalf
Of Christer Holmberg
Sent: Tuesday, September 27, 2011 8:51 PM
To: Roman Shpount; Harald Alvestrand
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE forRTC




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.










	From: []
On Behalf Of Roman Shpount
	Sent: 27. syyskuuta 2011 18:06
	To: Harald Alvestrand
	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
	from a non-ICE peer; that target is called the DEFAULT
	If the default candidates are not selected by the ICE algorithm
	communicating with an ICE-aware peer, an updated offer/answer
will be
	required after ICE processing completes in order to "fix up" the
	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
	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
	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
<> 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

	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.
	rtcweb mailing list