[jitsi-dev] jitsi videobridge rtcp handling


#1

I tried to mungle the SDP (e.g. sdp.replace(/(recvonly)/, “sendrecv”); + added ssrcs). That doesn’t seem to help, but I will do more investigations.

Also I didn’t see any PLIs sent with Chrome Stable, just with Canary so far.

···

2015-05-18 16:38 GMT+02:00 George Politis gp@jitsi.org:

You can try to mungle the SDP and set an SSRC (just generate one) for the recvonly channel. This should force the remote side and the bridge to understand RTCP packets and route them appropriately.

On 18 May 2015, at 16:20, dr.andreas.rice@gmx.net wrote:


dev mailing list

dev@jitsi.org

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/dev

So currently in recvonly streams the receiver has to wait till a keyframe is sent (every 3000 frames)?

What can we do to ask for a keyframe earlier with a recvonly streams?

Also askForKeyframes() rtcpFeedbackMessageSender.sendFIR(stream, receiveSSRCs) , RtpChannel.java #551 doesn’t seem to have any effect on chrome:

googFirsReceived

0

googPlisReceived

0

googNacksReceived

0

2015-05-15 7:18 GMT+02:00 Boris Grozev <[boris@jitsi.org](mailto:boris@jitsi.org

)>: On 15/05/15 04:05, Philipp Hancke wrote:Am 14.05.2015 um 18:00 schrieb Brian Baldino:I’m still digging further, but it looks like this is happening due to


dev mailing list

dev@jitsi.org

Unsubscribe instructions and other list options:

http://lists.jitsi.org/mailman/listinfo/dev
Chrome using an SSRC of “1” in its PLI messages, so they get filtered out

and ignored by the RtpChannelDatagramFilter (due to not matching any ssrcs

of the channel). Surprised that this isn’t affecting jitsi meet at all,

though. Does it do something to not rely on PLI?
It only does that on recvonly streams IIRC. See

[https://groups.google.com/forum/#!searchin/discuss-webrtc/ssrc%7Csort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J](https://groups.google.com/forum/#!searchin/discuss-webrtc/ssrc|sort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J](https://groups.google.com/forum/%23!searchin/discuss-webrtc/ssrc|sort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J))

for some discussion.
That’s interesting. Maybe we should assume RTCP packets with SSRC 1 are video, until they stop doing this.

Boris


dev mailing list

dev@jitsi.org

Unsubscribe instructions and other list options:

[http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev))


#2

You don't have to make the channel sendrecv, you can leave it recvonly. But you must signal the recvonly SSRC to jicofo so that it notifies the rest of the peers appropriately.

···

On 18 May 2015, at 17:10, PhiL wrote:

I tried to mungle the SDP (e.g. sdp.replace(/(recvonly)/, "sendrecv"); + added ssrcs). That doesn't seem to help, but I will do more investigations.
Also I didn't see any PLIs sent with Chrome Stable, just with Canary so far.

2015-05-18 16:38 GMT+02:00 George Politis <[gp@jitsi.org](mailto:gp@jitsi.org)>: You can try to mungle the SDP and set an SSRC (just generate one) for the recvonly channel. This should force the remote side and the bridge to understand RTCP packets and route them appropriately.

On 18 May 2015, at >> 16:20, [dr.andreas.rice@gmx.net](mailto:dr.andreas.rice@gmx.net) wrote:
So currently in recvonly streams the receiver has to wait till a keyframe is sent (every 3000 frames)?

What can we do to ask for a keyframe earlier with a recvonly streams?

Also askForKeyframes() rtcpFeedbackMessageSender.sendFIR(stream, receiveSSRCs) , RtpChannel.java #551 doesn't seem to have any effect on chrome:

googFirsReceived
0
googPlisReceived
0
googNacksReceived
0

2015-05-15 7:18 GMT+02:00 Boris Grozev <[[boris@jitsi.org](mailto:boris@jitsi.org)](mailto:[boris@jitsi.org](mailto:boris@jitsi.org))>: On 15/05/15 04:05, Philipp Hancke wrote:Am 14.05.2015 um 18:00 schrieb Brian Baldino:I'm still digging further, but it looks like this is happening due to Chrome using an SSRC of "1" in its PLI messages, so they get filtered out

and ignored by the RtpChannelDatagramFilter (due to not matching any ssrcs
of the channel). Surprised that this isn't affecting jitsi meet at all,
though. Does it do something to not rely on PLI?

It only does that on recvonly streams IIRC. See

[[https://groups.google.com/forum/#!searchin/discuss-webrtc/ssrc|sort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J](https://groups.google.com/forum/#!searchin/discuss-webrtc/ssrc|sort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J)](https://groups.google.com/forum/#!searchin/discuss-webrtc/ssrc|sort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J](https://groups.google.com/forum/%23!searchin/discuss-webrtc/ssrc|sort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J))
for some discussion.

That's interesting. Maybe we should assume RTCP packets with SSRC 1 are video, until they stop doing this.

Boris

_______________________________________________
dev mailing list
[[dev@jitsi.org](mailto:dev@jitsi.org)](mailto:[dev@jitsi.org](mailto:dev@jitsi.org))
Unsubscribe instructions and other list options:
[[http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)](http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev))

_______________________________________________
dev mailing list
[dev@jitsi.org](mailto:dev@jitsi.org)
Unsubscribe instructions and other list options:
[http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

_______________________________________________
dev mailing list
[dev@jitsi.org](mailto:dev@jitsi.org)
Unsubscribe instructions and other list options:
[http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev)

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev