Re: [kurento-public] RTP streaming from sdp file

[Ivan Gracia]

Yeah, what you described makes sense, and it's actually what you have to do. It's basically

• Negotiate the webrtc with the browser
• Process your sdp in the RTPEndpoint
• Connect both endpoint with the connect method

Cheers,

Ivan Gracia

On Tue, Jun 23, 2015 at 2:48 AM, Antonio Rusconi <antonio...@quobis.es> wrote:

Hello Staff,

I need to send via webRTC a RTP streaming starting from RTP. I mean:

[sdpConfig.sdp] ---> [which component I have to use?] ---> WebrtcEndpoint

(just for information, the sdp file that I have is this:

v=0

o=- 0 0 IN IP4 127.0.0.1

s=No Name

c=IN IP4 10.1.2.232

t=0 0

a=tool:libavformat 56.4.101

m=video 5004 RTP/AVP 96

b=AS:10

a=rtpmap:96 H264/90000

a=fmtp:96 packetization-mode=1

 

)

For streaming video I have always used PlayerEndpoint but in this case I've tried to use as address "rtp:/127.0.0.1:5004/" but it doesn't work. Which component do you think it will better to use? I'm thinking something about

RtpEndpoint.connect(WebrtEndpoint)

Using as SDPOffer the sdp file that I have. Do you think it make sense?

Thank you for your help.

Have a good work!

--
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.

[Antonio Rusconi]

Hello Ivan,

thank you for your answer. I've developed an application but I don't receive the streaming. Everything is explained in this post, following the discussion between you and Johana:

https://groups.google.com/forum/?hl=IT#!topic/kurento/CiN79QObJWQ

Can you take a fast look when you have time to tell me if there is something wrong? I will let you know, in case you want to know I solved it.

Thank you for your time, again.

Greetings!

Antonio Rusconi

[Ivan Gracia]

Could you use this as an SDP?

v=0
o=- 0 0 IN IP4 192.168.50.1
s=
c=IN IP4 192.168.50.1
t=0 0
m=video 26540 RTP/AVP 100
a=rtpmap:100 H264/90000
a=recvonly

Change the IPs to whatever you need, but be sure that they are the same IP, as in your SDP they are different.

Ivan Gracia

[Antonio Rusconi]

Ivan, thank you for your answer.

Even with your SDP it doesn't work. About my SDP fault, I already saw and corrected with no success. Is there a way to debug deeply RtpEndpoint? I mean to understand how it receive messages and how he configure itself?

[Ivan Gracia]

How are you sending the video to the RTP endpoint?

Ivan Gracia

[levib...@gmail.com]

Hi Ivan,

I've got a question related to this same issue, wondering if you could possibly help. Using the kurento tutorial JS "kurento-webrtc-loopback-generator" I've console logged the SDP output (attached as myStream.sdp). In my browser I can see the local video and the remote video - when I try publishing the sdp however it doesn't work. Am I missing a step. I thought console logging the SDP output and attaching that to Wowza would work?

[Ivan Gracia]

No, that doesn't work. For wowza you'll need an RTP SDP , while what you get in the browser is a WebRTC SDP. There are a number of posts around the list that already speak about this.

Ivan Gracia

[Antonio Rusconi]

Hello Ivan,

I have a module based on FFMPEG that produces the sdp and it works because I can open the streaming with VLC passing the SDP. The problem is that I want to bind the streaming to Kurento, so I'm doing this way:

MODULE --> [ RtpEndpoint -> WeRrtcEndpoint ] --> Web browser

And this is the main code:

getKurentoClient(function(error, kurentoClient) {

    if (error) return callback(error);

    kurentoClient.create('MediaPipeline', function(error, pipeline) {

        if (error) return callback(error);

        createMediaElements(pipeline, function(error, rtpEp, webRtc) {

            if (error) {

                pipeline.release();

                return callback(error);

            }

            sdp_rtp = generateSDP();

            rtpEp.processOffer(sdp_rtp, function(error, sdpAnswer) {

                if (error) {

                    rtpEp.release();

                    return sendError(res, 500, error);

                }

                webRtc.processOffer(sdpOffer, function(error, sdpAnswer) {

                    if (error) {

                        pipeline.release();

                        return callback(error);

                    }

                    pipelines[sessionId] = pipeline;

                    rtpEpId[sessionId] = rtpEp;

                    connectMediaElements(rtpEp, webRtc, function(error) {

                        if (error) {

                            pipeline.release();

                            return callback(error);

                        }

                    });

                    console.log("Everything should work...");

                    return callback(null, sdpAnswer);

                });

            });

        });

    });

});

 

where the support functions are:

function createMediaElements(pipeline, callback) {

     pipeline.create('RtpEndpoint', function(error, rtpEp) {

         if (error) return callback(error);

         pipeline.create('WebRtcEndpoint', function(error, webRtc) {

             if (error) return callback(error);

             return callback(null, rtpEp, webRtc);

         });

     });

 }

 function connectMediaElements(rtpEp, webRtc, callback) {

     rtpEp.connect(webRtc, function(error) {

         if (error) return callback(error);

     });

     return callback(null);

 }

 }

 function generateSDP() {

     var sdp_rtp = '';

     /*

    //VLC DUMMY MODULE

    sdp_rtp += 'v=0\r\n';

    sdp_rtp += 'o=- 0 0 IN IP4 127.0.0.1\r\n';

    sdp_rtp += 's=No Name\r\n';

    sdp_rtp += 'c=IN IP4 127.0.0.1\r\n';

    sdp_rtp += 't=0 0\r\n';

    sdp_rtp += 'tool:libavformat 56.4.101\r\n';

    sdp_rtp += 'm=video 5004 RTP/AVP 96\r\n';

    sdp_rtp += 'b=AS:10\r\n';

    sdp_rtp += 'a=rtpmap:96 H264/90000\r\n';

    sdp_rtp += 'a=fmtp:96 packetization-mode=1\r\n';

 */

     //SDP FROM IVAN GARCIA

     sdp_rtp += 'v=0\r\n';

     sdp_rtp += 'o=- 0 0 IN IP4 127.0.0.1\r\n';

     sdp_rtp += 's=\r\n';

     sdp_rtp += 'c=IN IP4 127.0.0.1\r\n';

     sdp_rtp += 't=0 0\r\n';

     sdp_rtp += 'm=video 5004 RTP/AVP 100\r\n';

     sdp_rtp += 'a=rtpmap:100 H264/90000\r\n';

     sdp_rtp += 'a=recvonly\r\n';

     /*

     //VLC SDP

     sdp_rtp += 'v=0\r\n';

     sdp_rtp += 'o=- 15651736854259072773 15651736854259072773 IN IP4 antonio-Lenovo-G585\r\n';

     sdp_rtp += 's=Unnamed\r\n';

     sdp_rtp += 'i=N/A\r\n';

     sdp_rtp += 'c=IN IP4 127.0.0.1\r\n';

     sdp_rtp += 't=0 0\r\n';

     sdp_rtp += 'a=tool:vlc 2.1.6\r\n';

     sdp_rtp += 'a=recvonly\r\n';

     sdp_rtp += 'a=type:broadcast\r\n';

     sdp_rtp += 'a=charset:UTF-8\r\n';

     sdp_rtp += 'm=video 5004 RTP/AVP 33\r\n';

     sdp_rtp += 'b=RR:0\r\n';

     sdp_rtp += 'a=rtpmap:33 MP2T/90000\r\n';

     */

     return sdp_rtp;

 }

I've enclosed all the SDP that I'm attempting to use. Seems that RtpEndpoint doesn't start to listen the streaming.

[Ivan Gracia]

If you can produce an RTSP with ffmpeg you can consume that directly with the PlayerEndpoint, and forget about the SDP dance.

Which SDP are you feeding to the RTP endpoint? When you process the offer, you'll get the port where the RTP endpoint is expecting the video. That's where you'll need to send the video. There was quite a good post about this somewhere in the list, a user that was quite well describing the whole process, but can't recall exactly which one it was, as it is quite scattered.

Ivan Gracia

[Antonio Rusconi]

Good morning Ivan,

Of course, I am trying to use RTSP instead RTP for sending video, especially because PlayerEndpoint allows me to handle better the video but now it means to use "VLC in the middle" to pass from RTP to RTSP. 

About the post, are you talking about this one? 

https://groups.google.com/forum/?hl=IT#!searchin/kurento/rtpendpoint/kurento/CiN79QObJWQ/YS-uGhP7t9AJ

Because I've followed this and here there is the problem:

I need to tell to RtpEndpoint where is the stream and not the opposite, because the streaming is produced by another application, so I need to tell  Kurento that has to be listen a particular port and not that it has to say which port wants to listen.

Cheers,

Antonio Rusconi

[Ivan Gracia]

Ok. The only way I can come up with, and that should work (but haven't tested it) is

• invoke rtpEp.generateOffer(). You can discard that offer.
• invoke rtpRp.processAnswer(<your_fake_sdp_here>)

Give that a try, as it should be working.

Ivan Gracia

[levib...@gmail.com]

I looked through a number of WebRTC -> RTP posts that you've commented on and I believe your logic to be:

1. pipeline.create("WebRtcEndpoint")

2. pipeline.create("RtpEndpoint")

3. webRtc.connect(Rtp)

4. webRtc.processOffer(offer)

5. Rtp.processOffer(sdp)

This is what I'm using for sdp:

v=0
o=- 0 0 IN IP4 52.25.217.148
s=
c=IN IP4 52.25.217.148

t=0 0
m=video 26540 RTP/AVP 100
a=rtpmap:100 H264/90000
a=recvonly

KMS is returning the RTP SDP answer as:

v=0

o=- 0 3646067584 IN IP4 52.25.217.148

s=Kurento Media Server

c=IN IP4 52.25.217.148

t=0 0

m=video 54534 RTP/AVP 100

a=rtpmap:100 H264/90000

a=sendonly

a=ssrc:3090531899 cname:user4024858172@host-c36acd93

I've tried that SDP answer in VLC and Wowza and both appear blank. I believed the way I was going about creating the RTP SDP was correct. Any help in the right direction would be appreciated. 

[Ivan Gracia]

Not really. What I meant was that you can feed the SDP from your external RTP source, as answer to the kms’s RTP generateOffer. Since you are negotiating SDP’s, which are basically a declaration of intentions/capabilities, if you feed your SDP to the processAnswer, your RTP endpoint in KMS should understand that the only candidate available in the SDP you’ve fed him is in the appropriate port where you are sending the video. If you do it the other way around, what you really are doing is you are instructing the RTP ep in KMS that it need to send the video to that port, so you are basically obtaining the opposite as expected.

Don’t know if that clarified things a bit… Just in case, suppose you have a mangledSdpForRtp string. You should have to

rtp.createOffer()
rtp.processAnswer(mangledSdpForRtp)

And that should put your KMS rtp ep listening in that port.

Ivan Gracia

[Israel Robotnick]

I'm having the same problem (rtp with a specific port that cant negociate so i need the kurento to listen to a specific port).

I did as you wrote:
rtpendpoint.generateoffer()
rtpendpoint.processAnswer(cameraSDP, sdpAnswer)

But the sdpAnswer is still a random port from KMS and other things that werent on the cameraSDP.

Is there another way to this?
Many of these old apps\cameras just throw their rtp to some port, usually without even an sdp. (I created it for them and its working on vlc)

Thanks,
Israel Robotnick

[Israel Robotnick]

P.S: Even the ip on the sdpAnswer is different from what i gave kurento on the camera sdp. Not only the port.

[Richard Williamson]

There was a conversation about this on the group from a while back which seemed to have the answer that it’s not possible to specify a port - the port will always be randomly allocated.

Sent from my iPhone

> On 19 May 2020, at 17:12, Israel Robotnick <israel.r...@gmail.com> wrote:
>
> P.S: Even the ip on the sdpAnswer is different from what i gave kurento on the camera sdp. Not only the port.

>
> --
> 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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/kurento/8a6d2869-100b-497b-9d06-f2a8b1dd1dee%40googlegroups.com.

[Israel Robotnick]

But its such an important feature and probably not too hard to implement.

Almost makes the who rtpendpoint unusable, all of my rtp feeds arrive on a port without me abling to change it. And what about multicast? That isnt only for kurento.

So strange