Webrtcbin does not add peer-reflexive ice candidates

[Trey Hutcheson]

Sweet. Thanks man

On Tue, Oct 6, 2020 at 3:08 PM Olivier Crête <olivier.crete at collabora.com>
wrote:

> On Tue, 2020-10-06 at 14:11 -0500, Trey Hutcheson wrote:
>
> Stun can be difficult. In our lab, sometimes the outbound stun requests
> from the remote peer (the browser) fail because of snat exhaustion, or
> simply by rate limiting of the stun server. When this happens, the only
> candidate to make it to our side is an mDNS candidate.
>
> I'd like to confirm your assertion that the peer reflexive candidate is
> added internally by libnice, but I'm using the rust gstreamer bindings (and
> the libnice crate is out of date and doesn't expose many of the c
> functions) and mostly opaque to me. I can, however, confirm that the remote
> side successfully establishes a connected pair, but the local side
> (webrtcbin) never advances the ice-connection-state
> beyond GST_WEBRTC_ICE_CONNECTION_STATE_CHECKING.
>
>
>
> If you run it with G_MESSAGES_DEBUG=libnice, it should spew out a bunch of
> debugging information.
>
> Actually, reading from the code, the conn checks don't actually start
> inside libnice until at least one remote candidate has been set. But
> reading draft-ietf-ice-trickle-21
> <https://tools.ietf.org/html/draft-ietf-ice-trickle-21>, I think we
> should start it immediately when the credentials are set
>
> I've made an MR with  this entirely untested branch
> https://gitlab.freedesktop.org/libnice/libnice/-/merge_requests/166 that
> might fix your problem.
>
> Olivier
>
>
> On Tue, Oct 6, 2020 at 1:52 PM Olivier Crête <olivier.crete at collabora.com>
> wrote:
>
> Hi,
>
> The peer reflexive candidates already get added internally inside libnice,
> the "new-remote-candidate" signal is just there for debugging and logging
> at the application level.
>
> So in theory, if you already set the remote credentials, I believe it
> should work. That said, this is a bit of code that has move quite a bit in
> the last few libnice releases. And there may very well be a bug in there.
>
> In practice, I expect you'd always at least get a "host" candidate from
> the other side.
>
> Olivier
>
> On Tue, 2020-10-06 at 13:10 -0500, Trey Hutcheson wrote:
>
> If a remote peer does not trickle in any resolvable candidates (for
> example, their stun binding fails), then there is no ice connectivity, and
> therefore, no actual media flows.
>
> However, if webrtcbin returns resolvable candidates, the browser will
> attempt to perform stun bindings against these candidates. When that
> happens, libnice's NiceAgent will emit the
> "initial-binding-request-received" signal, and it will also discover the
> remote side as a peer reflexive candidate, and emit the
> "new-remote-candidate-full" signal. In the case of a peer reflexive
> candidate, ice connectivity could be established if this candidate were
> added back to the ice agent's list of remote candidates.
>
> _______________________________________________
>
> gstreamer-devel mailing list
>
> gstreamer-devel at lists.freedesktop.org
>
>
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> --
>
>
> Olivier Crête
>
> olivier.crete at collabora.com
>
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
> _______________________________________________
>
> gstreamer-devel mailing list
>
> gstreamer-devel at lists.freedesktop.org
>
>
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
>
> --
>
> Olivier Crête olivier.crete at collabora.com
>
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20201006/31772969/attachment.htm>