Open atoppi opened 2 years ago
Let's start by calling out that this is not an area I'm really familiar with.
I see where pion is starts handling the RTX flow as part of the SDP setup. Pion then passes those details along to the RTPReceiveParameters
which end up flowing into the RTPReceiver.Receive
method and into startReceive
which handles the RTX SSRC. The call to streamsForSSRC
results in a call to BindRemoteStream
on the interceptor interface. When the ReceiverInterceptor
handles that call it adds the stream to the set of streams to send Receiver Reports to.
So that's the flow that's resulting in RTCP receiver reports being sent.
I don't know much about using RTX streams with Pion, but it definitely looks like there's at least support for that setup in the session parsing and setup. I wonder if the comment you linked to is out of date and this is now supported?
It seems to me the actual issue may be that the SDP answer is missing an indication that the RTX stream is supported and setup. Or that RTX support is half baked and we should stop passing the RTX SSRC into BindStream if we're not ready to handle them.
hello @boushley thanks for the detailed analysis
I don't know much about using RTX streams with Pion, but it definitely looks like there's at least support for that setup in the session parsing and setup. I wonder if the comment you linked to is out of date and this is now supported?
when trying to offer rtx from pion, this is the outcome
as you can see only one SSRC is being announced and there is no a=ssrc-group:FID
, so I guess that rtx is not being negotiated like e.g. does Chrome/FF.
As a consequence, I'm disabling rtx support by not registering the codec but that leads to the original issue.
fyi I was unable to reproduce on #2231
Getting hit again by the same issue :-( It looks like the triggering condition is disabling rtx in the pion media engine (e.g. not registering rtx support).
pion/webrtc v3.1.46
The scenario is still the same:
[Mon Dec 12 14:52:03 2022] [1726755082988956] Dropping RTCP packet with unknown SSRC (2297016547)
[Mon Dec 12 14:52:04 2022] [1726755082988956] Dropping RTCP packet with unknown SSRC (2297016547)
[Mon Dec 12 14:52:05 2022] [1726755082988956] Dropping RTCP packet with unknown SSRC (2297016547)
[Mon Dec 12 14:52:06 2022] [1726755082988956] Dropping RTCP packet with unknown SSRC (2297016547)
[Mon Dec 12 14:52:07 2022] [1726755082988956] Dropping RTCP packet with unknown SSRC (2297016547)
[Mon Dec 12 14:52:08 2022] [1726755082988956] Dropping RTCP packet with unknown SSRC (2297016547)
With rtx on, the negotiation completes but the feature will not actually work since Janus does not support same-ssrc rtx. On the other hand pion will not send RTCP to the rtx SSRC in this case.
The only solution I found is removing the offending SSRC lines from the remote SDP before setting remote desc in pion.
Your environment.
What did you do?
I'm sending an offer from Janus that contains
rtx
for videoSDP offer (janus)
``` v=0 o=- 1651154116641094 1 IN IP4 192.168.1.174 s=Mountpoint 10000 t=0 0 a=group:BUNDLE a v a=ice-options:trickle a=fingerprint:sha-256 82:8E:EA:3D:0D:52:F1:3B:02:0C:A7:5F:10:E1:DD:9D:4C:40:1D:13:8C:AE:19:FA:86:C7:DF:6A:A3:3E:23:12 a=extmap-allow-mixed a=msid-semantic: WMS janus m=audio 9 UDP/TLS/RTP/SAVPF 111 c=IN IP4 192.168.1.174 a=sendonly a=mid:a a=rtcp-mux a=ice-ufrag:LrNZ a=ice-pwd:RewF3LVilXQs06C9gOjVUk a=ice-options:trickle a=setup:actpass a=rtpmap:111 opus/48000/2 a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=msid:janus janusa a=ssrc:2759908030 cname:janus a=candidate:1 1 udp 2015363327 192.168.1.174 53372 typ host a=end-of-candidates m=video 9 UDP/TLS/RTP/SAVPF 100 101 c=IN IP4 192.168.1.174 a=sendonly a=mid:v a=rtcp-mux a=ice-ufrag:LrNZ a=ice-pwd:RewF3LVilXQs06C9gOjVUk a=ice-options:trickle a=setup:actpass a=rtpmap:100 vp8/90000 a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=rtpmap:101 rtx/90000 a=fmtp:101 apt=100 a=ssrc-group:FID 1010778191 3393424866 a=msid:janus janusv a=ssrc:1010778191 cname:janus a=ssrc:3393424866 cname:janus a=candidate:1 1 udp 2015363327 192.168.1.174 53372 typ host a=end-of-candidates ```Since pion seems not to support rtx over a different SSRC, I reject the
rtx
by not registering the codec in the media engine.SDP answer (pion)
``` v=0 o=- 2205701793287732906 1651154116 IN IP4 0.0.0.0 s=- t=0 0 a=fingerprint:sha-256 53:CB:E8:41:73:7D:79:DF:A7:B0:40:B3:0D:22:FF:55:10:52:CB:EA:33:47:5B:6A:5B:B2:74:9C:D6:AC:02:6C a=group:BUNDLE a v m=audio 9 UDP/TLS/RTP/SAVPF 111 c=IN IP4 0.0.0.0 a=setup:active a=mid:a a=ice-ufrag:UMqimwTZaeCbwgxK a=ice-pwd:XXJzevSCqkILXAaBakEipRSxZHVJtsMt a=rtcp-mux a=rtcp-rsize a=rtpmap:111 opus/48000/2 a=recvonly m=video 9 UDP/TLS/RTP/SAVPF 100 c=IN IP4 0.0.0.0 a=setup:active a=mid:v a=ice-ufrag:UMqimwTZaeCbwgxK a=ice-pwd:XXJzevSCqkILXAaBakEipRSxZHVJtsMt a=rtcp-mux a=rtcp-rsize a=rtpmap:100 vp8/90000 a=rtcp-fb:100 nack a=rtcp-fb:100 nack pli a=rtcp-fb:100 goog-remb a=recvonly ```Janus acknowledges the rejection and switches to same-ssrc retransmissions
What did you expect?
pion ignores the rtx SSRC
What happened?
pion starts sending periodic RTCP Receiver Reports about the rtx stream and janus prints a lot of warnings about the unknown SSRC for incoming RTCP.
I'm thinking of munging the SDP from janus in order to strip out
a=ssrc
lines.