WebRTC port requirements?

30,157 views
Skip to first unread message

Ken Smith

unread,
Jan 22, 2013, 2:22:21 PM1/22/13
to discuss-webrtc
Is there a succinct summary anywhere of what ports need to be open for WebRTC to function? I've looked around and can't find one. (For instance, in the current spec, the word "ports" doesn't even occur.)

I know, for instance, that RTMFP requires that all outbound UDP ports > 1023 be open, which is a non-starter on most corporate firewalls. I'm assuming that WebRTC is significantly more intelligent in that regard, but I'd still like to know what the bare minimum is.

What I know so far:

- The port for the signaling server (could be anything)
- The port for the STUN and/or TURN server (e.g., 19302, but could be anything)
- The port over which the actual communication happens (<-- This is mostly what I don't know)

Is the last one selected dynamically? What are the options? Could it be absolutely anything? If you were going to configure a firewall to be as absolutely secure as possible and still have WebRTC work out-of-the-box, what ports would you open up?

Kaiduan Xie

unread,
Jan 22, 2013, 2:48:32 PM1/22/13
to discuss...@googlegroups.com
If you look the source code, it does not specify the port range, look
the udpport.cc, min_port()/max_port() all returns 0, so OS will choose
the local port.
> --
>
>
>

Ken Smith

unread,
Jan 22, 2013, 3:57:04 PM1/22/13
to discuss...@googlegroups.com
So does this mean that it could expect to setup communication over any port? And hence that all outbound UDP ports need to be open? (That would seem like very - err, very - bad news. I think it would be a deal-killer for most corporate networks. Surely it hasn't been designed this way.)
--




Nick Foster

unread,
Jan 22, 2013, 4:04:02 PM1/22/13
to discuss...@googlegroups.com
Signaling can happen over a variety of methods, a common one is WebSockets which means it will go over port 80.

I am certainly not an expert on how ports are picked but my understanding is that, the media will be transported over any available port that can be obtained. Using TURN servers and other NAT traversal techniques it will be attempting to pick ports that are available to the outside world. WIth DNATs both parties start sending media at each other until both have opened a pinhole for each other.

- Nick


--
 
 
 

Ken Smith

unread,
Jan 22, 2013, 5:01:59 PM1/22/13
to discuss...@googlegroups.com
Thanks, Nick. That's more-or-less how I understood it to work - but I'm still curious about how the port selection process works, and which ports you would want to have open. Because even if you're just trying ports, presumably it's not just (say) starting at UDP port 1024 and walking one-by-one up to 65535, trying them all in turn. It's got to have a more intelligent process than that. Right?

It would be helpful to have someone from the Chromium project comment on this authoritatively.

The context of my question, for what it's worth, is that we'll be needing to tell companies implementing our product what specific outbound ports they need to have open for our stuff to work. Ideally, we could tell them something like "port 80/TCP for signaling, 3478/UDP/TCP for STUN, and port x/UDP for streaming." Or something like that. Telling them, "You need to open up outbound ports 1024-65535" is just gonna get us laughed at, I'm afraid.
--
 
 
 

Ivan Vučica

unread,
Jan 23, 2013, 3:12:40 AM1/23/13
to discuss...@googlegroups.com, discuss...@googlegroups.com
According to what Xie said, port 'zero' is requested from the OS -- which actually results in a random port. Well, perhaps not random, but OS-decided.

I presume that everything else is handled via ICE; candidates are generated, exchanged via signaling, and firewall 'piercing' is attempted.

and if what Xie said is accurate, it indeed would be great if one could specify min and max ports in browser config instead of having them both set to zero.

Regards,

Ivan Vučica
via phone
--
 
 
 

Anthony Roach

unread,
Jan 23, 2013, 11:01:40 AM1/23/13
to discuss...@googlegroups.com
Ken, my understanding of the RTP/ICE related specs is it requires the end user to use a stateful firewall that allows outbound UDP packets from any port to any port on a destination server, and then will allow inbound UDP packets from that same destination server/port to the sending port for a small amount of time. The browser will send an initial ICE packet out over whatever port it picks to get the firewall to open the port, and will then periodically send ICE packets to keep the port open. 

The same basic requirements would apply if they are using a NAT router... the NAT router would be required to create a dynamic temporary forward for the source UDP port when the initial ICE packet is sent and maintain that forward for a short amount of time. The subsequent ICE packets sent by the browser would then keep the forward open for the duration.

If the user has some sort of very restrictive firewall that won't let any UDP packets out by default or a NAT that won't do dynamic forwards, then there will be problems. Of course in a corporate environment with 1000 users all needing to do VOIP calls would you really expect the IT staff to create a static firewall rule and NAT forward for each of those 1000 user's PCs? 
Message has been deleted

Ken Smith

unread,
Jan 23, 2013, 12:06:01 PM1/23/13
to discuss...@googlegroups.com
That's a helpful explanation, Anthony. But my experience is that many corporate firewalls use a "deny-all" philosophy, i.e., they only allow traffic out over ports which they know ahead of time are legitimate. We recently tried to do something vaguely similar to WebRTC, but using Microsoft Silverlight as the underlying platform. Silverlight has all sorts of limitations in this regard, including the requirement that it can only open TCP/IP connections to a remote machine on ports 4502-4534. And this was a real problem for us, because nearly every single corporate environment to which we tried to deploy it (or even just demo it) had a policy which said, in effect, "We're only going to allow traffic out through ports which we know ahead of time are OK." Our application only needed a few ports out of those 32, but to simplify matters, we often asked them to just allow traffic out through all 32 ports. And quite often their security guys refused, saying, "Tell us which specific ports you need open, and we'll let traffic out through those."

I'm reasonably confident that if we go into an environment like that and say, "Hey, we need to allow traffic out through, umm, 64,000 ports," they're gonna stare at us like we're bonkers.

In other words, my worry is that if the only firewall traversal strategy requires 64,000 open ports, it's not much of a firewall traversal strategy, because it's not gonna work in a really large number of corporate environments.

In contrast, so far as I've been able to tell, Skype has a very robust firewall traversal strategy that involves trying just about every approach under the sun to get out. (It also does some stuff that wouldn't be advisable in WebRTC, like using ports 80 and 443 as a last-ditch traversal strategy.)

Can anyone else chime in with a confirmation that this is or is not a problem? Has anyone thought about putting together a network administrator's guide to WebRTC? Perhaps including (a) how to get WebRTC to work in a "deny-all" environment; and (b) how to make sure WebRTC won't work.

--
 
 
 

Ken Smith

unread,
Jan 23, 2013, 12:38:12 PM1/23/13
to discuss...@googlegroups.com
One more thing. My assumption is that my worries are misplaced, and that WebRTC will work out-of-the-box in most corporate environments, and with a few minor tweaks in the rest. I just want (a) to know that my worries are misplaced, and (b) to understand what the minor tweaks are. I can't imagine that with all the big brains working on WebRTC, they would have created something that will only work if a corporation does a 180 on its security philosophy from "only allow out what we approve" to "allow everything out". (On the other hand, my understanding is that this is precisely what Flash's RTMFP protocol requires, rendering it effectively useless, so you can perhaps see why I don't want to take anything for granted.)

Anthony Roach

unread,
Jan 23, 2013, 1:29:43 PM1/23/13
to discuss...@googlegroups.com
I can't say for sure whether your worries are misplaced or not, because I'm not an expert on WebRTC. From my reading of the specs and seeing how Chrome behaves it appears to me that there are going to be problems in a "deny-all" corporate environment. If Chrome (and the other browsers) were to add a way to configure a port range (either via the settings pages or via Javascript) for RTP, then that would help quite a bit, but from my reading of the spec I don't see any way that the port range can be reduced to a single port. In fact it appears that you need a seperate UDP port for each peer connection... although perhaps if your application will only connect to a single peer at a time, then you could get by with a single port. 

BTW, I've found this spec to be very useful in trying to figure out how WebRTC really works under the hood: http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-05

Also, I've seen Chrome include TCP ICE candidate lines in the SDP, and I don't understand how RTP over TCP would work or whether you could multiplex multiple peer connections over a single TCP connection port.

Justin Uberti

unread,
Jan 23, 2013, 3:55:40 PM1/23/13
to discuss-webrtc
The current answer to this question:
1) For enterprises that want to restrict UDP to a finit # of ports, the base WebRTC code supports restricting media to a range of ports. This is not wired up to any policy settings right now, but Chrome has built-in support for setting enterprise policies (http://www.thechromesource.com/using-policy-templates-for-chrome-in-enterprise-settings/) and so we could easily hook this up.
2) For enterprises that don't want to let any UDP out, we support ICE-TCP for connecting via TCP, over whatever port you want to use (80, 443, etc). 
3) For enterprises that want to prevent any connections to the outside, i.e. proxy everything, we will support an enterprise TURN server as a proxy for all WebRTC communications. This will be just like an application-supplied TURN server, except it will be used for all WebRTC sessions.
4) For enterprises that want to shut off WebRTC completely, there is a current policy setting to do this.


--
 
 
 

Adam Fineberg

unread,
Jan 23, 2013, 12:56:35 PM1/23/13
to discuss...@googlegroups.com
Ken,

If the corp firewall policy is very restrictive, one solution might be to run everything through a relay (turn server) where you can configure the relay to use a specific port.  That would allow the user inside the firewall to allocate a connection on the relay using a predefined port and then communicate that allocation to the other party as an ICE candidate.

Regards,
Adam
fine...@vline.com
www.vline.com
www.gittogether.com (WebRTC demo application)
--
 
 
 

-- 
Regards,
Adam

Neil Stratford

unread,
Jan 23, 2013, 1:15:02 PM1/23/13
to discuss-webrtc
I believe that the intention is that such networks are supported by
the use of TURN servers, either outside of the network which would
require a single port to the TURN relay, or within the network under
full control of the network admin.

Neil

On Jan 23, 5:38 pm, Ken Smith <smithk...@gmail.com> wrote:
> One more thing. My assumption is that my worries are misplaced, and that
> WebRTC will work out-of-the-box in most corporate environments, and with a
> few minor tweaks in the rest. I just want (a) to *know* that my worries are
> misplaced, and (b) to understand what the minor tweaks are. I can't imagine
> that with all the big brains working on WebRTC, they would have created
> something that will only work if a corporation does a 180 on its security
> philosophy from "only allow out what we approve" to "allow everything out".
> (On the other hand, my understanding is that this is precisely what Flash's
> RTMFP protocol requires <http://forums.adobe.com/thread/583118>, rendering
> it effectively useless, so you can perhaps see why I don't want to take
> anything for granted.)
>
> Ken Smith
> Cell: 425-443-2359
> Email: smithk...@gmail.com
> Blog:http://blog.wouldbetheologian.com/
>
>
>
>
>
>
>
> On Wed, Jan 23, 2013 at 9:06 AM, Ken Smith <smithk...@gmail.com> wrote:
> > That's a helpful explanation, Anthony. But my experience is that many
> > corporate firewalls use a "deny-all" philosophy, i.e., they only allow
> > traffic out over ports which they know ahead of time are legitimate. We
> > recently tried to do something vaguely similar to WebRTC, but using
> > Microsoft Silverlight as the underlying platform. Silverlight has all sorts
> > of limitations in this regard, including the requirement that it can only
> > open TCP/IP connections to a remote machine on ports 4502-4534. And this
> > was a real problem for us, because nearly every single corporate
> > environment to which we tried to deploy it (or even just demo it) had a
> > policy which said, in effect, "We're only going to allow traffic out
> > through ports which we know ahead of time are OK." Our application only
> > needed a few ports out of those 32, but to simplify matters, we often asked
> > them to just allow traffic out through all 32 ports. And quite often their
> > security guys refused, saying, "Tell us which *specific* ports you need
> > open, and we'll let traffic out through those."
>
> > I'm reasonably confident that if we go into an environment like that and
> > say, "Hey, we need to allow traffic out through, umm, 64,000 ports,"
> > they're gonna stare at us like we're bonkers.
>
> > In other words, my worry is that if the only firewall traversal strategy
> > requires 64,000 open ports, it's not much of a firewall traversal strategy,
> > because it's not gonna work in a really large number of corporate
> > environments.
>
> > In contrast, so far as I've been able to tell, Skype has a very robust
> > firewall traversal strategy that involves trying just about every approach
> > under the sun to get out. (It also does some stuff that wouldn't be
> > advisable in WebRTC, like using ports 80 and 443 as a last-ditch traversal
> > strategy.)
>
> > Can anyone else chime in with a confirmation that this is or is not a
> > problem? Has anyone thought about putting together a network
> > administrator's guide to WebRTC? Perhaps including (a) how to get WebRTC to
> > work in a "deny-all" environment; and (b) how to make sure WebRTC *won't*
> >  work.
>
> > Ken Smith
> > Cell: 425-443-2359
>
> > Email: smithk...@gmail.com
> > Blog:http://blog.wouldbetheologian.com/
> >>> Blog:http://blog.wouldbetheologian.**com/<http://blog.wouldbetheologian.com/>
>
> >>> On Tue, Jan 22, 2013 at 1:04 PM, Nick Foster <ni...@firespotter.com>wrote:
>
> >>>>  Signaling can happen over a variety of methods, a common one is
> >>>> WebSockets which means it will go over port 80.
>
> >>>> I am certainly not an expert on how ports are picked but my
> >>>> understanding is that, the media will be transported over any available
> >>>> port that can be obtained. Using TURN servers and other NAT traversal
> >>>> techniques it will be attempting to pick ports that are available to the
> >>>> outside world. WIth DNATs both parties start sending media at each other
> >>>> until both have opened a pinhole for each other.
>
> >>>> - Nick
>
> >>>> On Tue, Jan 22, 2013 at 12:57 PM, Ken Smith <smit...@gmail.com> wrote:
>
> >>>>> So does this mean that it could expect to setup communication over *
> >>>>> any* port? And hence that all outbound UDP ports need to be open?
> >>>>> (That would seem like very - err, *very* - bad news. I think it would
> >>>>> be a deal-killer for most corporate networks. Surely it hasn't been
> >>>>> designed this way.)
>
> >>>>> Ken Smith
> >>>>> Cell: 425-443-2359
> >>>>> Email: smit...@gmail.com
> >>>>> Blog:http://blog.wouldbetheologian.**com/<http://blog.wouldbetheologian.com/>
> >>>>>> > Blog:http://blog.wouldbetheologian.**com/<http://blog.wouldbetheologian.com/>

Ken Smith

unread,
Jan 23, 2013, 4:42:28 PM1/23/13
to discuss...@googlegroups.com
Thanks for the response, Justin. Some more questions (sorry!):

(1) Is an Active Directory policy the only way to restrict the range of ports being used? In other words, is there a way to control this (say) for Macs, or in a non-AD environment? I'm thinking that being able to set the range of ports via JavaScript would be very helpful.

(2) If, as others have suggested, this is what a TURN server is for, what's the simplest way to tell WebRTC, "Use UDP peer-to-peer if you can get it to work, and then fallback to using this TURN server as a relay if that doesn't work, over UDP first, and then (if nothing else works) over TCP?" Or do you get this for free just by referencing a TURN server rather than a STUN server?

(3) I like the sound of what you say ICE-TCP can do, namely, being able to push out through (say) TCP ports 80 or 443 if nothing else works. How do you get that to happen? Or is it something that WebRTC does automatically, and I don't need to worry about it? (So far I'm only seeing UDP ICE candidates get sent.)

Justin Uberti

unread,
Jan 23, 2013, 5:48:06 PM1/23/13
to discuss-webrtc
On Wed, Jan 23, 2013 at 1:42 PM, Ken Smith <smit...@gmail.com> wrote:
Thanks for the response, Justin. Some more questions (sorry!):

(1) Is an Active Directory policy the only way to restrict the range of ports being used? In other words, is there a way to control this (say) for Macs, or in a non-AD environment? I'm thinking that being able to set the range of ports via JavaScript would be very helpful.

No, there are several other ways - see Mac (http://www.chromium.org/administrators/mac-quick-start), or more info at http://www.chromium.org/administrators. This won't be exposed to JS - it's not clear how the JS would know the right enterprise policy.
 

(2) If, as others have suggested, this is what a TURN server is for, what's the simplest way to tell WebRTC, "Use UDP peer-to-peer if you can get it to work, and then fallback to using this TURN server as a relay if that doesn't work, over UDP first, and then (if nothing else works) over TCP?" Or do you get this for free just by referencing a TURN server rather than a STUN server?

That's how it works by default if you plug in a TURN server. 

(3) I like the sound of what you say ICE-TCP can do, namely, being able to push out through (say) TCP ports 80 or 443 if nothing else works. How do you get that to happen? Or is it something that WebRTC does automatically, and I don't need to worry about it? (So far I'm only seeing UDP ICE candidates get sent.)

The remote application needs to support ICE-TCP, of course, and be publicly accessible (e.g. a gateway) - it would signal this by sending ICE candidates with a protocol of TCP and a port of 443, for example.

