Re: Feedback on the PeerConnection API

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.


>> 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.

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:05:35 UTC