Webrtcbin does not add peer-reflexive ice candidates

[Trey Hutcheson]

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
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Olivier Crête-3]

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

[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 
Olivier Crête
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Trey Hutcheson]

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.

On Tue, Oct 6, 2020 at 1:52 PM Olivier Crête <[hidden email]> 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

[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 
Olivier Crête
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Olivier Crête-3]

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, 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 <[hidden email]> 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

[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 

Olivier Crête

[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________

gstreamer-devel mailing list

[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 
Olivier Crête
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

[Trey Hutcheson]

Sweet. Thanks man

On Tue, Oct 6, 2020 at 3:08 PM Olivier Crête <[hidden email]> 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, 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 <[hidden email]> 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

[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 

Olivier Crête

[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________

gstreamer-devel mailing list

[hidden email]

https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

-- 
Olivier Crête
[hidden email]

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel

_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel