Very important bug on new RTP Forward

[Mariano Facundo]

When we changed to the new RTP Forward API, it stopped working for streams coming from firefox and mobile devices, it only kept working for chrome.

The response of the forward is success, but the forward does not take place correctly.

With the same version, we rolled back to old RTP Forward API and it works properly.

So, there must be any bug there. I will try to study in further now, we are still fixing all our production systems, once I complete that, I will try to make time and debug this

[Mariano Facundo]

Ok, so here's the conclusions,

RTP Forward for me at least is not working when I make use of the new API if I forward a stream that comes from Firefox (or some mobile devices) but it works if it comes from chrome.

If I switch and make use of the old api (on the same janus build), it works always.

I tried to read the code of the videoroom plugin but I'm getting lost and can't find what's causing that issue.

This is the request we use for forwarding with the new API:

***********************************

request: "rtp_forward",
room: this.videoRoomId,
publisher_id: this.publisherId,
host: "127.0.0.1",
host_family: "ipv4",
streams: [
{
port: Number(this.audioPort),
pt: 111,
mid: this.audioStream.mid,
},
{
port: Number(this.videoPort),
pt: videoPt,
mid: this.videoStream.mid,
},
],

********************************

audioStream and videoStream mids are well defined, and come directly from the corresponding data from Janus.

For the old api we use this request:

*************************************

request: "rtp_forward",
room: this.videoRoomId,
publisher_id: this.publisherId,
host: configProvider.CURRENT_IP_FOR_RTP_FORWARD,
host_family: "ipv4",
audio_port: Number(this.audioPort),
video_port: Number(this.videoPort),
audio_pt: 111,
video_pt: videoPt,

*************************************

With the old api, it always work, with the new one only for chrome, so it's making nonsense. Maybe the problem is not the RTP Forwarder itself and it's in the reception of the streams or it's me using things incorrectly.

[Lorenzo Miniero]

Just used the new API with Firefox and it worked just fine here. I used this request from the VideoRoom demo page, to forward to the sample mountpoint:

sfutest.send({
        message: {
                request: "rtp_forward",
                room: myroom,
                publisher_id: myid,
                secret: "adminpwd",
                host: "127.0.0.1",
                streams: [
                        { mid: "0", port: 5002 },
                        { mid: "1", port: 5004, rtcp_port: 5005 }
                ]
        }
});

L.

[Mariano Facundo]

It shows as it's forwarding, ffmpeg launches, but it's unable to process anything when the forwarded stream comes from firefox. I am posting more research as I make it

[Lorenzo Miniero]

I think I may have found out the problem: it looks like the "pt" to force a payload type is not working as expected when using the new API. My guess is that the payload type FFmpeg is expecting is X, which is what Chrome uses already while other endpoints (e.g., Firefox) use a different one: as a result, FFmpeg receives RTP packets with an unknown payload type and discards it. I'll check why this is happening, and come with a fix shortly in case.

L.

[Mariano Facundo]

Makes sense!

Just in case, I created the sample object I am posting for new api

{"janus":"message","body":{"request":"rtp_forward","room":336556928400892,"publisher_id":5739562,"host":"127.0.0.1","host_family":"ipv4","streams":[{"port":21536,"pt":111,"mid":1},{"port":29970,"pt":102,"mid":0}]}}

[Lorenzo Miniero]

I found some attributes (pt but not only) that were read from the wrong JSON parent: this should be fixed in the latest commit I made.

L.

[Mariano Facundo]

Awesome,

I tried to debug and fix but got lost in the code, sorry for that!

I noticed from your example you sent that you use RTCP and I could not find a way to use RTCP with ffmpeg, so I became curious on what you use in your tests  to receive the RTP Forwards (if you're doing a transcode/republishing to rtmp and CLI if that's possible).

 I'll wait snap to take your latest commit as I install through snap Janus-Gateway and test the new commit there!

Thanks!

[Lorenzo Miniero]

We do something peculiar for RTCP, that's done specifically to work with mountpoints from the Streaming plugin.

L.