Trouble with RTP forwarding

[Benjamin Ionescu]

Hello,
New to this community, nice to meet you all.

My situation is that I have a Janus videoroom set up and want to do RTP forwarding with one of the publishers. I get the expected successful response. When I do a request to list forwarders, I see that indeed, the publisher whose data I want to publish is indeed listed as a forwarder.

But when I try to use ffmpeg to stream from the port I'm ostensibly forwarding to, it doesn't do anything. No data can be read at the port.

I don't think this is an ffmpeg issue, because I can stream to the port using ffmpeg directly (rather than streaming to Janus and then asking Janus to forward to that port), and then ffmpeg can read the data from that port just fine...

Thanks!

[Alessandro Toppi]

No data can be read at the port

Sounds like a networking issue, check on the wire (pcap / netcat) what is happening both on the sending host (Janus) and receiving host (ffmpeg).

[Lorenzo Miniero]

Or more simply ffmpeg is configured with an SDP that expects a specific payload type, and a different one is being sent by the Janus RTP forwarder. In that case, the fix is simple, since you can specify the payload type to use when creating a forwarder.

L.

[Benjamin Ionescu]

Indeed the payload type I put in the SDP file was wrong. But, I've fixed that now, and the final behaviour remains the same. 0 bits of data get played. I can try to look into using netcat.

[Benjamin Ionescu]

I looked at this with wireshark, and (as you both probably suspected), the port that Janus is forwarding RTP to is indeed receiving data. In other words Janus is doing its part, and it's just a question of how to read it, which I think makes this no longer a Janus issue (though when I figure out how to play the data I'll post it here!). Thanks guys.

[Benjamin Ionescu]

One thing I did notice though, is that when I stream my webcam directly to some port with ffmpeg, the packets wireshark picks up are larger in size than the ones streamed to some port via Janus's RTP forwarding.

[Benjamin Ionescu]

I solved it! Thanks so much!

The problem was this: I thought it was sufficient to choose any payload type I want in the Janus API request that initiates RTP forwarding. Then,  the SDP file which ffmpeg uses to listen to the port should specify that chosen payload type (alternatively with gstreamer, just specify the right payload type in the command from here: https://groups.google.com/g/meetecho-janus/c/Vezbp74Uy6w). However, when I check handle_info for the publisher whose stream I want to RTP forward, it already has a specified payload type. When I do RTP forwarding, I have to use that one! So if PublisherA's handle_info request's response says the pt is X, I can't ask it to do rtp_forwarding with pt Y.

[Lorenzo Miniero]

No, you don't have to use that one. As I said in my previous response, you can override the payload type when creating an RTP forwarder, as shown in the documentation too:

https://janus.conf.meetecho.com/docs/videoroom

What I meant is that obviously the payload type that you choose (or not choose, if you want to keep the original one) must be the same as the one FFmpeg will expect, so the one in the SDP you pass to FFmpeg must be the same, or otherwise FFmpeg will drop the packet. Just tell the RTP forwarder to use the payload type the FFmpeg SDP wants.

L.

[Benjamin Ionescu]

Hi,

I understood that you meant that the payload type of the RTP forwarder must match the one specified to ffmpeg in the SDP file. 

I double-checked as to why my rtp_forward request wasn't overriding the payload type like it should have. It seems I was using the request format from the legacy docs - using the key audio_pt instead of pt, and putting it at the "body" level of the request and not the "body/streams" level.
Apologies if in retrospect this might not be an interesting problem to other/future Janus users, but thanks for the help all the same.

[Lorenzo Miniero]

It is an interesting problem, I just want to make sure the correct solution is what remains for future users to see :-D

I thought we had managed to keep all legacy APIs working, so it's weird audio_pt didn't work for you when you tried: unless you were trying to forward a video stream? (in which case you should have used video_pt instead). But using the new APIs is the correct way to do it anyway.

L.

[Benjamin Ionescu]

In this case I was definitely forwarding an audio stream. By the way, a second thing, which wasn't a problem when I did RTP forwarding to a Raspberry Pi, but was a problem on a Ubuntu PC: if I don't disable ufw (the firewall), then I can't read the data from the port I'm trying to forward to.
Also, funny story. The reason I used legacy syntax in my request was because I based it off something a colleague wrote on February 11th, 2022, apparently less than 12 hours before the multistream update!