Subject: Re: [pntaw] Real-time media over TCP

From: Justin Uberti <[email-masked]>
Date: Fri, 8 Nov 2013 15:32:41 -0800

FWIW: we use ICE-TCP to connect to a conferencing server, instead of
TURN-TCP, to avoid the extra TURN hop and the whole TURN credentials
business. It's an optimization for sure, but a useful one.

I don't think ICE-TCP will be all that useful for P2P connectivity in the
near future. The scenarios that require ICE-TCP are the exact ones where
simultaneous open will probably be impossible.

On Sun, Oct 20, 2013 at 9:10 AM, Parthasarathi R <[email-masked]
> wrote:

> Hi Harald & all,
>
> I agree that ICE-TCP qualifies for "MAY" requirement in case both browsers
> are behind firewall. ICE-TCP is good for usecase wherein only one of the
> browsers is behind firewall. Existing WebRTC usecase namely FedEx call is
> good example for only one browser behind firewall wherein IVR is not going
> to be behind UDP blocking firewall. In those usecases, ICE-TCP candidates
> has merits over TURN relay candidates. IMO, ICE-TCP MUST be considered.
>
> The current WebRTC FW usecase is (accidentially) inline with one of the
> browser behind firewall scenario as mentioned in sec 3.3.2.1 of
> draft-ietf-rtcweb-use-cases-and-requirements-12:
>
> "The difference is that one of the users is behind a NAT that blocks UDP
> traffic."
>
> Thanks
> Partha
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf
> > Of Harald Alvestrand
> > Sent: Wednesday, October 16, 2013 5:33 PM
> > To: [email-masked]
> > Subject: Re: [pntaw] Real-time media over TCP
> >
> > On 10/15/2013 06:15 PM, Dan Wing wrote:
> > > On Oct 14, 2013, at 11:02 PM, Tirumaleswar Reddy (tireddy)
> > <[email-masked]> wrote:
> > >
> > >>> -----Original Message-----
> > >>> From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Dan
> > >>> Wing (dwing)
> > >>> Sent: Tuesday, October 15, 2013 5:31 AM
> > >>> To: [email-masked]
> > >>> Cc: [email-masked]; [email-masked]
> > >>> Subject: Re: [pntaw] Real-time media over TCP
> > >>>
> > >>>
> > >>> On Oct 14, 2013, at 12:06 PM, [email-masked] wrote:
> > >>>
> > >>>> Hi,
> > >>>>
> > >>>> In practice I doubt you find many situations where UDP is
> > completely blocked
> > >>> but incoming TCP connections from anywhere are allowed.
> > >>>
> > >>> Agreed.
> > >>>
> > >>> But if both ends are trying to communicate with each other, their
> > >>> communications will appear as a TCP simultaneous-open.  That could
> > (in fact,
> > >>> "should") work across a firewall because the firewall will see an
> > outbound SYN
> > >>> to a host/port after which it will see an inbound SYN from that
> > same
> > >>> host/port.
> > >> But firewall TCP inspection causes the inbound SYN from the same
> > host/port to be dropped (Firewalls typically do not permit TCP
> > simultaneous-open). Even with NAT as per the survey results in ICE TCP
> > (http://tools.ietf.org/html/rfc6544#appendix-A) TCP simultaneous-open
> > worked only in roughly 45% of the cases.
> > > If avoiding TURN improves the user experience, and IT policy says TCP
> > is allowed, I expect firewall vendors would make sure TCP simultaneous
> > open works.
> > >
> > >
> > If something improves the user experience if it is possible to do it,
> > but the basic functionality works without it, and it's unclear whether
> > the special circumstances under which it's going to improve the user
> > experience in fact exist in the field, I think that's perfect for a MAY
> > implement.
> >
> > _______________________________________________
> > pntaw mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/pntaw
>
> _______________________________________________
> pntaw mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pntaw
>

---

From: <[email-masked]>
Date: Fri, 8 Nov 2013 23:58:24 +0000

Hi Justin,

It’s great to hear that at least one browser will be able to do ICE-TCP. It is an optimization, but definitely a useful one for certain central server and gateway situations. I have heard also from other service/gateway providers that they want to avoid the TURN-TCP “hop” for the same reasons you state. After listening to them, I’d say ICE-TCP ought to be rather a “SHOULD” instead of “MAY” in the RTCWeb NAT traversal framework.

I suppose that when real-time media runs over TCP, it is in general best to avoid bundling, but to run the different medias over separate TCP connections. That way a single lost packet only affects the rate of one of the medias instead of the aggregate.

I wonder if you already have a plan in Chrome if and how to deal with HTTP (and TLS) restricted firewalls. Are you OK with the idea of connecting to a TURN server with HTTP CONNECT, or do you see some issues with that?

Markus

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Justin Uberti
Sent: 09 November, 2013 01:33
To: Parthasarathi R
Cc: Harald Alvestrand; [email-masked]
Subject: Re: [pntaw] Real-time media over TCP

FWIW: we use ICE-TCP to connect to a conferencing server, instead of TURN-TCP, to avoid the extra TURN hop and the whole TURN credentials business. It's an optimization for sure, but a useful one.

I don't think ICE-TCP will be all that useful for P2P connectivity in the near future. The scenarios that require ICE-TCP are the exact ones where simultaneous open will probably be impossible.

On Sun, Oct 20, 2013 at 9:10 AM, Parthasarathi R <[email-masked]<mailto:[email-masked]>> wrote:
Hi Harald & all,

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf
> Of Harald Alvestrand
> To: [email-masked]<mailto:[email-masked]>
> <[email-masked]<mailto:[email-masked]>> wrote:
> >
> >>> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
> Behalf Of Dan
> >>> Wing (dwing)
> >>> To: [email-masked]<mailto:[email-masked]>
> >>> Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
> >>> On Oct 14, 2013, at 12:06 PM, [email-masked]<mailto:[email-masked]> wrote:
> >>>
> >>>> Hi,
> >>>>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
pntaw mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/pntaw

---

From: Justin Uberti <[email-masked]>
Date: Fri, 8 Nov 2013 17:56:34 -0800

On Fri, Nov 8, 2013 at 3:58 PM, <[email-masked]> wrote:

>  Hi Justin,
>
>
>
> It’s great to hear that at least one browser will be able to do ICE-TCP.
> It is an optimization, but definitely a useful one for certain central
> server and gateway situations. I have heard also from other service/gateway
> providers that they want to avoid the TURN-TCP “hop” for the same reasons
> you state. After listening to them, I’d say ICE-TCP ought to be rather a
> “SHOULD” instead of “MAY” in the RTCWeb NAT traversal framework.
>

Sounds good.

>
>
> I suppose that when real-time media runs over TCP, it is in general best
> to avoid bundling, but to run the different medias over separate TCP
> connections. That way a single lost packet only affects the rate of one of
> the medias instead of the aggregate.
>
>
>
That is an interesting idea, but I think it is probably difficult to make
work because the BUNDLE decision happens separately from ICE candidate pair
selection.

I think what we really want is some sort of multi-TCP transport, where we
can open several simultaneous TCP connections and rotate between them. Or
maybe a Minion TCP-based approach. These would have their own issues, but
be conceptually simpler.

>  I wonder if you already have a plan in Chrome if and how to deal with
> HTTP (and TLS) restricted firewalls. Are you OK with the idea of connecting
> to a TURN server with HTTP CONNECT, or do you see some issues with that?
>

We already use HTTP CONNECT with ICE-TCP, TURN-TCP, and TURN-TLS. It works.

>
>
> Markus
>
>
>
>
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> Of *ext Justin Uberti
> *Sent:* 09 November, 2013 01:33
> *To:* Parthasarathi R
> *Cc:* Harald Alvestrand; [email-masked]
>
> *Subject:* Re: [pntaw] Real-time media over TCP
>
>
>
> On Sun, Oct 20, 2013 at 9:10 AM, Parthasarathi R <
> [email-masked]> wrote:
>
> Hi Harald & all,
>

---

From: "Parthasarathi R" <[email-masked]>
Date: Sat, 9 Nov 2013 15:25:44 +0530

Hi Justin,  Markus & all,

It is good to know that conference server usecase as well for ICE-TCP usage. I think that it is better to request for adding conference/IVR Server/Gateway with firewall usecases explicitly in the RTCWeb usecase & requirement document in case there is no other objection in this mail thread.

Thanks

Partha 

From: [email-masked] [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Saturday, November 09, 2013 7:27 AM
To: [email-masked]
Cc: Harald Tveit Alvestrand; [email-masked]; Parthasarathi R
Subject: Re: [pntaw] Real-time media over TCP

Hi Justin,

Sounds good. 

That is an interesting idea, but I think it is probably difficult to make work because the BUNDLE decision happens separately from ICE candidate pair selection.

I think what we really want is some sort of multi-TCP transport, where we can open several simultaneous TCP connections and rotate between them. Or maybe a Minion TCP-based approach. These would have their own issues, but be conceptually simpler.

Markus 

On Sun, Oct 20, 2013 at 9:10 AM, Parthasarathi R <[email-masked]> wrote:

Hi Harald & all,

Thanks
Partha

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 09 Nov 2013 23:22:23 +0100

On 11/09/2013 10:55 AM, Parthasarathi R wrote:
>
> Hi Justin,  Markus & all,
>
>  
>
> It is good to know that conference server usecase as well for ICE-TCP
> usage. I think that it is better to request for adding conference/IVR
> Server/Gateway with firewall usecases explicitly in the RTCWeb usecase
> & requirement document in case there is no other objection in this
> mail thread.
>

Section 3.4.3 "Video conferencing system with central server" seems to
already cover this case.

In particular (from -12):

   Note: This use-case adds requirements on ..... ability to traverse very
   restrictive FWs.

>  
>
> Thanks
>
> Partha
>
>  
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Justin Uberti
> *Sent:* Saturday, November 09, 2013 7:27 AM
> *To:* [email-masked]
> *Cc:* Harald Tveit Alvestrand; [email-masked]; Parthasarathi R
> On Fri, Nov 8, 2013 at 3:58 PM, <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> Hi Justin,
>
>  
>
> It’s great to hear that at least one browser will be able to do
> ICE-TCP. It is an optimization, but definitely a useful one for
> certain central server and gateway situations. I have heard also from
> other service/gateway providers that they want to avoid the TURN-TCP
> “hop” for the same reasons you state. After listening to them, I’d say
> ICE-TCP ought to be rather a “SHOULD” instead of “MAY” in the RTCWeb
> NAT traversal framework.  
>
>  
>
> Sounds good. 
>
>      
>
>     I suppose that when real-time media runs over TCP, it is in
>     general best to avoid bundling, but to run the different medias
>     over separate TCP connections. That way a single lost packet only
>     affects the rate of one of the medias instead of the aggregate.
>
>      
>
> That is an interesting idea, but I think it is probably difficult to
> make work because the BUNDLE decision happens separately from ICE
> candidate pair selection.
>
>  
>
> I think what we really want is some sort of multi-TCP transport, where
> we can open several simultaneous TCP connections and rotate between
> them. Or maybe a Minion TCP-based approach. These would have their own
> issues, but be conceptually simpler.
>
>  
>
>     I wonder if you already have a plan in Chrome if and how to deal
>     with HTTP (and TLS) restricted firewalls. Are you OK with the idea
>     of connecting to a TURN server with HTTP CONNECT, or do you see
>     some issues with that?  
>
>  
>
>     *From:[email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>]
>     *On Behalf Of *ext Justin Uberti
>     *Cc:* Harald Alvestrand; [email-masked] <mailto:[email-masked]>
>
>
>     FWIW: we use ICE-TCP to connect to a conferencing server, instead
>     of TURN-TCP, to avoid the extra TURN hop and the whole TURN
>     credentials business. It's an optimization for sure, but a useful one.
>
>      
>
>     I don't think ICE-TCP will be all that useful for P2P connectivity
>     in the near future. The scenarios that require ICE-TCP are the
>     exact ones where simultaneous open will probably be impossible.
>
>      
>
>     On Sun, Oct 20, 2013 at 9:10 AM, Parthasarathi R
>     <[email-masked] <mailto:[email-masked]>>
>     wrote:
>
>     Hi Harald & all,
>
>     > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf
>
>     > Of Harald Alvestrand
>     > To: [email-masked] <mailto:[email-masked]>
>     > <[email-masked] <mailto:[email-masked]>> wrote:
>     > >
>     > >>> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     > Behalf Of Dan
>     > >>> Wing (dwing)
>     > >>> To: [email-masked] <mailto:[email-masked]>
>     > >>> Cc: [email-masked] <mailto:[email-masked]>;
>     [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

-- 
Surveillance is pervasive. Go Dark.

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Sun, 10 Nov 2013 17:31:18 +0000

Hi Harald,

Even though there is a note  in Sec 3.4.3.1  for ability to traverse very restrictive FWs, there is no additional requirement because of this usecase. I attached the exact note and relevant requirement in the mail for easy reference. Also, there is no additional requirement as part of Sec 3.4.1 (Telephony terminal) or Sec 3.4.2 (WebEx call) w.r.t to traverse very restrictive FW. I’m requesting for adding the explicit additional requirement in Sec 3.4.3.1 or  Sec 3.4.2.2 or Sec 3.4.3.3 to provide the better clarity between ICE-TCP based solution and TURN based solution. The requirement shall be in the line of:

“The browser should be able to send streams and data to a peer in the presence of NATs and FWs that block UDP traffic and incoming TCP connection.”

I have mailed these requirement change as part of http://www.ietf.org/mail-archive/web/rtcweb/current/msg09101.html in IETF RTCWeb WG. The requirement difference in this mail and archive is that “should” is mentioned here whereas “must” was mentioned earlier. Also update the existing NAT/FW requirement is to state both browser behind firewall scenario as follows:

“The browser must be able to send streams and data to a peer in the presence of NATs and FWs that block UDP traffic and incoming TCP connection in both browser side as well as in the peer side” (TURN only works)

Thanks
Partha

Note: Sec 3.4.3.1 note -
   This use-case adds requirements on support for fast stream
   switches F7, on encryption of media and on ability to traverse very
   restrictive FWs.  There exist several solutions that enable the
   server to forward one high resolution and several low resolution
   video streams: a) each browser could send a high resolution, but
   scalable stream, and the server could send just the base layer for
   the low resolution streams, b) each browser could in a simulcast
   fashion send one high resolution and one low resolution stream, and
   the server just selects or c) each browser sends just a high
   resolution stream, the server transcodes into low resolution streams
   as required.
