webrtcbin ice-state-connection doesn't change to 'disconnected'

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

webrtcbin ice-state-connection doesn't change to 'disconnected'

givip
I have a pipeline with only 'Data Channel',
I can successfully establish connection with remote peer and even exchange
data (string).

When I close connection on the other side, GStreamer hasn't any reaction.

I tried to poll any state propertires in webrtcbin (every 5 seconds):

gint state;
g_object_get(webrtcbin, "connection-state", &state, NULL);
GST_DEBUG("Connection State webrtcbin: %d", state);

gint sig_state;
g_object_get(webrtcbin, "signaling-state", &sig_state, NULL);
GST_DEBUG("Signalling State webrtcbin: %d", sig_state);

gint ice_state;
g_object_get(webrtcbin, "ice-connection-state", &ice_state, NULL);
GST_DEBUG("ICE State webrtcbin: %d", ice_state);

gint ice_gath_state;
g_object_get(webrtcbin, "ice-gathering-state", &ice_gath_state, NULL);
GST_DEBUG("ICE Gathering State webrtcbin: %d", ice_gath_state);


But all state remain 0 always.


A little bit different situation with 'Media channel':

'connection-state' and 'signalling-state' are the same 0;

'ice-connection-state', 'ice-gathering-state' changes to 2 when CONNECTED
and remains in this state even remote peer had been disconnected.




--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: webrtcbin ice-state-connection doesn't change to 'disconnected'

Matthew Waters
The state properties are currently best effort and do not always reflect
the actual state due to issues with the dependant libraries.

e.g
- libnice currently doesn't signal disconnection properly (even if the
enum value is in its API)
- the GStreamer dtls have no state field which means the algorithm that
computes 'connection-state' (from the webrtc spec) always results in 'new'
- the ICE transports associated with the data-channel is used when
computing any state which is an oversight.

In short, there are issues with the states and patches are welcome.


On 26/10/19 12:50 am, givip wrote:

> I have a pipeline with only 'Data Channel',
> I can successfully establish connection with remote peer and even exchange
> data (string).
>
> When I close connection on the other side, GStreamer hasn't any reaction.
>
> I tried to poll any state propertires in webrtcbin (every 5 seconds):
>
> gint state;
> g_object_get(webrtcbin, "connection-state", &state, NULL);
> GST_DEBUG("Connection State webrtcbin: %d", state);
>
> gint sig_state;
> g_object_get(webrtcbin, "signaling-state", &sig_state, NULL);
> GST_DEBUG("Signalling State webrtcbin: %d", sig_state);
>
> gint ice_state;
> g_object_get(webrtcbin, "ice-connection-state", &ice_state, NULL);
> GST_DEBUG("ICE State webrtcbin: %d", ice_state);
>
> gint ice_gath_state;
> g_object_get(webrtcbin, "ice-gathering-state", &ice_gath_state, NULL);
> GST_DEBUG("ICE Gathering State webrtcbin: %d", ice_gath_state);
>
>
> But all state remain 0 always.
>
>
> A little bit different situation with 'Media channel':
>
> 'connection-state' and 'signalling-state' are the same 0;
>
> 'ice-connection-state', 'ice-gathering-state' changes to 2 when CONNECTED
> and remains in this state even remote peer had been disconnected.
>
>
>
>
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> 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

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: webrtcbin ice-state-connection doesn't change to 'disconnected'

Olivier Crête-3
Hi,

If you enable the keepalive-conncheck property, you get a slightly non compliant behavior from libnice, it sends connchecks even after the connection is established, but that will give you a state change on disconnection.

Olivier

On October 28, 2019 10:48:17 p.m. GMT+01:00, Matthew Waters <[hidden email]> wrote:

>The state properties are currently best effort and do not always
>reflect
>the actual state due to issues with the dependant libraries.
>
>e.g
>- libnice currently doesn't signal disconnection properly (even if the
>enum value is in its API)
>- the GStreamer dtls have no state field which means the algorithm that
>computes 'connection-state' (from the webrtc spec) always results in
>'new'
>- the ICE transports associated with the data-channel is used when
>computing any state which is an oversight.
>
>In short, there are issues with the states and patches are welcome.
>
>
>On 26/10/19 12:50 am, givip wrote:
>> I have a pipeline with only 'Data Channel',
>> I can successfully establish connection with remote peer and even
>exchange
>> data (string).
>>
>> When I close connection on the other side, GStreamer hasn't any
>reaction.
>>
>> I tried to poll any state propertires in webrtcbin (every 5 seconds):
>>
>> gint state;
>> g_object_get(webrtcbin, "connection-state", &state, NULL);
>> GST_DEBUG("Connection State webrtcbin: %d", state);
>>
>> gint sig_state;
>> g_object_get(webrtcbin, "signaling-state", &sig_state, NULL);
>> GST_DEBUG("Signalling State webrtcbin: %d", sig_state);
>>
>> gint ice_state;
>> g_object_get(webrtcbin, "ice-connection-state", &ice_state, NULL);
>> GST_DEBUG("ICE State webrtcbin: %d", ice_state);
>>
>> gint ice_gath_state;
>> g_object_get(webrtcbin, "ice-gathering-state", &ice_gath_state,
>NULL);
>> GST_DEBUG("ICE Gathering State webrtcbin: %d", ice_gath_state);
>>
>>
>> But all state remain 0 always.
>>
>>
>> A little bit different situation with 'Media channel':
>>
>> 'connection-state' and 'signalling-state' are the same 0;
>>
>> 'ice-connection-state', 'ice-gathering-state' changes to 2 when
>CONNECTED
>> and remains in this state even remote peer had been disconnected.
>>
>>
>>
>>
>> --
>> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
>> _______________________________________________
>> 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