[jitsi-dev] jitsi videobridge rtcp handling


#1

So I generate SSRC for the recvonly channel. Do the rest of the peers need to SRD for this SSRC as well?

I thought the bridge has the “mixed” stream to send RTCP packets if it needs to.

···

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

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:


dev mailing list

dev@jitsi.org

Unsubscribe instructions and other list options:

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

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. It only does that on recvonly streams IIRC. See

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


dev mailing list

dev@jitsi.org

Unsubscribe instructions and other list options:

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

On 18 May 2015, at 16:20, 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)>: 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?
[[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))](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)](https://groups.google.com/forum/%23!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.

Boris


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](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](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](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](http://lists.jitsi.org/mailman/listinfo/dev](http://lists.jitsi.org/mailman/listinfo/dev))


#2

So I generate SSRC for the recvonly channel. Do the rest of the peers need to SRD for this SSRC as well?

Yes.

I thought the bridge has the "mixed" stream to send RTCP packets if it needs to.

It does, but if you have a recvonly channel in Chrome and it asks for a PLI (i.e. the webrtc.org engine asks for a PLI), then the bridge and the remote end has to know the recvonly channel SSRC in order to relay and process the PLI.

···

On 19 May 2015, at 11:49, dr.andreas.rice@gmx.net wrote:

2015-05-18 17:23 GMT+02:00 George Politis <[gp@jitsi.org](mailto:gp@jitsi.org)>: 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)](mailto:[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)](mailto:[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))](mailto:[[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))](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)](https://groups.google.com/forum/%23!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))](mailto:[[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))](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)](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)](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