3.4.3.2<http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.4.3.2>.  Additional Requirements

   F17

   A17

Browser requirement:
--
 F17     The browser must be able to mix several
           audio streams.

F7      The browser must support insertion of reference frames
           in outgoing media streams when requested by a peer.

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Harald Alvestrand
Sent: Sunday, November 10, 2013 3:52 AM
To: Parthasarathi R; 'Justin Uberti'; [email-masked]
Cc: [email-masked]
Subject: Re: [pntaw] Real-time media over TCP

Section 3.4.3 "Video conferencing system with central server" seems to already cover this case.

Thanks
Partha

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Justin Uberti
Sent: Saturday, November 09, 2013 7:27 AM
To: [email-masked]<mailto:[email-masked]>
Cc: Harald Tveit Alvestrand; [email-masked]<mailto:[email-masked]>; Parthasarathi R
Subject: Re: [pntaw] Real-time media over TCP

On Fri, Nov 8, 2013 at 3:58 PM, <[email-masked]<mailto:[email-masked]>> wrote:
Hi Justin,

Sounds good.

Markus

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of ext Justin Uberti
Sent: 09 November, 2013 01:33
To: Parthasarathi R
Cc: Harald Alvestrand; [email-masked]<mailto:[email-masked]>

--

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 10 Nov 2013 20:55:50 +0100

