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

Re: Feedback on the PeerConnection API

From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 6 Jul 2012 09:46:18 -0700
Message-ID: <CABcZeBNPxwLNnQXz9N_v2Nc79wpkp4MamyHvrU85OiX0Hgyx1w@mail.gmail.com>
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
Cc: Silvia Pfeiffer <silviapfeiffer1@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
On Fri, Jul 6, 2012 at 9:11 AM, Stefan Hakansson LK
<stefan.lk.hakansson@ericsson.com> wrote:
> 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.

You should be able to just not provide servers.


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

ICE will generally favor host candidates.

-Ekr
Received on Friday, 6 July 2012 16:47:25 UTC

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