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

["Ravindran Parthasarathi" <[e-mail]>]

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.

 

Thanks

Partha

 

From: [e-mail] [mailto:[e-mail]] On Behalf
Of Christer Holmberg
Sent: Tuesday, September 27, 2011 8:51 PM
To: Roman Shpount; Harald Alvestrand
Cc: [e-mail]
Subject: Re: [rtcweb] RFC 5245 interpretation (Re: Requiring ICE forRTC
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: [e-mail] [mailto:[e-mail]]
On Behalf Of Roman Shpount
	Sent: 27. syyskuuta 2011 18:06
	To: Harald Alvestrand
	Cc: [e-mail]
	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
<[e-mail]> 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
	[e-mail]
	https://www.ietf.org/mailman/listinfo/rtcweb