On 11/10/2013 06:31 PM, Ravindran, Parthasarathi (NSN - IN/Bangalore) wrote:
>
> Hi Harald,
>
>  
>
> Even though there is a note  in Sec 3.4.3.1  for ability to traverse
> very restrictive FWs, there is no additional requirement because of
> this usecase. I attached the exact note and relevant requirement in
> the mail for easy reference.
>

You're right - this note was a leftover when the requirements in section
3.1 were factored out to be "applicable to all scenarios".

The relevant point in 3.1 is:

   o  Clients can be on firewalled networks with no UDP allowed

So are you saying that we should add a requirement in 3.1 to say

 * Clients can be on firewalled network with no UDP or incoming TCP allowed

?

> Also, there is no additional requirement as part of Sec 3.4.1
> (Telephony terminal) or Sec 3.4.2 (WebEx call) w.r.t to traverse very
> restrictive FW. I’m requesting for adding the explicit additional
> requirement in Sec 3.4.3.1 or  Sec 3.4.2.2 or Sec 3.4.3.3 to provide
> the better clarity between ICE-TCP based solution and TURN based
> solution. The requirement shall be in the line of:
>
>  
>
> “The browser should be able to send streams and data to a peer in the
> presence of NATs and FWs that block UDP traffic and incoming TCP
> connection.”
>
>  
>
> I have mailed these requirement change as part of
> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09101.html in
> IETF RTCWeb WG. The requirement difference in this mail and archive is
> that “should” is mentioned here whereas “must” was mentioned earlier.
> Also update the existing NAT/FW requirement is to state both browser
> behind firewall scenario as follows:
>
>  
>
> “The browser must be able to send streams and data to a peer in the
> presence of NATs and FWs that block UDP traffic and incoming TCP
> connection in both browser side as well as in the peer side” (TURN
> only works)
>
>  
>
> Thanks
>
> Partha
>
>  
>
> Note: Sec 3.4.3.1 note -
>
> *3.4.3.2*
> <http://tools.ietf.org/html/draft-ietf-rtcweb-use-cases-and-requirements-12#section-3.4.3.2>*. 
> Additional Requirements*
>
>  
>
>  
>
>    F17
>
>  
>
>    A17
>
>  
>
> Browser requirement:
>
> --
>
> Behalf Of *ext Harald Alvestrand
> *Sent:* Sunday, November 10, 2013 3:52 AM
> *To:* Parthasarathi R; 'Justin Uberti'; [email-masked]
> *Cc:* [email-masked]
>     It is good to know that conference server usecase as well for
>     ICE-TCP usage. I think that it is better to request for adding
>     conference/IVR Server/Gateway with firewall usecases explicitly in
>     the RTCWeb usecase & requirement document in case there is no
>     other objection in this mail thread.
>
>
> [mailto:[email-masked]] *On Behalf Of *Justin Uberti
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* Harald Tveit Alvestrand; [email-masked] <mailto:[email-masked]>;
> Parthasarathi R

