Re: [rtcweb] New version of use-case draft uploaded

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

Hi Stefan,

<snip> > "Note that ICE support being mandatory does not preclude a WebRTC
> endpoint from supporting more traversal mechanisms than ICE using STUN
> and TURN."
> 
> OK?
</snip>

OK for me.

Thanks
Partha

> -----Original Message-----
> From: Stefan Håkansson LK [mailto:[e-mail]]
> Sent: Tuesday, February 11, 2014 3:46 PM
> To: Magnus Westerlund; Parthasarathi R; [e-mail]
> Subject: Re: [rtcweb] New version of use-case draft uploaded
> 
> On 2014-02-10 12:02, Magnus Westerlund wrote:
> > Hi Partha,
> >
> > See inline
> >
> > On 2014-02-08 10:12, Parthasarathi R wrote:
> >> Hi Stefan,
> >>
> >> <snip>
> >>> Yes, I did that change (TURN -> ICE). My understanding was that ICE
> is
> >>> what is used/mandated (and it in turn makes use of STUN and TURN).
> >>>
> >> </snip>
> >>
> >> ICE is mandated in RTCWeb but I disagree to your assumption that ICE
> in turn
> >> makes use of TURN. My concern is that The requirement document is
> misleading
> >> about TURN requirements. ICE-TCP avoids TURN server as the middle-
> box in the
> >> network. ICE-TCP is host candidate whereas TURN is relay candidate
> and as
> >> per ICE candidate selection, host candidate is preferred over relay
> >> candidates.
> >
> > I will agree that the note as currently worded is not completely
> > accurate and clear. Based on the text in the preceding section, it
> makes
> > sense to note that ICE using STUN and TURN is not the only solution
> > including additional ICE modes or relay services. I request the
> authors
> > propose a new formulation of the note.
> 
> Proposal:
> 
> "Note that ICE support being mandatory does not preclude a WebRTC
> endpoint from supporting more traversal mechanisms than ICE using STUN
> and TURN."
> 
> OK?
> 
> =