[jitsi-dev] jitsi videobridge rtcp handling


#1

Okay that make sense. Thank you.

Is the generated SSRC for the recvonly channel supposed to show up on the bridge when doing a GET /colibri/conferencesXXX ?

Because I can’t see it, I see only ssrc where actually data is flowing.

{

        "channels": [

            {

                "channel-bundle-id": "551c48b049297113e2f8a184",

                "sources": [

                    3408283600

                ],

                "rtp-level-relay-type": "translator",

                "expire": 60,

                "initiator": true,

                "ssrcs": [

                    2934823582

                ],

                "id": "f06af2be4d6d5a3",

                "direction": "sendrecv"

            },

            {

                "channel-bundle-id": "551db593ab779dea3361b38c",

                "sources": [

                    3408283600

                ],

                "rtp-level-relay-type": "translator",

                "expire": 60,

                "initiator": true,

                "id": "9d219925fe0614d7",

                "direction": "sendrecv"

            }

        ],

        "name": "video"

    }
···

2015-05-19 11:55 GMT+02:00 George Politis gp@jitsi.org:

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

Yes.

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.


dev mailing list

dev@jitsi.org

Unsubscribe instructions and other list options:

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

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](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. 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))](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)))](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))%5D(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](https://groups.google.com/forum/%23!searchin/discuss-webrtc/ssrc|sort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J))))

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 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?
for some discussion.
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](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))%5D(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](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)

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

hmm we probably don't include it there. It's stored in the RtpChannel.receiveSSRCs array and that's not used to "describe" the channel.

···

On 19 May 2015, at 12:26, dr.andreas.rice@gmx.net wrote:

Okay that make sense. Thank you.
Is the generated SSRC for the recvonly channel supposed to show up on the bridge when doing a GET /colibri/conferencesXXX ?
Because I can't see it, I see only ssrc where actually data is flowing.

{
"channels": [
{
"channel-bundle-id": "551c48b049297113e2f8a184",
"sources": [
3408283600
],
"rtp-level-relay-type": "translator",
"expire": 60,
"initiator": true,
"ssrcs": [
2934823582
],
"id": "f06af2be4d6d5a3",
"direction": "sendrecv"
},
{
"channel-bundle-id": "551db593ab779dea3361b38c",
"sources": [
3408283600
],
"rtp-level-relay-type": "translator",
"expire": 60,
"initiator": true,
"id": "9d219925fe0614d7",
"direction": "sendrecv"
}
],
"name": "video"
}

2015-05-19 11:55 GMT+02:00 George Politis <[gp@jitsi.org](mailto:gp@jitsi.org)>: On 19 May 2015, at 11:49, [dr.andreas.rice@gmx.net](mailto:dr.andreas.rice@gmx.net) wrote:

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](http://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.

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