---

From: "Ravindran, Parthasarathi (NSN - IN/Bangalore)" <[email-masked]>
Date: Tue, 12 Nov 2013 18:30:04 +0000

Hi Harald,

Please read inline.

Thanks
Partah

From: ext Harald Alvestrand [mailto:[email-masked]]
Sent: Monday, November 11, 2013 1:26 AM
To: Ravindran, Parthasarathi (NSN - IN/Bangalore)
Cc: [email-masked]
Subject: Re: [pntaw] Real-time media over TCP

Even though there is a note  in Sec 3.4.3.1  for ability to traverse very restrictive FWs, there is no additional requirement because of this usecase. I attached the exact note and relevant requirement in the mail for easy reference.

You're right - this note was a leftover when the requirements in section 3.1 were factored out to be "applicable to all scenarios".

?
<Partha>  In sec 3.1, the requirement has to be updated as below for more clarity

1)       Clients can be on firewalled network with no UDP allowed and no incoming TCP allowed (ICE-TCP solution)

2)       Both clients in the session can be on firewalled network with no UDP allowed and no incoming TCP allowed

Also, firewall related requirement in the draft has to be updated as per the above.

</Partha>

Also, there is no additional requirement as part of Sec 3.4.1 (Telephony terminal) or Sec 3.4.2 (WebEx call) w.r.t to traverse very restrictive FW. I’m requesting for adding the explicit additional requirement in Sec 3.4.3.1 or  Sec 3.4.2.2 or Sec 3.4.3.3 to provide the better clarity between ICE-TCP based solution and TURN based solution. The requirement shall be in the line of:

Thanks
Partha

Note: Sec 3.4.3.1 note -

   F17

   A17

Browser requirement:

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of ext Harald Alvestrand
Sent: Sunday, November 10, 2013 3:52 AM
To: Parthasarathi R; 'Justin Uberti'; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [pntaw] Real-time media over TCP

Thanks
Partha

Sounds good.

Markus

--

--

---

From: <[email-masked]>
Date: Thu, 14 Nov 2013 11:39:12 +0000

Justin,

One more clarification:
[Markus] I wonder if you already have a plan in Chrome if and how to deal with HTTP (and TLS) restricted firewalls. Are you OK with the idea of connecting to a TURN server with HTTP CONNECT, or do you see some issues with that?
[Justin] We already use HTTP CONNECT with ICE-TCP, TURN-TCP, and TURN-TLS. It works.

[Markus] So you use HTTP CONNECT to open the TCP connections for ICE-TCP too? And in this way you will basically never need to use TURN for the conference server or gateway type of case where the other peer is reachable by TCP? That would be cool. Now we would have to get this standardized somehow or just convince other browsers to do the same, as the standards path seems tricky and lengthy. Could you tell how you decide if HTTP CONNECT is needed or not? Do you do some connectivity tests in the background and cache the result, or do you do it for each RTCPeerConnection? Or do you just follow the HTTP proxy configuration rules and apply them to ICE-TCP and TURN?

