Webrtc native code implementation - CreatePeerConnection - PortAllocator

[shyam pradeep]

Hi,

peerconnectioninterface.h

  virtual rtc::scoped_refptr<PeerConnectionInterface> CreatePeerConnection(

      const PeerConnectionInterface::RTCConfiguration& configuration,

      std::unique_ptr<cricket::PortAllocator> allocator,

      std::unique_ptr<rtc::RTCCertificateGeneratorInterface> cert_generator,

      PeerConnectionObserver* observer) = 0;

Can someone explain the application and usage of PortAllocator and RTCCertificateGeneratorInterface parameters in the function mention above?

Thanks,

Shyam

[Henrik Andreasson]

See e.g. portallocator.h for more details.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7f7b7f69-30fa-44f0-a52e-673dedbeaf40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Taylor Brandstetter]

PortAllocator is used for gathering ICE candidates, and RTCCertificateGeneratorInterface is used for generating SSL certificates for use by DTLS. If either of these arguments is null, the default "built-in" implementation will be used.

Something to note about the PortAllocator interface is that it's not very stable; we've added various things to it as we've extended our ICE implementation. However, in my experience, most developers only use this interface to inject a custom socket implementation, for example:

std::unique_ptr<cricket::PortAllocator> allocator(
    new BasicPortAllocator(new BasicNetworkManager(),
                           new CustomSocketFactory()));
auto pc = factory->CreatePeerConnection(..., std::move(allocator), ...);

So, at some point I hope to remove PortAllocator from the CreatePeerConnection method and allow just passing in the socket factory directly, which should simplify things and avoid developers relying on an interface that isn't stable. See this bug: https://bugs.chromium.org/p/webrtc/issues/detail?id=7447

Maybe now is a good time to ask: Does anyone actually subclass PortAllocator and implement their own ICE gathering logic? Or do people who use this interface just use BasicPortAllocator (the built-in implementation)?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAD2mqc42DY2YO121tXvhbaK0YCzQmMGAFPuZvKQHzbZx95rtFw%40mail.gmail.com.

[Chrystian Guth]

Hi,

Is this suitable for encrypting the transport packets with an external algorithm? Or will that mess with STUN and TURN?

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7f7b7f69-30fa-44f0-a52e-673dedbeaf40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

Yes, you could implement a "PacketSocketFactory" that creates socket objects that apply encryption before passing on data to the underlying socket. You'd just need to do the inverse on the other side, decrypting packets before they're passed along to upper layers (including ICE).

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b5688531-33cc-438e-a4b6-be1a70c66d2c%40googlegroups.com.

[shyam pradeep]

Hi,

Thanks for the response. One more clarification.

If a peer can connect to STUN only through a proxy, how to specify the proxy information in webrtc peer native code? Does PortAllocator help with that?  

Thanks,

Shyam

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/7f7b7f69-30fa-44f0-a52e-673dedbeaf40%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.

[Taylor Brandstetter]

Here's a thread where this was discussed: https://groups.google.com/d/msg/discuss-webrtc/E3FX4bp363M/7FpT-SmAEAAJ

In summary, it's possible by constructing a BasicPortAllocator and using "set_proxy". But this is something we want to remove support for, since the code is old, untested, unmaintained, different than the proxy code used by chromium, lacking features, not part of the WebRTC standard, etc.

The alternative is to create a custom BasicPacketSocketFactory that creates socket objects that go through a proxy, which is effectively what chromium does. Then your application will be responsible for the proxy code, and you can do whatever kind of proxying you need. I plan to create detailed instructions for transitioning from "set_proxy" to this approach once we're ready to do the deprecation; it's just not a high priority at the moment.

To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrtc+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/b49c7d5d-2573-4d03-8b64-a568fd177fd8%40googlegroups.com.