Invoking "add-local-ip-address" on GstWebRTCICE

Fri Jul 17 11:59:59 UTC 2020

Great. Thanks.

Good job on writing this, by the way. Well done, mate.

On Fri, Jul 17, 2020 at 2:56 AM Matthew Waters <ystreet00 at gmail.com> wrote:

> On 17/7/20 4:07 pm, Ben Rush wrote:
>
> Ok. So to be clear: I'm okay with master as-is if I'm able to specify the
> IP/port range manually. I don't necessarily need the merge request I
> mentioned above if the existing code in master is able to handle my need
> for explicitly declaring the IP and port for an ICE candidate (which it
> appears to). It's my understanding the merge request above (after further
> inspection) is only concerned with port RANGES, not necessarily port/IP
> pairs. I really only have one IP/port pair in my scenario anyway.
>
> I think it makes complete sense to place the port properties on
> GstWebRTCICE.
>
> As a corollary, what really matters to me is defining the port ranges
> involved for my firewall rules. I'm seeing that (perhaps?) port ranges
> 40000-65535 are randomly selected for those involved in ICE when a TURN
> server isn't involved. I tried digging into the gstreamer and libnice code
> to understand where the exact port ranges are coming from, but I couldn't
> narrow it down. Worst case scenario, I'm fine relying on the automatic ICE
> port range identification so long as I know the min/max ranges involved.
> Any idea on what that might be?
>
>
> Yes, port ranges are that MR.  A single value can also be expressed
> through a range.
>
> libnice will choose from the min/max port range if specified, otherwise, 0
> is passed as the port number which means the kernel randomly generates an
> available port.
>
> The add-local-ip-address implementation in libnice explicitly sets the
> NiceAddress port to 0 so will get the random treatment unless min/max port
> are specified.
>
> Cheers
> -Matt
>
> On Thu, Jul 16, 2020 at 11:49 PM Matthew Waters <ystreet00 at gmail.com>
> wrote:
>
>> On 17/7/20 2:41 pm, Ben Rush wrote:
>>
>> Yes, you nailed it: I'm on an older release. gst-inspect showed that the
>> property didn't exist. I was hyper-focused on the latest source and failed
>> to inspect my local branch. I had actually thought about that over dinner
>> today while thinking about the post I made to this group. Thanks for
>> confirming it for me.
>>
>> Can you explain "it needs updating to place the necessary properties on
>> the ICE object rather than on webrtcbin itself"? I'm willing to do the leg
>> work, I'm just not sure what you mean precisely.
>>
>>
>> I mean, instead of adding the port properties on webrtcbin as well, they
>> should only be on the GstWebRTCICE object.  We're trying the keep the API
>> on webrtcbin limited to only the webrtc PeerConnection API if at all
>> possible. It also needs a manual rebase (probably not hard) and the review
>> comment addressed.
>>
>> On Thu, Jul 16, 2020 at 9:47 PM Matthew Waters <ystreet00 at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On 17/7/20 7:55 am, Ben Rush wrote:
>>>
>>> Admittedly I seem to occasionally get myself confused when it comes to
>>> navigating objects and their properties in the GLib Object System. Often I
>>> find myself exploring sample code and piecing together an understanding
>>> from that. However, I can't seem to get at what I need here and am hoping
>>> someone can help.
>>>
>>> First, the main problem I'm attempting to solve is forcing WebRTCBin to
>>> restrict the addresses and ports used when generating ICE candidates. I'm
>>> behind a firewall, don't want to / can't use a TURN server in my specific
>>> scenario, and so would like to specify the exact ports / addresses to be
>>> considered as candidates. From examining the source, it appears as though
>>> my only way to do that is to rely on emitting this signal with the address
>>> information (IP/port):
>>>
>>>
>>> https://gstreamer.freedesktop.org/documentation/webrtc/index.html?gi-language=c#GstWebRTCICE::add-local-ip-address
>>>
>>> So, I assume I'll need to call g_signal_emit_by_name() with the proper
>>> arguments, one of which being the object to receive the signal. All well
>>> and good, except for the fact that the receiving object is of type
>>> GstWebRTCICE. So, I need to get that object. Per this documentation:
>>> https://gstreamer.freedesktop.org/documentation/webrtc/index.html?gi-language=c#webrtcbin:ice-agent it
>>> appears to be a property on the webrtcbin element.
>>>
>>> So, I have this code:
>>>
>>>     _pipeline = gst_parse_launch("webrtcbin bundle-policy=max-bundle
>>> name=sendrecv "
>>>         "autoaudiosrc ! audioconvert ! audioresample ! queue ! opusenc !
>>> rtpopuspay ! "
>>>         "queue ! " RTP_CAPS_OPUS "97 ! sendrecv. ", &error);
>>> .....
>>>     _webRtcElement = gst_bin_get_by_name(GST_BIN(_pipeline), "sendrecv");
>>> .....
>>>             GValue value = { 0, };
>>>             g_value_init(&value, G_TYPE_OBJECT);
>>>             g_object_get_property(G_OBJECT(_webRtcElement), "ice-agent",
>>> &value);
>>>             GObject* object = (GObject*)g_value_get_object(&value);
>>>
>>> But the value of the object is always null. What am I doing wrong? How
>>> am I navigating this improperly?
>>>
>>>
>>> Do you have a version of GStreamer that includes that?  The 'ice-agent'
>>> property on webrtcbin and 'add-local-ip-address' on gstwebrtcice is only
>>> available in master and is not in any released version yet.
>>>
>>> Also, I noticed this merge request:
>>> https://gitlab.freedesktop.org/gstreamer/gst-plugins-bad/-/issues/856.
>>> I'm hoping this doesn't mean forcing a particular IP/port is even possible
>>> with webrtcbin.
>>>
>>>
>>> This MR would probably by your best bet but it needs updating to place
>>> the necessary properties on the ICE object rather than on webrtcbin itself.
>>>
>>> Cheers
>>> -Matt
>>>
>>> Thanks in advance.
>>>
>>> _______________________________________________
>>> gstreamer-devel mailing listgstreamer-devel at lists.freedesktop.orghttps://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/gstreamer-devel/attachments/20200717/40a2a7eb/attachment.htm>