W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2012

Re: Feedback on the PeerConnection API

From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Date: Fri, 6 Jul 2012 18:11:33 +0200
Message-ID: <4FF70E35.7090500@ericsson.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: "public-webrtc@w3.org" <public-webrtc@w3.org>
On 07/06/2012 06:04 PM, Silvia Pfeiffer wrote:
> Hi Stefan,
> Thanks for the feedback!
> On Fri, Jul 6, 2012 at 5:56 PM, Stefan Hakansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> 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.
> I saw it, but haven't experimented with it yet, so can't really say.
> It seems a bit more complicated, but if it provides more detailed
> control over what happens, then that's likely a good thing.
>>> 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).
> Ah, that's good. But it doesn't seem to be standardised in this way.
> It would be good if it was.

I agree, a way to not use any STUN or TURN server should be specified.

>>> 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.
> I also don't think the new API standardises this part, so would be
> keen to hear if this would be a possibility to include, too.

That is something we need to look into (personally I have to little 
knowledge about ICE; but probably the host (local) candidates would have 
highest priority and thus be used as first choice).

> Thanks,
> 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 16:12:05 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC