- From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
- Date: Fri, 6 Jul 2012 17:56:24 +0200
- To: public-webrtc@w3.org
On 07/06/2012 05:01 PM, Silvia Pfeiffer wrote: > Hi all, > > I've just subscribed to this mailing list and have had a cursory look > on the mailing list archives, but don't think I've seen the topic > discussed that I am curious about. So, apologies if it has been and do > point me to it. > > While experimenting with a simple websocket server [1] to set up a > PeerConnection [2] on a local network between two machines for a demo > at a presentation [3], I came across the need to use a STUN or TURN > server for IP address resolution. I did these experiments in Google > Chrome 19. As you probably are aware of, the PeerConnection API has changed significantly. It would be interesting to get feedback on the latest version ([4], available ar "webkitPeerConnection00" in newer versions of Chrome), if you are interested in trying it out. > > My understanding of the PeerConnection() API function is that the > first argument is passing in a public STUN or TURN server so that the > client can determine its public IP address. This then along with the > locally discovered private IPs are placed in the SDP packet and sent > across the communications channel eg google app server or node.js > server or so. In my example setup, I could have done the demo > completely within the private network, except I needed a public STUN > server to resolve the IP address. > > I would therefore like to suggest that we should be able to pass > "NONE" as a first argument to the PeerConnection() API function. This > would say "don't use a STUN server, just put the local IPs in the > packet". I think you can pass an empty string to get this behavior (at least that is how we did it in our early implementation [5] if I recall correctly). Br, Stefan > > My use case is for clients on a corporate network they may not have > outbound access to a STUN nor do they need to since they all have > direct IP reachability to each other. > > Also, I would like to suggest an improvement to the the current > implementation: if both clients have IPs in the same subnet, they > should try to connect to each other on the private IPs first before > going for the public IPs. I'm thinking of situations where the NAT > used on the network isn't smart enough for two clients on the same > network to connect to their common public SNAT IP and then have the > packets come back in. > > Best Regards, > Silvia. > > [1] http://html5videoguide.net/presentations/WebDirCode2012/websocket/websocket-server.js > [2] http://html5videoguide.net/presentations/WebDirCode2012/websocket/webrtc.html > [3] http://blog.gingertech.net/2012/06/04/video-conferencing-in-html5-webrtc-via-web-sockets/ [4] http://dev.w3.org/2011/webrtc/editor/webrtc.html [5] https://labs.ericsson.com/apis/web-real-time-communication/downloads >
Received on Friday, 6 July 2012 15:56:56 UTC