Receiver not send RtcpRr

[Meonardo]

I am using a modified version of media-receiver/main.cpp to receive media stream from a SFU, the media data
received successfully, but when I use wireshark to capture the traffic, I can not found any RTCP packet to the server, is this an issue or do I need send the RtcpRr manually?

Here is my sdp:

created offer SDP:
v=0
o=rtc 2455670017 0 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE video
a=group:LS video
a=msid-semantic:WMS *
a=ice-options:ice2,trickle
a=fingerprint:sha-256 C6:19:BE:9D:3E:2F:3D:84:94:91:82:38:39:4B:F2:9E:BD:4A:48:67:A6:CE:E9:EA:E3:66:85:59:C8:40:4E:E1
m=video 64199 UDP/TLS/RTP/SAVPF 96
c=IN IP4 172.16.30.195
a=mid:video
a=recvonly
a=rtcp-mux
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 goog-remb
a=fmtp:96 profile-level-id=42e01f;packetization-mode=1;level-asymmetry-allowed=1
a=setup:actpass
a=ice-ufrag:BJQK
a=ice-pwd:6b9jgLhcLdW0qa8IR2Pbjq
a=candidate:1 1 UDP 2122317823 172.16.30.195 64199 typ host

================================================================

received answer SDP:
v=0
o=107545983070848 2 IN IP4 0.0.0.0
s=PlaySession
t=0 0
a=ice-lite
a=group:BUNDLE video
a=msid-semantic: WMS baobao/baobao
m=video 9 UDP/TLS/RTP/SAVPF 96
c=IN IP4 0.0.0.0
a=ice-ufrag:141p5770
a=ice-pwd:4g5234w25i1a22928z5y70bh2hp64bz8
a=fingerprint:sha-256 71:5A:06:95:8B:FE:B4:7C:C7:F2:23:34:89:45:AF:03:4E:2C:58:C1:6E:F4:8E:14:24:45:68:8A:5A:AE:64:6A
a=setup:passive
a=mid:video
a=sendonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 H264/90000
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=fmtp:96 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=ssrc:214313045 cname:r698al9p5ax084ca
a=ssrc:214313045 label:video-7t22790o
a=candidate:0 1 udp 2130706431 172.16.30.48 8000 typ host generation 0
a=candidate:1 1 udp 2130706431 172.17.0.1 8000 typ host generation 0

[Meonardo]

If I use the Chrome as my receiver I can see the RR(201) packets are send to the SFU.

[paullouisageneau]

RTCP RRs are sent by RtcpReceivingSession. You need to add it on the track with Track::setMediaHandler() like in the media-receiver example.

[Meonardo]

Thanks for your reply, I already added the RtcpReceivingSession to the Track:

auto video_recv_session = std::make_shared<rtc::RtcpReceivingSession>();
video_track_->setMediaHandler(video_recv_session );

[paullouisageneau]

OK, then please check you send Sender Reports on sender side, currently it waits for SR to send RR. It can be done with RtcpSrReporter like in the streamer example.

[Meonardo]

Is the RtcpReceivingSession implementation different then WebRTC in Chrome?

The RtcpReceivingSession on the recv side actually already set, I can confirm the broswer was sending the RR to SFU.

[paullouisageneau]

Yes it is, that is something which should be fixed. However, you did not answer my question, does the SFU send RTCP SRs?

[Meonardo]

does the SFU send RTCP SRs?

No.

After some digging, the SFU actually wait for the receiver to send RR first then reponse SR to the receiver,
this is the problem.
I also try to send RR to SFU manually to initial the RR-SR process from the receiver side, it works but there is another problem: too much traffic of the RTCP packets and lead the high CPU usage.