Any news about your webrtc gstreamer plugin ?

[adrien....@gmail.com]

Heya !

You developped a plugin for gstreamer acting like a webrtc client, so we should receive/send media stream from/to browsers.
DTLS-SRTP seems to be implemented in gstreamer 1.2.

So I was wondering what is your roadmap about this plugin ? I know webrtcendpoint is already functionning with Kurento, but I already have a gstreamer-based server application, I would only need  webrtcsrc/webrtcsink.

Thank you for your very good work,

Cordially,
Adrien

[Miguel París Díaz]

Hello Adrien,

There is some work done about DTLS-SRTP but it is frozen and it is not yet in GStreamer, so we decided to use this code to build our own WebRTCEndpoint instead of waiting that it will be included in GStreamer.

WebRTCEndpoint has an easy way to manage SDPs, and it is configured internally basing in offer/answer negotiation, so it facilitate the development a lot.
It can be connected following the same way. Here you have good examples that can help you to know how to connect this Kurento element with other GStreamer elements:
https://github.com/Kurento/gst-kurento-plugins/blob/develop/tests/check/element/webrtcendpoint.c#L247

Moreover, I attach the description taken from gst-inspect. I hope it helps you for your purpose ;)

Best.

--
You received this message because you are subscribed to the Google Groups "kurento" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kurento+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Miguel París Díaz
------------------------------------------------------------------------
Computer/Software engineer.
Researcher in http://www.kurento.org
http://twitter.com/mparisdiaz
------------------------------------------------------------------------

[adrien....@gmail.com]

Hi,

Thank you for your very helpful answer.
I did tried to play with your webRTCEndpoint, without any luck for now, but I admit I didn't tried hard. I'll use the week-end to compile and play with the plugin.

I didn't know that DTLS-SRTP was frozen, I really though that it was in Gstreamer 1.2. That's too bad, I though I could use very soon the webrtc plugin as a "standard" plugin.

Well, you made my day anyway.

Thank you,
Adrien

[adrien....@gmail.com]

Ok, I managed to compile and install the webrtcendpoint element, gst-inspect did not blacklist it, and gstreamer allows me to make the element and add it into a pipeline.

Unfortunately, I don't know how to generate a sdp offer from it. From your examples and tests, you use a constant string as your sdp message to be parsed and set into the webrtcendpoint element, but you said "WebRTCEndpoint has an easy way to manage SDPs, it is configured internally basing in offer/answer negotiation". So I may misunderstood something here. Anyway, I'm quite lost on how to use the webrtcendpoint gstelement.

So I guess I have to play a little bit with sdp messages afterall ?
How about ice ? How is it handled through stun-server property and custom sdp messages ?

Thank you for your advices,

Adrien

[Miguel París Díaz]

Hello Adrien,
webrtcendpoint is an element that allows connecting a gstreamer pipeline with another peer using WebRTC standar. As its own name says, it must be located at the end and at the beginning of the media chain and it sends/receives audio and video to/from another WebRTC peer (that can be a browser or another webrtcendpoint).

Imagine that you want to connect two webrcendpoints. One of them (A) sends video to the other one (B). So you will have two simple pipelines connected through WebRTC:

videotestsrcA -> webrtcendpointA  ----> WebRTC standar ----> webrtcendpointB -> autovideosinkB
This example is this: https://github.com/Kurento/gst-kurento-plugins/blob/develop/tests/check/element/webrtcendpoint.c#L98

The "connection" between webrtcendpointA and webrtcendpointB is done performing the SDP negotiation. This must be managed in the next way:
1) Each webrtcendpoint has a SDP pattern to generate offers and answers. This pattern basically indicates the media capabilities that the webrtcendpoint will have (audio and video codecs, direction of the media flow as sendonly, recvonly and sendrecv, etc.). To set it:

g_object_set (sender, "pattern-sdp", pattern_sdp, NULL);

Also, you can add info about STUN server using stun-server and stun-server-port properties.

2) Supposing that A starts the SDP negotiation, it generates an offer. The offer has the media info and connection info of A (ICE candidates)

g_signal_emit_by_name (sender, "generate-offer", &offer);

3) The offer is sent to B in a any way (this is named signaling).

4) Using the offer, B generates a SDP answer. In this step webrtcendpoint B is configured and it is ready to receive video. The answer has the media info and connection info of B (ICE candidates)

g_signal_emit_by_name (receiver, "process-offer", offer, &answer);

5) The answer is sent to A using the signaling layer.

5) A processes the SDP answer. In this step webrtcendpoint A is configured and it starts sending video to B

 g_signal_emit_by_name (sender, "process-answer", answer);

6) Video flows from A to B

This is a short and schematic explanation. But it is interesting that you know more about SDP.
A good point to start is wikipedia: http://en.wikipedia.org/wiki/Session_Description_Protocol
For the complete info see the RFC: http://tools.ietf.org/html/rfc2327

Understanding Kurento terminology can help you to know better the webrtcendpoint:
http://www.kurento.org/kurento-media-element-toolbox

I have also attached the gst-inspect doc of webrtcendpoint.

I hope this helps you ;).
Best.

[adrien....@gmail.com]

That was a very nice explanation.

I misguided myself as the webrtcendpoint has "stun-server" and "stun-server-port" properties (which will add ICE candidates in the SDP message). I though that SDP generation was done by the webrtcendpoint itself according to its pads and surrounding caps. Well, that would be too easy :D

I've already written a small python WebRTC signaling server (with Tornado websocket) so two browsers do stream to one another. So I did not have to generate the DSP offers/answers. But for scalability reasons (and for fun) I want to code a "webrtc relay server" with gstreamer thanks to your webrtc element. So I guess I have to dive inside SDP message.

By the way, using python gobject introspection bindings, there are many segfault with GstSdp (alone) as well when trying to apply the "sdp-pattern" property to a webrtcendpoint element. Do not worry, you can't do anything (a bug in gir I suppose)... Just to tell readers that I do not advice Python with webrtcendpoint for now.

Keep up the good work and the good support !

Adrien