In the future we will also support TURN/TCP and TURN/TLS, which will require no changes to the remote application. 

--
 
 
 

Ken Smith

unread,
Jan 23, 2013, 5:57:31 PM1/23/13
to discuss...@googlegroups.com
I think that answers all my questions (at least for now, and on that topic :-). Thanks, Justin.
--
 
 
 

BP Gangadharan

unread,
Feb 20, 2013, 1:00:59 AM2/20/13
to discuss...@googlegroups.com
Sorry for this late question. Could you please clarify

A) Do you expect ICE-TCP (esp on TLS) to go over a http proxy where DPI is not present.
B) On your point 3, how does this enterprise TURN server work? Would there be an option in
     the proxy settings of the browser (eg: chrome) to specify the enterprise TURN proxy address? Would this enterprise TURN server then proxy the STUN/TURN traffic to the real TURN server in the internet?

- Binod.

Warren McDonald

unread,
Feb 20, 2013, 5:01:05 PM2/20/13
to discuss...@googlegroups.com
I would like to know the answer A.

On B, the TURN server would be deployed in, or across, the DMZ to allow it to have an internal and external internet address. The peerconnection config would have to have 2 entries for this server, one for the internal and for the external addressing. Or you could have split dns config, so the right IP is resolved depending on internal or external source.

Warren

Justin Uberti

unread,
Feb 20, 2013, 7:27:46 PM2/20/13
to discuss-webrtc
On Tue, Feb 19, 2013 at 10:00 PM, BP Gangadharan <bp.gang...@gmail.com> wrote:
Sorry for this late question. Could you please clarify

A) Do you expect ICE-TCP (esp on TLS) to go over a http proxy where DPI is not present.

If the proxy supports HTTPS, e.g. tunnelling via HTTP CONNECT, then yes. If not, then no.
 
B) On your point 3, how does this enterprise TURN server work? Would there be an option in
     the proxy settings of the browser (eg: chrome) to specify the enterprise TURN proxy address? Would this enterprise TURN server then proxy the STUN/TURN traffic to the real TURN server in the internet?

Yes, this would be configured via settings/enterprise policies. In this case a "real TURN server" would probably not be needed.

--
 
---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Justin Uberti

