Re: [rtcweb] ICE does not work if both peers are behind symmetric NAT

What I meant was that RTC client should have TURN support, but should be
able to fallback to use case when only STUN server is available. In real
life TURN server might not always be available to the application developer.
TURN servers for large applications can consume a lot of bandwidth and
typically not offered as a free service. On the other hand, STUN servers a
not resource intensive at all.
_____________
Roman Shpount

On Sun, Sep 25, 2011 at 5:36 PM, Cameron Byrne <cb.list6@gmail.com> wrote:

> On Sun, Sep 25, 2011 at 2:05 PM, Roman Shpount <roman@telurix.com> wrote:
> > It is most likely not right since it assumes that different servers are
> used
> > for STUN and TURN. In real life these are the same server. We also need
> to
> > specify if TURN should be used for this call, or if we plan to use STUN
> only
> > and never proxy media. Finally we need to specify credentials to use with
> > server STUN/TURN.
> >
>
> Not creating a path for proxying media will be a real mistake.  There
> is too much NAT444, ipv6-only, and other complicated CGN work going on
> to not account for this.
>
> That said, TURN with support not only for overcoming NAT44 but also
> NAT64 should be required as defined in RFC 6156
>
> http://tools.ietf.org/html/rfc6156
>
> CB
>
>
> > One more thing that we should decide on is if we need mandate TURNS, or
> if
> > we assume that sRTP security is sufficient and TURNS is only used when
> > connection to TURN server cannot be setup. We also need to figure out how
> we
> > need to interact with proxy configuration of the browser. We can either
> > always use a proxy, use proxy as one of the ICE candidates, only use a
> proxy
> > if direct connection to TURN server is not possible.
> >
> > P.S. We should probably try to get more people with VoIP expertise
> involved
> > on W3C side, since right now it looks like they are underrepresented
> there.
> > _____________
> > Roman Shpount
> >
> >
> > On Sun, Sep 25, 2011 at 6:51 AM, Harald Alvestrand <harald@alvestrand.no
> >
> > wrote:
> >>
> >> On 09/24/2011 11:15 PM, Iñaki Baz Castillo wrote:
> >>>
> >>> 2011/9/24 Alfred E. Heggestad<aeh@db.org>:
> >>>>
> >>>> "ICE does not work" is not correct. ICE will still "work" even if both
> >>>> peers are behind NAT. the media will simply be relayed via a TURN
> >>>> server,
> >>>> and not flow directly between peers.
> >>>
> >>> Yes, that's exactly what I said in my second paragraph :)
> >>>
> >>>
> >>>> the TURN server credentials should be provisioned by the service
> >>>> provider
> >>>
> >>> And is that estandarized within rtcweb?
> >>
> >> so far, the only place where it has been mentioned is in the W3C API
> >> document, which documents how a PeerConnection is initialized with info
> on
> >> TURN / STUN servers.
> >>
> >> I think that part needs attention of a TURN expert; it doesn't look
> right
> >> to me.
> >> But I don't think anything more is needed.
> >>
> >>                Harald
> >>
> >> _______________________________________________
> >> rtcweb mailing list
> >> rtcweb@ietf.org
> >> https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
> > _______________________________________________
> > rtcweb mailing list
> > rtcweb@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtcweb
> >
> >
>