Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
STUN service for Mozilla WebRTC
1,004 views
Skip to first unread message
Ralph Giles
Oct 31, 2012, 6:35:27 PM10/31/12
to dev-...@lists.mozilla.org, Randell Jesup, mm...@mozilla.com
(discussed briefly on irc, following up here for wider reference)
The NAT traversal used by WebRTC requires in part a STUN (or TURN)
server clients can ask for their public IP address. So far, we've just
hard-coded a particular public stun server[*] into our code.
While webrtc allows web content to specify its own stun or turn server,
I always expected we would need to deploy and maintain our own stun
servers as a default option. I've volunteered to get something set up
for testing.
Because a round trip to this server is part of call setup, it's better
to have geographically distributed servers to reduce latency. I propose
we use Amazon's EC2 virtual machines for this. They're easy to get
started, Mozilla already has a relationship with them for other other
work, and they have data centres in six locations around the globe.
I've volunteered to set something up for testing. STUN is a very simple
protocol, so this should be inexpensive and easy to set up. I've opened
bug 807494[+] to track this. Please contribute any technical ideas there.
I wanted to mention the project here just so people are aware of it, and
to get feedback on the general idea.
-r
[*] e.g.
https://github.com/mozilla/mozilla-central/blob/fce8a2c197d97d0a8a443c4d59055d73b638c25f/media/mtransport/nricectx.cpp#L278
[+] https://bugzilla.mozilla.org/show_bug.cgi?id=807494
The NAT traversal used by WebRTC requires in part a STUN (or TURN)
server clients can ask for their public IP address. So far, we've just
hard-coded a particular public stun server[*] into our code.
While webrtc allows web content to specify its own stun or turn server,
I always expected we would need to deploy and maintain our own stun
servers as a default option. I've volunteered to get something set up
for testing.
Because a round trip to this server is part of call setup, it's better
to have geographically distributed servers to reduce latency. I propose
we use Amazon's EC2 virtual machines for this. They're easy to get
started, Mozilla already has a relationship with them for other other
work, and they have data centres in six locations around the globe.
I've volunteered to set something up for testing. STUN is a very simple
protocol, so this should be inexpensive and easy to set up. I've opened
bug 807494[+] to track this. Please contribute any technical ideas there.
I wanted to mention the project here just so people are aware of it, and
to get feedback on the general idea.
-r
[*] e.g.
https://github.com/mozilla/mozilla-central/blob/fce8a2c197d97d0a8a443c4d59055d73b638c25f/media/mtransport/nricectx.cpp#L278
[+] https://bugzilla.mozilla.org/show_bug.cgi?id=807494
Suhas Nandakumar (snandaku)
Oct 31, 2012, 6:53:08 PM10/31/12
to Ralph Giles, dev-...@lists.mozilla.org, mm...@mozilla.com, Randell Jesup
We also need to support API for configuring stun server into the peer connection.
Cheers
Suhas/crypt
Sent from my iPad
> _______________________________________________
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media
Cheers
Suhas/crypt
Sent from my iPad
> dev-media mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-media
Ralph Giles
Nov 1, 2012, 1:32:42 AM11/1/12
to Suhas Nandakumar (snandaku), dev-...@lists.mozilla.org, mm...@mozilla.com, Randell Jesup
On 12-10-31 3:53 PM, Suhas Nandakumar (snandaku) wrote:
> We also need to support API for configuring stun server into the peer connection.
Agreed. I believe implementing this is
> We also need to support API for configuring stun server into the peer connection.
https://bugzilla.mozilla.org/show_bug.cgi?id=786236
We'll also eventually want to collect stun prefs from the user and any
platform interfaces.
-r
0 new messages