unread,
Feb 20, 2013, 7:28:35 PM2/20/13
to discuss-webrtc
On Wed, Feb 20, 2013 at 2:01 PM, Warren McDonald <warren....@gmail.com> wrote:
I would like to know the answer A.

On B, the TURN server would be deployed in, or across, the DMZ to allow it to have an internal and external internet address. The peerconnection config would have to have 2 entries for this server, one for the internal and for the external addressing. Or you could have split dns config, so the right IP is resolved depending on internal or external source.

No, the PeerConnection config would only have the internal address. It learns the external address via the TURN protocol. 

Warren

BP Gangadharan

unread,
Feb 21, 2013, 6:40:34 AM2/21/13
to discuss...@googlegroups.com


On Thu, Feb 21, 2013 at 5:57 AM, Justin Uberti <jub...@google.com> wrote:
Thanks Justin for the quick response. Please see comments below.

On Tue, Feb 19, 2013 at 10:00 PM, BP Gangadharan <bp.gang...@gmail.com> wrote:
Sorry for this late question. Could you please clarify

A) Do you expect ICE-TCP (esp on TLS) to go over a http proxy where DPI is not present.

If the proxy supports HTTPS, e.g. tunnelling via HTTP CONNECT, then yes. If not, then no.

I guess, this would require every browser to honour http proxy settings for TURN as well and send a CONNECT to the proxy for establishing TURN traffic. Right?

Will this be specified in any w3c or ietf speficiations? Or will this be an implementation specific behaviour of the browser?
 
 
B) On your point 3, how does this enterprise TURN server work? Would there be an option in
     the proxy settings of the browser (eg: chrome) to specify the enterprise TURN proxy address? Would this enterprise TURN server then proxy the STUN/TURN traffic to the real TURN server in the internet?

Yes, this would be configured via settings/enterprise policies. In this case a "real TURN server" would probably not be needed.

If I understand your answer correctly, this TURN proxy settings will not be as visible as an HTTP proxy setting. The enterprise will have to use something like
a mechanism specified in the pages below for setting it up.
http://support.google.com/chromeos/a/bin/answer.py?hl=en&answer=187202
http://support.google.com/chromeos/a/bin/answer.py?hl=en&answer=187204

Could you please confirm?

thanks,
Binod
 

Justin Uberti

unread,
Feb 21, 2013, 1:24:53 PM2/21/13
to discuss-webrtc
On Thu, Feb 21, 2013 at 3:40 AM, BP Gangadharan <bp.gang...@gmail.com> wrote:


On Thu, Feb 21, 2013 at 5:57 AM, Justin Uberti <jub...@google.com> wrote:
Thanks Justin for the quick response. Please see comments below.

On Tue, Feb 19, 2013 at 10:00 PM, BP Gangadharan <bp.gang...@gmail.com> wrote:
Sorry for this late question. Could you please clarify

A) Do you expect ICE-TCP (esp on TLS) to go over a http proxy where DPI is not present.

If the proxy supports HTTPS, e.g. tunnelling via HTTP CONNECT, then yes. If not, then no.

I guess, this would require every browser to honour http proxy settings for TURN as well and send a CONNECT to the proxy for establishing TURN traffic. Right?

More generally, for all WebRTC-related TCP flows (either using ICE-TCP or TURN), the browser has to be aware of how to run those TCP flows through the proxy. 

Will this be specified in any w3c or ietf speficiations? Or will this be an implementation specific behaviour of the browser?

This probably need to be specified in IETF, since there are edge cases, i.e. should the HTTP proxy be used to connect to the TURN server when it is an enterprise TURN server, etc. 

 
 
 
B) On your point 3, how does this enterprise TURN server work? Would there be an option in
     the proxy settings of the browser (eg: chrome) to specify the enterprise TURN proxy address? Would this enterprise TURN server then proxy the STUN/TURN traffic to the real TURN server in the internet?

Yes, this would be configured via settings/enterprise policies. In this case a "real TURN server" would probably not be needed.

If I understand your answer correctly, this TURN proxy settings will not be as visible as an HTTP proxy setting. The enterprise will have to use something like
a mechanism specified in the pages below for setting it up.
http://support.google.com/chromeos/a/bin/answer.py?hl=en&answer=187202
http://support.google.com/chromeos/a/bin/answer.py?hl=en&answer=187204

Could you please confirm?

TBD. My expectation would be that it would be visible as a proxy setting as well as configurable via policy, but this is a complicated area since Chrome typically relies on the OS proxy settings, which have no knowledge of TURN.

Warren McDonald

unread,
Feb 21, 2013, 5:25:29 PM2/21/13
to discuss...@googlegroups.com
Hi,

re my post on how an enterprise TURN server would be implemented, I assumed no proxy was involved, as the TURN server would have a private address which was accessible by internal clients.  

The case I proposed where the TURN server had 2 listening addresses, one private, one public, suggested split DNS so that private and public users accessing the same web application would get the correct address resolution. 

There are other ways of implementing this, such as placing the TURN server in network zone with public internet address only, but ensuring enterprise networking is configured to allow appropriate port access to this server.

Which case would be more appropriate depends on existing enterprise network arrangements.

Warren    

Warren McDonald

unread,
Feb 21, 2013, 5:33:09 PM2/21/13
to discuss...@googlegroups.com


On Thursday, 21 February 2013 11:28:35 UTC+11, Justin Uberti wrote:



On Wed, Feb 20, 2013 at 2:01 PM, Warren McDonald <warren....@gmail.com> wrote:
I would like to know the answer A.

On B, the TURN server would be deployed in, or across, the DMZ to allow it to have an internal and external internet address. The peerconnection config would have to have 2 entries for this server, one for the internal and for the external addressing. Or you could have split dns config, so the right IP is resolved depending on internal or external source.

No, the PeerConnection config would only have the internal address. It learns the external address via the TURN protocol. 

      But what about external clients connecting to the same app, They will likely need to resolve to the same TURN server first in some scenarios.

mehmet ozisik

unread,
Feb 27, 2013, 7:55:44 AM2/27/13
to discuss...@googlegroups.com


22 Ocak 2013 Salı 21:22:21 UTC+2 tarihinde Ken Smith yazdı:

mehmet ozisik

unread,
Feb 27, 2013, 7:56:22 AM2/27/13
to discuss...@googlegroups.com
Hi Justin,

I would like to ask about your second option. How we can configure ports as 80 or 443 with webrtc. I have tried to call modified sdp after ice gathering state is reported as "complete" by calling setLocalDescription. I thought maybe I can chage the port numbers via this way. But after my test I saw that my assumption is wrong, because webrtc is not using my ports (of course it could be that my port could be binded by another app. ). Here is code piece :

var pConnLocalDescType = peerConnection.localDescription.type;
var data = modifyLocalDescPorts(peerConnection.localDescription.sdp); //function wich modifies port numvbes
var sd = new RTCSessionDescription({type:pConnLocalDescType, sdp:data});
mSelf.peerConnection.setLocalDescription(sd, successFunc, errorFunc);


I am trying with canary version.
Is there a different way to configure ports?

Regards
Mehmet

23 Ocak 2013 Çarşamba 22:55:40 UTC+2 tarihinde Justin Uberti yazdı:
Message has been deleted

Justin Uberti

unread,
Feb 27, 2013, 7:12:30 PM2/27/13
to discuss-webrtc
Changing the local ports isn't going to help you. You need to change the remote ports (and make sure there is something listening on those ports)


SProgrammer

unread,
Nov 28, 2013, 8:41:11 PM11/28/13
to discuss...@googlegroups.com
This is not PROFESSION, ENTERPRISE minded.

> There are 20/25 years of experienced senior networking administrators who never supports and get happy when you tell them "oh hey listen please enabled 0 to 65500 tcp and udp ports" because the webRTC developers did a quick port range development". For such a wide range of ports make the system more complicated specially in terms of behind firewall/nat 

> in my experience its best to have ports as static, so that any networking administrators can slowly adopt it and make permanent trust on those ports for example:
80 or 443 for signaling
3478 for turn/stun/ice/nat/tcp-udp hole punch
10000 to 65000 RTP/Media stream 

At list something like this or similar to this. Allowing ports from 0 to unlimited is always sound like idiot in front of many network/ICT department.



Warren McDonald

unread,
Nov 29, 2013, 7:18:46 AM11/29/13
to discuss...@googlegroups.com
There are ways to limit the ports needed by WebRTC, but for this you need to employ a TURN server that you have some control over. See some configurations below:

1. A TURN server listening on port 443 TCP or TLS, with a recent Chrome browser that will use the browser web proxy to make connections to the TCP port on the TURN server.
This will let you out of the network with just a single port 443. The compromise is that TCP is not as suitable  as UDP for RTC as latency will be higher. 
 Note: I recommend port 443 here not just because it is normally open, but because the web proxy access to TURN uses the CONNECT method (same as SSL) and most proxy servers are configured to only allow CONNECT on common HTTPS ports like 443 and 8443.     

2. TURN server listening on regular port 3478 UDP, with any WebRTC compatible browser, that will use TURN if no other connection path to the remote browser is found in the ICE candidates. So if you have not other UDP access out to connect with other browsers, then this will suffice. The compromise here is that it is not true peer to peer as all traffic will be forced through the browser. This is not so bad if every corporate site had their own TURN server, but bad if you are forcing a long triangular connection, through a distant server, which adds a lot of latency. This also applies to case 1. 

3. Allow egress to TURN 3478 and all UDP ports in the media range 49152 to 65535. This is not so offensive to Network admin as they recognise UDP as less commonly used for exploitation than TCP. This will allow full NAT hole punching and peer to peer where remote browser can negotiate that. Forget the originating port, as it doesn't really matter. Random ports are used now for pretty much all outgoing traffic.

Warren       

Kam Low

unread,
Feb 12, 2014, 10:15:58 PM2/12/14
to discuss...@googlegroups.com
I also came up against the unrealistic expectation of asking sys admins to open up all UDP ports for WebRTC.

My surveillance project uses a native C++ app as the server (for broadcasting video streams), and the browser as a client. I'm thinking that I will probably embed a pseudo TURN server in the server app which will proxy data packets to the internal application. This can be used along with an external relay server and regular host candidates to ensure a connection, and to only require that a single port is forwarded for the application.

Obviously this method won't work for browser-only apps (unless via a plugin?), but at least it solves one of my problems using WebRTC in a native app :)

Yiding Jia

unread,
Jun 30, 2014, 3:05:50 PM6/30/14
to discuss...@googlegroups.com
If you are using the native client you can pass in a custom port allocator which sets the min-max port range in which it allocates ports. When you do this it tries the ports in the range in increasing order instead of assigning randomly from all possible ports. This doesn't make everything go on one port, but should limit the number. If you don't expect many concurrent connections you can open only a small range of ports.


I think there's also UDP port multiplexing in the works to multiplex different connections on the same port, I don't know how far along that is.

Jason Suttles

unread,
Jul 2, 2021, 11:42:57 AM7/2/21
to discuss-webrtc
Hi everyone,
I'm unable to find a final range on this. 
"Allow egress to TURN 3478 and all UDP ports in the media range 49152 to 65535. This is not so offensive to Network admin as they recognise UDP as less commonly used for exploitation than TCP. This will allow full NAT hole punching and peer to peer where remote browser can negotiate that. Forget the originating port, as it doesn't really matter. Random ports are used now for pretty much all outgoing traffic."
Is this the final word? 49152 to 65535 UDP?

Thanks,
Jason
Reply all
Reply to author
Forward
0 new messages