Markus

From: ext Justin Uberti [mailto:[email-masked]]
Sent: 09 November, 2013 03:57
To: Isomaki Markus (Nokia-CIC/Espoo)
Cc: Parthasarathi R; Harald Tveit Alvestrand; [email-masked]
Subject: Re: [pntaw] Real-time media over TCP

Sounds good.

Markus

---

From: Justin Uberti <[email-masked]>
Date: Thu, 14 Nov 2013 15:00:22 -0800

On Thu, Nov 14, 2013 at 3:39 AM, <[email-masked]> wrote:

>  Justin,
>
>
>
> One more clarification:
>
> [Markus] I wonder if you already have a plan in Chrome if and how to deal
> with HTTP (and TLS) restricted firewalls. Are you OK with the idea of
> connecting to a TURN server with HTTP CONNECT, or do you see some issues
> with that?
>
> [Markus] So you use HTTP CONNECT to open the TCP connections for ICE-TCP
> too? And in this way you will basically never need to use TURN for the
> conference server or gateway type of case where the other peer is reachable
> by TCP? That would be cool. Now we would have to get this standardized
> somehow or just convince other browsers to do the same, as the standards
> path seems tricky and lengthy. Could you tell how you decide if HTTP
> CONNECT is needed or not? Do you do some connectivity tests in the
> background and cache the result, or do you do it for each
> RTCPeerConnection? Or do you just follow the HTTP proxy configuration rules
> and apply them to ICE-TCP and TURN?
>

Yes, HTTP CONNECT is used for ICE-TCP.

I forget the details, but I think right now we just obey the proxy
configuration for TCP, but also try direct UDP. There could be cases where
direct TCP could work as well, but given that that's not an optimal outcome
anyway, I don't think that is hooked up.

>
>
> Markus
>
>
>
>
>
> *From:* ext Justin Uberti [mailto:[email-masked]]
> *Sent:* 09 November, 2013 03:57
> *To:* Isomaki Markus (Nokia-CIC/Espoo)
> *Cc:* Parthasarathi R; Harald Tveit Alvestrand; [email-masked]
>
> make work because the BUNDLE decision happens separately from ICE candidate
> pair selection.
>
>
>