[jitsi-dev] jitsi videobridge rtcp handling


#1

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:

On 15/05/15 04:05, Philipp Hancke wrote:

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

Am 14.05.2015 um 18:00 schrieb Brian Baldino:

It only does that on recvonly streams IIRC. See

https://groups.google.com/forum/#!searchin/discuss-webrtc/ssrc%7Csort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J

for some discussion.
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?


#2

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:

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?

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)
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)
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


#3

The askForKeyframe method sends a FIR using an SSRC value generated by the bridge (and advertised in COLIBRI) -- is it added to chrome's remote description SDP? In jitsi-meet this goes in the ssrc-lines labeled 'mixed*'.

Also, I've seen webrtc-internals show googNacksReceived (and also googNacksSent) as 0, while I observe NACK packets on the network. Not sure under what circumstances it happens.

Another thing which we used to do to trigger a keyframe was a round of SDL/SRD. But I don't know if we still do this, or if it still works.

Regards,
Boris

···

On 18/05/15 17: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


#4

I also tried having the bridge call askForKeyframe method every 5 seconds,
but that didn't seem to result in Client 2 getting video any quicker.

···

On Mon, May 18, 2015 at 8:07 AM, Boris Grozev <boris@jitsi.org> wrote:

On 18/05/15 17: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

The askForKeyframe method sends a FIR using an SSRC value generated by the
bridge (and advertised in COLIBRI) -- is it added to chrome's remote
description SDP? In jitsi-meet this goes in the ssrc-lines labeled 'mixed*'.

Also, I've seen webrtc-internals show googNacksReceived (and also
googNacksSent) as 0, while I observe NACK packets on the network. Not sure
under what circumstances it happens.

Another thing which we used to do to trigger a keyframe was a round of
SDL/SRD. But I don't know if we still do this, or if it still works.

Regards,

Boris

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


#5

I'm still digging deeper...I believe I've successfully got PLIs passing
through the video bridge from Client 2 to Client 1, but Client 1 doesn't
register them on chrome://webrtc-internals. I notice that on chrome
stable, I don't see receivers register sending any feedback in
webrtc-internals, but on my build of chromium (a couple versions ahead) it
fires off lots of PLIs, perhaps there are some changes in chrome's webrtc
stack there?

I'm also still mystified how Jitsi meet clients get video without any
feedback being sent by the client. I believe the bridge will force a key
frame when doing a switch, but I have no clue as to why that logic doesn't
seem to result in video for Client 2 when they join in our scenario. We'll
be looking at disabling bundle/rtcp-mux soon to see what that shows.

···

On Mon, May 18, 2015 at 7:38 AM, George Politis <gp@jitsi.org> wrote:

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:

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?

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)
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

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


#6

Hi Brian,

I'm still digging deeper...I believe I've successfully got PLIs passing
through the video bridge from Client 2 to Client 1, but Client 1 doesn't
register them on chrome://webrtc-internals. I notice that on chrome
stable, I don't see receivers register sending any feedback in
webrtc-internals, but on my build of chromium (a couple versions ahead)
it fires off lots of PLIs, perhaps there are some changes in chrome's
webrtc stack there?

I suspect there might be an issue with FB reporting in webrtc-internals in chrome stable -- number of NACKs sent stay at 0 for me, even though I see them on the network. I'll try to confirm and open an issue tomorrow.

I'm also still mystified how Jitsi meet clients get video without any
feedback being sent by the client. I believe the bridge will force a
key frame when doing a switch, but I have no clue as to why that logic
doesn't seem to result in video for Client 2 when they join in our
scenario. We'll be looking at disabling bundle/rtcp-mux soon to see
what that shows.

If RTCP feedback is broken for some reason, this could be caused by this:
https://github.com/jitsi/jitsi-meet/issues/274

I only see it rarely, but there could be something that makes it happen more often for you...again :slight_smile:

Regards,
Boris

···

On 19/05/15 01:04, Brian Baldino wrote:

On Mon, May 18, 2015 at 7:38 AM, George Politis <gp@jitsi.org > <mailto:gp@jitsi.org>> wrote:

    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

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    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


#7

Thanks Boris! Inline.

Hi Brian,

I'm still digging deeper...I believe I've successfully got PLIs passing
through the video bridge from Client 2 to Client 1, but Client 1 doesn't
register them on chrome://webrtc-internals. I notice that on chrome
stable, I don't see receivers register sending any feedback in
webrtc-internals, but on my build of chromium (a couple versions ahead)
it fires off lots of PLIs, perhaps there are some changes in chrome's
webrtc stack there?

I suspect there might be an issue with FB reporting in webrtc-internals in
chrome stable -- number of NACKs sent stay at 0 for me, even though I see
them on the network. I'll try to confirm and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've seen in
chrome stable vs. canary are some fixes there, have you tried running that
test with a canary build and seeing if the stats match? Either way, it's
been very confusing...sometimes we do see stats update properly and
sometimes we get nothing there at all. We haven't run wireshark traces for
every call to compare, maybe I'll spend some time on that.

I'm also still mystified how Jitsi meet clients get video without any
feedback being sent by the client. I believe the bridge will force a
key frame when doing a switch, but I have no clue as to why that logic
doesn't seem to result in video for Client 2 when they join in our
scenario. We'll be looking at disabling bundle/rtcp-mux soon to see
what that shows.

If RTCP feedback is broken for some reason, this could be caused by this:
https://github.com/jitsi/jitsi-meet/issues/274

I only see it rarely, but there could be something that makes it happen
more often for you...again :slight_smile:

This at least *sounds* exactly like what we're seeing. What can I do to
help you debug/reproduce?

···

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org> wrote:

On 19/05/15 01:04, Brian Baldino wrote:

Regards,
Boris

On Mon, May 18, 2015 at 7:38 AM, George Politis <gp@jitsi.org >> <mailto:gp@jitsi.org>> wrote:

    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)>
                <
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

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    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

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


#8

Hi Brian,

Sorry for the slow response (inline).

Thanks Boris! Inline.

    Hi Brian,

        I'm still digging deeper...I believe I've successfully got PLIs
        passing
        through the video bridge from Client 2 to Client 1, but Client 1
        doesn't
        register them on chrome://webrtc-internals. I notice that on chrome
        stable, I don't see receivers register sending any feedback in
        webrtc-internals, but on my build of chromium (a couple versions
        ahead)
        it fires off lots of PLIs, perhaps there are some changes in
        chrome's
        webrtc stack there?

    I suspect there might be an issue with FB reporting in
    webrtc-internals in chrome stable -- number of NACKs sent stay at 0
    for me, even though I see them on the network. I'll try to confirm
    and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've seen
in chrome stable vs. canary are some fixes there, have you tried running
that test with a canary build and seeing if the stats match? Either
way, it's been very confusing...sometimes we do see stats update
properly and sometimes we get nothing there at all. We haven't run
wireshark traces for every call to compare, maybe I'll spend some time
on that.

You are right, it looks OK with canary.

Have in mind that RTCP FB messages are hard to spot because of SRTCP: chrome usually sends them in a compound packet with an RR and only the first packet's headers are readable.

        I'm also still mystified how Jitsi meet clients get video
        without any
        feedback being sent by the client. I believe the bridge will
        force a
        key frame when doing a switch, but I have no clue as to why that
        logic
        doesn't seem to result in video for Client 2 when they join in our
        scenario. We'll be looking at disabling bundle/rtcp-mux soon to see
        what that shows.

    If RTCP feedback is broken for some reason, this could be caused by
    this:
    https://github.com/jitsi/jitsi-meet/issues/274

    I only see it rarely, but there could be something that makes it
    happen more often for you...again :slight_smile:

This at least /sounds/ exactly like what we're seeing. What can I do to
help you debug/reproduce?

You can check if this is indeed what you are running into by adding a print here:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L799

For debugging -- I don't know. I don't think any of us is actively looking into it right now (it is a low prio, since it only results in a slight delay when RTCP FB works). It looks like for some reason the DTLS connect thread is too slow to initialize the transformer:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L914

But this is all I know and I don't see how to debug it at the moment.

Regards,
Boris

···

On 19/05/15 02:56, Brian Baldino wrote:

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org > <mailto:boris@jitsi.org>> wrote:
    On 19/05/15 01:04, Brian Baldino wrote:


#9

No problem Boris, thanks. We were able to get past the issue now, here is,
I think, a summary of what we found:

1) Chrome has an issue where a receive stream can be created before a send
stream (even if the description describes both). In this case, the receive
stream will use "1" as the local SSRC and will not get updated when the
send stream gets created after (I posted about this on the discuss-webrtc
list, and this bug <https://code.google.com/p/webrtc/issues/detail?id=4678>
was created to track it). For us, this was happening when a client joined a
call which already had a client in it and we included all client SSRCs in
the call in the initial offer to this new client. We fixed this by always
sending an initial offer with just the bridge's dummy SSRCs, and adding the
SSRCs for other clients in a separate offer (I believe this is what Jitsi
meet does, which explains why we weren't seeing it there as consistently).
This issue presented itself as: audio and video for the second client
taking a long time to render as well as frequent frozen video.

2) Even though the behavior in the above scenario on Chrome is a bug, there
are scenarios where Chrome does (by design) use an SSRC of 1 for rtcp
feedback, jitsi videobridge fails to forward this in two places: 1) it
drops them in RTPChannelDatagramFilter due to the sender SSRC "1" not being
recognized for that channel and 2) (assuming #1 has been changed to not
drop the feedback packet) the derived SRTCP context for these packets (when
forwarding them on to the far side client) seems to be incorrect, causing
them to fail authentication by the far side client.

3) I do not know if the workaround for #1 is 100% foolproof, as we've seen
instances of this same failure in jitsi meet calls as well.

-brian

···

On Tue, May 19, 2015 at 10:03 PM, Boris Grozev <boris@jitsi.org> wrote:

Hi Brian,

Sorry for the slow response (inline).

On 19/05/15 02:56, Brian Baldino wrote:

Thanks Boris! Inline.

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org >> <mailto:boris@jitsi.org>> wrote:

    Hi Brian,

    On 19/05/15 01:04, Brian Baldino wrote:

        I'm still digging deeper...I believe I've successfully got PLIs
        passing
        through the video bridge from Client 2 to Client 1, but Client 1
        doesn't
        register them on chrome://webrtc-internals. I notice that on
chrome
        stable, I don't see receivers register sending any feedback in
        webrtc-internals, but on my build of chromium (a couple versions
        ahead)
        it fires off lots of PLIs, perhaps there are some changes in
        chrome's
        webrtc stack there?

    I suspect there might be an issue with FB reporting in
    webrtc-internals in chrome stable -- number of NACKs sent stay at 0
    for me, even though I see them on the network. I'll try to confirm
    and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've seen
in chrome stable vs. canary are some fixes there, have you tried running
that test with a canary build and seeing if the stats match? Either
way, it's been very confusing...sometimes we do see stats update
properly and sometimes we get nothing there at all. We haven't run
wireshark traces for every call to compare, maybe I'll spend some time
on that.

You are right, it looks OK with canary.

Have in mind that RTCP FB messages are hard to spot because of SRTCP:
chrome usually sends them in a compound packet with an RR and only the
first packet's headers are readable.

        I'm also still mystified how Jitsi meet clients get video
        without any
        feedback being sent by the client. I believe the bridge will
        force a
        key frame when doing a switch, but I have no clue as to why that
        logic
        doesn't seem to result in video for Client 2 when they join in our
        scenario. We'll be looking at disabling bundle/rtcp-mux soon to
see
        what that shows.

    If RTCP feedback is broken for some reason, this could be caused by
    this:
    https://github.com/jitsi/jitsi-meet/issues/274

    I only see it rarely, but there could be something that makes it
    happen more often for you...again :slight_smile:

This at least /sounds/ exactly like what we're seeing. What can I do to
help you debug/reproduce?

You can check if this is indeed what you are running into by adding a
print here:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L799

For debugging -- I don't know. I don't think any of us is actively looking
into it right now (it is a low prio, since it only results in a slight
delay when RTCP FB works). It looks like for some reason the DTLS connect
thread is too slow to initialize the transformer:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L914

But this is all I know and I don't see how to debug it at the moment.

Regards,
Boris

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


#10

Bringing this back up since we're running into it again in the legitimate
use case (a client video muting).

What's the official way to have the bridge accept RTCP with a sender SSRC
of "1"? I tried configuring it as an "ssrc" on the channel (via the REST
API patch)...but the bridge doesn't seem to actually read from this field.
'sources' also doesn't seem to give the right behavior (though I'll admit
I'm not entirely clear on the difference in roles between 'sources' and
'ssrcs' on a channel).

-brian

···

On Wed, May 20, 2015 at 9:25 AM, Brian Baldino <brian@highfive.com> wrote:

No problem Boris, thanks. We were able to get past the issue now, here
is, I think, a summary of what we found:

1) Chrome has an issue where a receive stream can be created before a send
stream (even if the description describes both). In this case, the receive
stream will use "1" as the local SSRC and will not get updated when the
send stream gets created after (I posted about this on the discuss-webrtc
list, and this bug
<https://code.google.com/p/webrtc/issues/detail?id=4678> was created to
track it). For us, this was happening when a client joined a call which
already had a client in it and we included all client SSRCs in the call in
the initial offer to this new client. We fixed this by always sending an
initial offer with just the bridge's dummy SSRCs, and adding the SSRCs for
other clients in a separate offer (I believe this is what Jitsi meet does,
which explains why we weren't seeing it there as consistently). This issue
presented itself as: audio and video for the second client taking a long
time to render as well as frequent frozen video.

2) Even though the behavior in the above scenario on Chrome is a bug,
there are scenarios where Chrome does (by design) use an SSRC of 1 for rtcp
feedback, jitsi videobridge fails to forward this in two places: 1) it
drops them in RTPChannelDatagramFilter due to the sender SSRC "1" not being
recognized for that channel and 2) (assuming #1 has been changed to not
drop the feedback packet) the derived SRTCP context for these packets (when
forwarding them on to the far side client) seems to be incorrect, causing
them to fail authentication by the far side client.

3) I do not know if the workaround for #1 is 100% foolproof, as we've seen
instances of this same failure in jitsi meet calls as well.

-brian

On Tue, May 19, 2015 at 10:03 PM, Boris Grozev <boris@jitsi.org> wrote:

Hi Brian,

Sorry for the slow response (inline).

On 19/05/15 02:56, Brian Baldino wrote:

Thanks Boris! Inline.

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org >>> <mailto:boris@jitsi.org>> wrote:

    Hi Brian,

    On 19/05/15 01:04, Brian Baldino wrote:

        I'm still digging deeper...I believe I've successfully got PLIs
        passing
        through the video bridge from Client 2 to Client 1, but Client 1
        doesn't
        register them on chrome://webrtc-internals. I notice that on
chrome
        stable, I don't see receivers register sending any feedback in
        webrtc-internals, but on my build of chromium (a couple versions
        ahead)
        it fires off lots of PLIs, perhaps there are some changes in
        chrome's
        webrtc stack there?

    I suspect there might be an issue with FB reporting in
    webrtc-internals in chrome stable -- number of NACKs sent stay at 0
    for me, even though I see them on the network. I'll try to confirm
    and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've seen
in chrome stable vs. canary are some fixes there, have you tried running
that test with a canary build and seeing if the stats match? Either
way, it's been very confusing...sometimes we do see stats update
properly and sometimes we get nothing there at all. We haven't run
wireshark traces for every call to compare, maybe I'll spend some time
on that.

You are right, it looks OK with canary.

Have in mind that RTCP FB messages are hard to spot because of SRTCP:
chrome usually sends them in a compound packet with an RR and only the
first packet's headers are readable.

        I'm also still mystified how Jitsi meet clients get video
        without any
        feedback being sent by the client. I believe the bridge will
        force a
        key frame when doing a switch, but I have no clue as to why that
        logic
        doesn't seem to result in video for Client 2 when they join in
our
        scenario. We'll be looking at disabling bundle/rtcp-mux soon to
see
        what that shows.

    If RTCP feedback is broken for some reason, this could be caused by
    this:
    https://github.com/jitsi/jitsi-meet/issues/274

    I only see it rarely, but there could be something that makes it
    happen more often for you...again :slight_smile:

This at least /sounds/ exactly like what we're seeing. What can I do to
help you debug/reproduce?

You can check if this is indeed what you are running into by adding a
print here:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L799

For debugging -- I don't know. I don't think any of us is actively
looking into it right now (it is a low prio, since it only results in a
slight delay when RTCP FB works). It looks like for some reason the DTLS
connect thread is too slow to initialize the transformer:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L914

But this is all I know and I don't see how to debug it at the moment.

Regards,
Boris

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


#11

Hi Brian,

I guess we’re not so clear about ‘ssrc’ either. It’s a old relic that's deprecated afaik. Configuring SSRC 1 as a ‘source’ should have the desired effect though; How do you format your JSON object? Looking at the code, it should be defined in a `‘sources’: [1, 443343433, …]` array inside the channel.

Best,
George

···

On Nov 3, 2015, at 8:33 PM, Brian Baldino <brian@highfive.com> wrote:

Bringing this back up since we're running into it again in the legitimate use case (a client video muting).

What's the official way to have the bridge accept RTCP with a sender SSRC of "1"? I tried configuring it as an "ssrc" on the channel (via the REST API patch)...but the bridge doesn't seem to actually read from this field. 'sources' also doesn't seem to give the right behavior (though I'll admit I'm not entirely clear on the difference in roles between 'sources' and 'ssrcs' on a channel).

-brian

On Wed, May 20, 2015 at 9:25 AM, Brian Baldino <brian@highfive.com <mailto:brian@highfive.com>> wrote:
No problem Boris, thanks. We were able to get past the issue now, here is, I think, a summary of what we found:

1) Chrome has an issue where a receive stream can be created before a send stream (even if the description describes both). In this case, the receive stream will use "1" as the local SSRC and will not get updated when the send stream gets created after (I posted about this on the discuss-webrtc list, and this bug <https://code.google.com/p/webrtc/issues/detail?id=4678> was created to track it). For us, this was happening when a client joined a call which already had a client in it and we included all client SSRCs in the call in the initial offer to this new client. We fixed this by always sending an initial offer with just the bridge's dummy SSRCs, and adding the SSRCs for other clients in a separate offer (I believe this is what Jitsi meet does, which explains why we weren't seeing it there as consistently). This issue presented itself as: audio and video for the second client taking a long time to render as well as frequent frozen video.

2) Even though the behavior in the above scenario on Chrome is a bug, there are scenarios where Chrome does (by design) use an SSRC of 1 for rtcp feedback, jitsi videobridge fails to forward this in two places: 1) it drops them in RTPChannelDatagramFilter due to the sender SSRC "1" not being recognized for that channel and 2) (assuming #1 has been changed to not drop the feedback packet) the derived SRTCP context for these packets (when forwarding them on to the far side client) seems to be incorrect, causing them to fail authentication by the far side client.

3) I do not know if the workaround for #1 is 100% foolproof, as we've seen instances of this same failure in jitsi meet calls as well.

-brian

On Tue, May 19, 2015 at 10:03 PM, Boris Grozev <boris@jitsi.org <mailto:boris@jitsi.org>> wrote:
Hi Brian,

Sorry for the slow response (inline).

On 19/05/15 02:56, Brian Baldino wrote:
Thanks Boris! Inline.

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org <mailto:boris@jitsi.org> > <mailto:boris@jitsi.org <mailto:boris@jitsi.org>>> wrote:

    Hi Brian,

    On 19/05/15 01:04, Brian Baldino wrote:

        I'm still digging deeper...I believe I've successfully got PLIs
        passing
        through the video bridge from Client 2 to Client 1, but Client 1
        doesn't
        register them on chrome://webrtc-internals. I notice that on chrome
        stable, I don't see receivers register sending any feedback in
        webrtc-internals, but on my build of chromium (a couple versions
        ahead)
        it fires off lots of PLIs, perhaps there are some changes in
        chrome's
        webrtc stack there?

    I suspect there might be an issue with FB reporting in
    webrtc-internals in chrome stable -- number of NACKs sent stay at 0
    for me, even though I see them on the network. I'll try to confirm
    and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've seen
in chrome stable vs. canary are some fixes there, have you tried running
that test with a canary build and seeing if the stats match? Either
way, it's been very confusing...sometimes we do see stats update
properly and sometimes we get nothing there at all. We haven't run
wireshark traces for every call to compare, maybe I'll spend some time
on that.

You are right, it looks OK with canary.

Have in mind that RTCP FB messages are hard to spot because of SRTCP: chrome usually sends them in a compound packet with an RR and only the first packet's headers are readable.

        I'm also still mystified how Jitsi meet clients get video
        without any
        feedback being sent by the client. I believe the bridge will
        force a
        key frame when doing a switch, but I have no clue as to why that
        logic
        doesn't seem to result in video for Client 2 when they join in our
        scenario. We'll be looking at disabling bundle/rtcp-mux soon to see
        what that shows.

    If RTCP feedback is broken for some reason, this could be caused by
    this:
    https://github.com/jitsi/jitsi-meet/issues/274

    I only see it rarely, but there could be something that makes it
    happen more often for you...again :slight_smile:

This at least /sounds/ exactly like what we're seeing. What can I do to
help you debug/reproduce?

You can check if this is indeed what you are running into by adding a print here:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L799

For debugging -- I don't know. I don't think any of us is actively looking into it right now (it is a low prio, since it only results in a slight delay when RTCP FB works). It looks like for some reason the DTLS connect thread is too slow to initialize the transformer:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L914

But this is all I know and I don't see how to debug it at the moment.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
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


#12

Thanks George! I believe I tried as you described, but it seemed to cause
issues (I don't think I got video flowing either way). I'll try adding
that again and see if I can figure out what's going wrong.

···

On Wed, Nov 4, 2015 at 8:20 AM, George Politis <gp@jitsi.org> wrote:

Hi Brian,

I guess we’re not so clear about ‘ssrc’ either. It’s a old relic that's
deprecated afaik. Configuring SSRC 1 as a ‘source’ should have the desired
effect though; How do you format your JSON object? Looking at the code, it
should be defined in a `‘sources’: [1, 443343433, …]` array inside the
channel.

Best,
George

On Nov 3, 2015, at 8:33 PM, Brian Baldino <brian@highfive.com> wrote:

Bringing this back up since we're running into it again in the legitimate
use case (a client video muting).

What's the official way to have the bridge accept RTCP with a sender SSRC
of "1"? I tried configuring it as an "ssrc" on the channel (via the REST
API patch)...but the bridge doesn't seem to actually read from this field.
'sources' also doesn't seem to give the right behavior (though I'll admit
I'm not entirely clear on the difference in roles between 'sources' and
'ssrcs' on a channel).

-brian

On Wed, May 20, 2015 at 9:25 AM, Brian Baldino <brian@highfive.com> wrote:

No problem Boris, thanks. We were able to get past the issue now, here
is, I think, a summary of what we found:

1) Chrome has an issue where a receive stream can be created before a
send stream (even if the description describes both). In this case, the
receive stream will use "1" as the local SSRC and will not get updated when
the send stream gets created after (I posted about this on the
discuss-webrtc list, and this bug
<https://code.google.com/p/webrtc/issues/detail?id=4678> was created to
track it). For us, this was happening when a client joined a call which
already had a client in it and we included all client SSRCs in the call in
the initial offer to this new client. We fixed this by always sending an
initial offer with just the bridge's dummy SSRCs, and adding the SSRCs for
other clients in a separate offer (I believe this is what Jitsi meet does,
which explains why we weren't seeing it there as consistently). This issue
presented itself as: audio and video for the second client taking a long
time to render as well as frequent frozen video.

2) Even though the behavior in the above scenario on Chrome is a bug,
there are scenarios where Chrome does (by design) use an SSRC of 1 for rtcp
feedback, jitsi videobridge fails to forward this in two places: 1) it
drops them in RTPChannelDatagramFilter due to the sender SSRC "1" not being
recognized for that channel and 2) (assuming #1 has been changed to not
drop the feedback packet) the derived SRTCP context for these packets (when
forwarding them on to the far side client) seems to be incorrect, causing
them to fail authentication by the far side client.

3) I do not know if the workaround for #1 is 100% foolproof, as we've
seen instances of this same failure in jitsi meet calls as well.

-brian

On Tue, May 19, 2015 at 10:03 PM, Boris Grozev <boris@jitsi.org> wrote:

Hi Brian,

Sorry for the slow response (inline).

On 19/05/15 02:56, Brian Baldino wrote:

Thanks Boris! Inline.

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org >>>> <mailto:boris@jitsi.org>> wrote:

    Hi Brian,

    On 19/05/15 01:04, Brian Baldino wrote:

        I'm still digging deeper...I believe I've successfully got PLIs
        passing
        through the video bridge from Client 2 to Client 1, but Client 1
        doesn't
        register them on chrome://webrtc-internals. I notice that on
chrome
        stable, I don't see receivers register sending any feedback in
        webrtc-internals, but on my build of chromium (a couple versions
        ahead)
        it fires off lots of PLIs, perhaps there are some changes in
        chrome's
        webrtc stack there?

    I suspect there might be an issue with FB reporting in
    webrtc-internals in chrome stable -- number of NACKs sent stay at 0
    for me, even though I see them on the network. I'll try to confirm
    and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've seen
in chrome stable vs. canary are some fixes there, have you tried running
that test with a canary build and seeing if the stats match? Either
way, it's been very confusing...sometimes we do see stats update
properly and sometimes we get nothing there at all. We haven't run
wireshark traces for every call to compare, maybe I'll spend some time
on that.

You are right, it looks OK with canary.

Have in mind that RTCP FB messages are hard to spot because of SRTCP:
chrome usually sends them in a compound packet with an RR and only the
first packet's headers are readable.

        I'm also still mystified how Jitsi meet clients get video
        without any
        feedback being sent by the client. I believe the bridge will
        force a
        key frame when doing a switch, but I have no clue as to why that
        logic
        doesn't seem to result in video for Client 2 when they join in
our
        scenario. We'll be looking at disabling bundle/rtcp-mux soon
to see
        what that shows.

    If RTCP feedback is broken for some reason, this could be caused by
    this:
    https://github.com/jitsi/jitsi-meet/issues/274

    I only see it rarely, but there could be something that makes it
    happen more often for you...again :slight_smile:

This at least /sounds/ exactly like what we're seeing. What can I do to
help you debug/reproduce?

You can check if this is indeed what you are running into by adding a
print here:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L799

For debugging -- I don't know. I don't think any of us is actively
looking into it right now (it is a low prio, since it only results in a
slight delay when RTCP FB works). It looks like for some reason the DTLS
connect thread is too slow to initialize the transformer:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L914

But this is all I know and I don't see how to debug it at the moment.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
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

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


#13

Hi Brian,

Please let us know how it goes. If you have a bleeding edge bridge you can have it capture decrypted packets (both RTP and RTCP), which can help you determine whether the bridge correctly forwards RTCP packets with SSRC 1. You can find detailed instructions on how to use this functionality here [1], in the Javadoc of the DebugTransformEngine.

···

-
George

[1]: https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/DebugTransformEngine.java

On Nov 4, 2015, at 10:50 AM, Brian Baldino <brian@highfive.com> wrote:

Thanks George! I believe I tried as you described, but it seemed to cause issues (I don't think I got video flowing either way). I'll try adding that again and see if I can figure out what's going wrong.

On Wed, Nov 4, 2015 at 8:20 AM, George Politis <gp@jitsi.org <mailto:gp@jitsi.org>> wrote:
Hi Brian,

I guess we’re not so clear about ‘ssrc’ either. It’s a old relic that's deprecated afaik. Configuring SSRC 1 as a ‘source’ should have the desired effect though; How do you format your JSON object? Looking at the code, it should be defined in a `‘sources’: [1, 443343433, …]` array inside the channel.

Best,
George

On Nov 3, 2015, at 8:33 PM, Brian Baldino <brian@highfive.com <mailto:brian@highfive.com>> wrote:

Bringing this back up since we're running into it again in the legitimate use case (a client video muting).

What's the official way to have the bridge accept RTCP with a sender SSRC of "1"? I tried configuring it as an "ssrc" on the channel (via the REST API patch)...but the bridge doesn't seem to actually read from this field. 'sources' also doesn't seem to give the right behavior (though I'll admit I'm not entirely clear on the difference in roles between 'sources' and 'ssrcs' on a channel).

-brian

On Wed, May 20, 2015 at 9:25 AM, Brian Baldino <brian@highfive.com <mailto:brian@highfive.com>> wrote:
No problem Boris, thanks. We were able to get past the issue now, here is, I think, a summary of what we found:

1) Chrome has an issue where a receive stream can be created before a send stream (even if the description describes both). In this case, the receive stream will use "1" as the local SSRC and will not get updated when the send stream gets created after (I posted about this on the discuss-webrtc list, and this bug <https://code.google.com/p/webrtc/issues/detail?id=4678> was created to track it). For us, this was happening when a client joined a call which already had a client in it and we included all client SSRCs in the call in the initial offer to this new client. We fixed this by always sending an initial offer with just the bridge's dummy SSRCs, and adding the SSRCs for other clients in a separate offer (I believe this is what Jitsi meet does, which explains why we weren't seeing it there as consistently). This issue presented itself as: audio and video for the second client taking a long time to render as well as frequent frozen video.

2) Even though the behavior in the above scenario on Chrome is a bug, there are scenarios where Chrome does (by design) use an SSRC of 1 for rtcp feedback, jitsi videobridge fails to forward this in two places: 1) it drops them in RTPChannelDatagramFilter due to the sender SSRC "1" not being recognized for that channel and 2) (assuming #1 has been changed to not drop the feedback packet) the derived SRTCP context for these packets (when forwarding them on to the far side client) seems to be incorrect, causing them to fail authentication by the far side client.

3) I do not know if the workaround for #1 is 100% foolproof, as we've seen instances of this same failure in jitsi meet calls as well.

-brian

On Tue, May 19, 2015 at 10:03 PM, Boris Grozev <boris@jitsi.org <mailto:boris@jitsi.org>> wrote:
Hi Brian,

Sorry for the slow response (inline).

On 19/05/15 02:56, Brian Baldino wrote:
Thanks Boris! Inline.

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org <mailto:boris@jitsi.org> >> <mailto:boris@jitsi.org <mailto:boris@jitsi.org>>> wrote:

    Hi Brian,

    On 19/05/15 01:04, Brian Baldino wrote:

        I'm still digging deeper...I believe I've successfully got PLIs
        passing
        through the video bridge from Client 2 to Client 1, but Client 1
        doesn't
        register them on chrome://webrtc-internals <>. I notice that on chrome
        stable, I don't see receivers register sending any feedback in
        webrtc-internals, but on my build of chromium (a couple versions
        ahead)
        it fires off lots of PLIs, perhaps there are some changes in
        chrome's
        webrtc stack there?

    I suspect there might be an issue with FB reporting in
    webrtc-internals in chrome stable -- number of NACKs sent stay at 0
    for me, even though I see them on the network. I'll try to confirm
    and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've seen
in chrome stable vs. canary are some fixes there, have you tried running
that test with a canary build and seeing if the stats match? Either
way, it's been very confusing...sometimes we do see stats update
properly and sometimes we get nothing there at all. We haven't run
wireshark traces for every call to compare, maybe I'll spend some time
on that.

You are right, it looks OK with canary.

Have in mind that RTCP FB messages are hard to spot because of SRTCP: chrome usually sends them in a compound packet with an RR and only the first packet's headers are readable.

        I'm also still mystified how Jitsi meet clients get video
        without any
        feedback being sent by the client. I believe the bridge will
        force a
        key frame when doing a switch, but I have no clue as to why that
        logic
        doesn't seem to result in video for Client 2 when they join in our
        scenario. We'll be looking at disabling bundle/rtcp-mux soon to see
        what that shows.

    If RTCP feedback is broken for some reason, this could be caused by
    this:
    https://github.com/jitsi/jitsi-meet/issues/274

    I only see it rarely, but there could be something that makes it
    happen more often for you...again :slight_smile:

This at least /sounds/ exactly like what we're seeing. What can I do to
help you debug/reproduce?

You can check if this is indeed what you are running into by adding a print here:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L799

For debugging -- I don't know. I don't think any of us is actively looking into it right now (it is a low prio, since it only results in a slight delay when RTCP FB works). It looks like for some reason the DTLS connect thread is too slow to initialize the transformer:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L914

But this is all I know and I don't see how to debug it at the moment.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
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

_______________________________________________
dev mailing list
dev@jitsi.org <mailto:dev@jitsi.org>
Unsubscribe instructions and other list options:
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


#14

Ok, I think I've got a bit of info here:

RTCP with an ssrc of 1 gets dropped
in RtpChannelDatagramFilter::acceptRTCP. That method checks if the sender
ssrc is in the RTPChannel's ssrcs and, if not, drops it. The RTPChannel's
ssrcs get populated via RTPChannel::acceptDataInputStreamDatagramPacket.
When acceptDataInputStreamDatagramPacket sees a packet with a new ssrc, it
adds it via addReceiveSSRC. RTCP is processed
in acceptControlInputStreamDatagramPacket and only RTCP bye messages are
examined (and handled via calling removeReceiveSSRC), logic for adding a
receive ssrc doesn't exist inside of
acceptControlInputStreamDatagramPacket, so it's not possible for an ssrc of
1 (sent only via RTCP) to get added there.

As for 'ssrcs' and 'sources' in colibri, this is what I see:
1) The 'ssrcs' field is ignored when issuing a colibri patch to the bridge,
but when a get is requested, it is populated with the values added via
addReceiveSSRC.
2) The 'sources' field will populate the 'ssrcs' value when issuing a
colibri patch (it will take those values and call addReceiveSSRC), however
when doing a get, the 'sources' field is populated with the BRIDGE source
ssrcs (the dummy audio and video streams). This comes from
RtpChannel::describe where it fills in the 'sources' field with its local
ssrc.

If I add the "1" ssrc as a source, it properly gets added as a receive
ssrc, which means that when RtpChannelDatagramFilter::acceptRTCP sees an
RTCP packet with a sender ssrc of "1", it will forward it correctly.

So it seems that there are some conflicting definitions/usages of 'ssrcs'
and 'sources' in a channel. It appears as though "sources" are meant to
reflect streams coming from the bridge (but they only ever seem to contain
the streams which *originate* at the bridge, not the ones it forwards), and
"ssrcs" are the streams that the bridge should expect to receive on that
channel (either via the rtp packet ssrc or the senderssrc field in an rtcp
packet).

So a couple options that came to mind were:
1) Signal the "1" ssrc via the 'sources' block in colibri. This works, but
seems to further contribute to the current confusion in how 'sources' and
'ssrcs' are used. Also, other ssrcs don't need to be explicitly signaled
(they get added automatically) so this doesn't seem to be very consistent
with existing behavior. This wouldn't break existing clients, but failing
to make this change will break clients based on chrome when their in
recvonly for video.
2) Have the acceptDataInputStreamDatagramPacket add any new sender ssrcs it
sees automatically, this matches what we do with normal rtp ssrcs and would
not require any changes from clients.
3) Always require ssrcs to be signaled explicitly. Never add a ssrc
implicitly, only accept those that have been signaled explicitly and
require the client to configure the ssrcs correctly. This would break all
clients :frowning:

Regardless of which option (the above or something else) we choose to solve
this, I think there is some cleanup to be done around the usage of
'sources' and 'ssrcs' as well.

-brian

···

On Wed, Nov 4, 2015 at 9:51 AM, George Politis <gp@jitsi.org> wrote:

Hi Brian,

Please let us know how it goes. If you have a bleeding edge bridge you can
have it capture decrypted packets (both RTP and RTCP), which can help you
determine whether the bridge correctly forwards RTCP packets with SSRC 1.
You can find detailed instructions on how to use this functionality here
[1], in the Javadoc of the DebugTransformEngine.

-
George

[1]:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/DebugTransformEngine.java

On Nov 4, 2015, at 10:50 AM, Brian Baldino <brian@highfive.com> wrote:

Thanks George! I believe I tried as you described, but it seemed to cause
issues (I don't think I got video flowing either way). I'll try adding
that again and see if I can figure out what's going wrong.

On Wed, Nov 4, 2015 at 8:20 AM, George Politis <gp@jitsi.org> wrote:

Hi Brian,

I guess we’re not so clear about ‘ssrc’ either. It’s a old relic that's
deprecated afaik. Configuring SSRC 1 as a ‘source’ should have the desired
effect though; How do you format your JSON object? Looking at the code, it
should be defined in a `‘sources’: [1, 443343433, …]` array inside the
channel.

Best,
George

On Nov 3, 2015, at 8:33 PM, Brian Baldino <brian@highfive.com> wrote:

Bringing this back up since we're running into it again in the legitimate
use case (a client video muting).

What's the official way to have the bridge accept RTCP with a sender SSRC
of "1"? I tried configuring it as an "ssrc" on the channel (via the REST
API patch)...but the bridge doesn't seem to actually read from this field.
'sources' also doesn't seem to give the right behavior (though I'll admit
I'm not entirely clear on the difference in roles between 'sources' and
'ssrcs' on a channel).

-brian

On Wed, May 20, 2015 at 9:25 AM, Brian Baldino <brian@highfive.com> >> wrote:

No problem Boris, thanks. We were able to get past the issue now, here
is, I think, a summary of what we found:

1) Chrome has an issue where a receive stream can be created before a
send stream (even if the description describes both). In this case, the
receive stream will use "1" as the local SSRC and will not get updated when
the send stream gets created after (I posted about this on the
discuss-webrtc list, and this bug
<https://code.google.com/p/webrtc/issues/detail?id=4678> was created to
track it). For us, this was happening when a client joined a call which
already had a client in it and we included all client SSRCs in the call in
the initial offer to this new client. We fixed this by always sending an
initial offer with just the bridge's dummy SSRCs, and adding the SSRCs for
other clients in a separate offer (I believe this is what Jitsi meet does,
which explains why we weren't seeing it there as consistently). This issue
presented itself as: audio and video for the second client taking a long
time to render as well as frequent frozen video.

2) Even though the behavior in the above scenario on Chrome is a bug,
there are scenarios where Chrome does (by design) use an SSRC of 1 for rtcp
feedback, jitsi videobridge fails to forward this in two places: 1) it
drops them in RTPChannelDatagramFilter due to the sender SSRC "1" not being
recognized for that channel and 2) (assuming #1 has been changed to not
drop the feedback packet) the derived SRTCP context for these packets (when
forwarding them on to the far side client) seems to be incorrect, causing
them to fail authentication by the far side client.

3) I do not know if the workaround for #1 is 100% foolproof, as we've
seen instances of this same failure in jitsi meet calls as well.

-brian

On Tue, May 19, 2015 at 10:03 PM, Boris Grozev <boris@jitsi.org> wrote:

Hi Brian,

Sorry for the slow response (inline).

On 19/05/15 02:56, Brian Baldino wrote:

Thanks Boris! Inline.

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org >>>>> <mailto:boris@jitsi.org>> wrote:

    Hi Brian,

    On 19/05/15 01:04, Brian Baldino wrote:

        I'm still digging deeper...I believe I've successfully got PLIs
        passing
        through the video bridge from Client 2 to Client 1, but Client
1
        doesn't
        register them on chrome://webrtc-internals. I notice that on
chrome
        stable, I don't see receivers register sending any feedback in
        webrtc-internals, but on my build of chromium (a couple
versions
        ahead)
        it fires off lots of PLIs, perhaps there are some changes in
        chrome's
        webrtc stack there?

    I suspect there might be an issue with FB reporting in
    webrtc-internals in chrome stable -- number of NACKs sent stay at 0
    for me, even though I see them on the network. I'll try to confirm
    and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've
seen
in chrome stable vs. canary are some fixes there, have you tried
running
that test with a canary build and seeing if the stats match? Either
way, it's been very confusing...sometimes we do see stats update
properly and sometimes we get nothing there at all. We haven't run
wireshark traces for every call to compare, maybe I'll spend some time
on that.

You are right, it looks OK with canary.

Have in mind that RTCP FB messages are hard to spot because of SRTCP:
chrome usually sends them in a compound packet with an RR and only the
first packet's headers are readable.

        I'm also still mystified how Jitsi meet clients get video
        without any
        feedback being sent by the client. I believe the bridge will
        force a
        key frame when doing a switch, but I have no clue as to why
that
        logic
        doesn't seem to result in video for Client 2 when they join in
our
        scenario. We'll be looking at disabling bundle/rtcp-mux soon
to see
        what that shows.

    If RTCP feedback is broken for some reason, this could be caused by
    this:
    https://github.com/jitsi/jitsi-meet/issues/274

    I only see it rarely, but there could be something that makes it
    happen more often for you...again :slight_smile:

This at least /sounds/ exactly like what we're seeing. What can I do
to
help you debug/reproduce?

You can check if this is indeed what you are running into by adding a
print here:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L799

For debugging -- I don't know. I don't think any of us is actively
looking into it right now (it is a low prio, since it only results in a
slight delay when RTCP FB works). It looks like for some reason the DTLS
connect thread is too slow to initialize the transformer:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L914

But this is all I know and I don't see how to debug it at the moment.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
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

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
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

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


#15

Slight correction, the fix described in #2 would actually be done in
RtpChannelDatagramFilter::acceptRTCP (since this is where the RTCP is
dropped now, and is called before
RTPChannel::acceptControlInputStreamDatagramPacket).
We have access to the channel there, so we would be able to call
addReceiveSSRC.

I'll note that the RtpChannelDatagramFilter::acceptRTCP method is only
checking two things currently: if the size of the packet is larger than 8
bytes, and if the ssrc is known. So obviously removing the ssrc check
there means the method won't be checking much. I don't know if there's a
compelling reason to strictly filter RTCP there which would be compromised
by allowing new sender SSRCs, if so we may need to go with another option.

···

On Thu, Nov 5, 2015 at 3:58 PM, Brian Baldino <brian@highfive.com> wrote:

Ok, I think I've got a bit of info here:

RTCP with an ssrc of 1 gets dropped
in RtpChannelDatagramFilter::acceptRTCP. That method checks if the sender
ssrc is in the RTPChannel's ssrcs and, if not, drops it. The RTPChannel's
ssrcs get populated via RTPChannel::acceptDataInputStreamDatagramPacket.
When acceptDataInputStreamDatagramPacket sees a packet with a new ssrc, it
adds it via addReceiveSSRC. RTCP is processed
in acceptControlInputStreamDatagramPacket and only RTCP bye messages are
examined (and handled via calling removeReceiveSSRC), logic for adding a
receive ssrc doesn't exist inside of
acceptControlInputStreamDatagramPacket, so it's not possible for an ssrc of
1 (sent only via RTCP) to get added there.

As for 'ssrcs' and 'sources' in colibri, this is what I see:
1) The 'ssrcs' field is ignored when issuing a colibri patch to the
bridge, but when a get is requested, it is populated with the values added
via addReceiveSSRC.
2) The 'sources' field will populate the 'ssrcs' value when issuing a
colibri patch (it will take those values and call addReceiveSSRC), however
when doing a get, the 'sources' field is populated with the BRIDGE source
ssrcs (the dummy audio and video streams). This comes from
RtpChannel::describe where it fills in the 'sources' field with its local
ssrc.

If I add the "1" ssrc as a source, it properly gets added as a receive
ssrc, which means that when RtpChannelDatagramFilter::acceptRTCP sees an
RTCP packet with a sender ssrc of "1", it will forward it correctly.

So it seems that there are some conflicting definitions/usages of 'ssrcs'
and 'sources' in a channel. It appears as though "sources" are meant to
reflect streams coming from the bridge (but they only ever seem to contain
the streams which *originate* at the bridge, not the ones it forwards), and
"ssrcs" are the streams that the bridge should expect to receive on that
channel (either via the rtp packet ssrc or the senderssrc field in an rtcp
packet).

So a couple options that came to mind were:
1) Signal the "1" ssrc via the 'sources' block in colibri. This works,
but seems to further contribute to the current confusion in how 'sources'
and 'ssrcs' are used. Also, other ssrcs don't need to be explicitly
signaled (they get added automatically) so this doesn't seem to be very
consistent with existing behavior. This wouldn't break existing clients,
but failing to make this change will break clients based on chrome when
their in recvonly for video.
2) Have the acceptDataInputStreamDatagramPacket add any new sender ssrcs
it sees automatically, this matches what we do with normal rtp ssrcs and
would not require any changes from clients.
3) Always require ssrcs to be signaled explicitly. Never add a ssrc
implicitly, only accept those that have been signaled explicitly and
require the client to configure the ssrcs correctly. This would break all
clients :frowning:

Regardless of which option (the above or something else) we choose to
solve this, I think there is some cleanup to be done around the usage of
'sources' and 'ssrcs' as well.

-brian

On Wed, Nov 4, 2015 at 9:51 AM, George Politis <gp@jitsi.org> wrote:

Hi Brian,

Please let us know how it goes. If you have a bleeding edge bridge you
can have it capture decrypted packets (both RTP and RTCP), which can help
you determine whether the bridge correctly forwards RTCP packets with SSRC
1. You can find detailed instructions on how to use this functionality here
[1], in the Javadoc of the DebugTransformEngine.

-
George

[1]:
https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/DebugTransformEngine.java

On Nov 4, 2015, at 10:50 AM, Brian Baldino <brian@highfive.com> wrote:

Thanks George! I believe I tried as you described, but it seemed to
cause issues (I don't think I got video flowing either way). I'll try
adding that again and see if I can figure out what's going wrong.

On Wed, Nov 4, 2015 at 8:20 AM, George Politis <gp@jitsi.org> wrote:

Hi Brian,

I guess we’re not so clear about ‘ssrc’ either. It’s a old relic that's
deprecated afaik. Configuring SSRC 1 as a ‘source’ should have the desired
effect though; How do you format your JSON object? Looking at the code, it
should be defined in a `‘sources’: [1, 443343433, …]` array inside the
channel.

Best,
George

On Nov 3, 2015, at 8:33 PM, Brian Baldino <brian@highfive.com> wrote:

Bringing this back up since we're running into it again in the
legitimate use case (a client video muting).

What's the official way to have the bridge accept RTCP with a sender
SSRC of "1"? I tried configuring it as an "ssrc" on the channel (via the
REST API patch)...but the bridge doesn't seem to actually read from this
field. 'sources' also doesn't seem to give the right behavior (though I'll
admit I'm not entirely clear on the difference in roles between 'sources'
and 'ssrcs' on a channel).

-brian

On Wed, May 20, 2015 at 9:25 AM, Brian Baldino <brian@highfive.com> >>> wrote:

No problem Boris, thanks. We were able to get past the issue now, here
is, I think, a summary of what we found:

1) Chrome has an issue where a receive stream can be created before a
send stream (even if the description describes both). In this case, the
receive stream will use "1" as the local SSRC and will not get updated when
the send stream gets created after (I posted about this on the
discuss-webrtc list, and this bug
<https://code.google.com/p/webrtc/issues/detail?id=4678> was created
to track it). For us, this was happening when a client joined a call which
already had a client in it and we included all client SSRCs in the call in
the initial offer to this new client. We fixed this by always sending an
initial offer with just the bridge's dummy SSRCs, and adding the SSRCs for
other clients in a separate offer (I believe this is what Jitsi meet does,
which explains why we weren't seeing it there as consistently). This issue
presented itself as: audio and video for the second client taking a long
time to render as well as frequent frozen video.

2) Even though the behavior in the above scenario on Chrome is a bug,
there are scenarios where Chrome does (by design) use an SSRC of 1 for rtcp
feedback, jitsi videobridge fails to forward this in two places: 1) it
drops them in RTPChannelDatagramFilter due to the sender SSRC "1" not being
recognized for that channel and 2) (assuming #1 has been changed to not
drop the feedback packet) the derived SRTCP context for these packets (when
forwarding them on to the far side client) seems to be incorrect, causing
them to fail authentication by the far side client.

3) I do not know if the workaround for #1 is 100% foolproof, as we've
seen instances of this same failure in jitsi meet calls as well.

-brian

On Tue, May 19, 2015 at 10:03 PM, Boris Grozev <boris@jitsi.org> wrote:

Hi Brian,

Sorry for the slow response (inline).

On 19/05/15 02:56, Brian Baldino wrote:

Thanks Boris! Inline.

On Mon, May 18, 2015 at 3:40 PM, Boris Grozev <boris@jitsi.org >>>>>> <mailto:boris@jitsi.org>> wrote:

    Hi Brian,

    On 19/05/15 01:04, Brian Baldino wrote:

        I'm still digging deeper...I believe I've successfully got
PLIs
        passing
        through the video bridge from Client 2 to Client 1, but
Client 1
        doesn't
        register them on chrome://webrtc-internals. I notice that
on chrome
        stable, I don't see receivers register sending any feedback in
        webrtc-internals, but on my build of chromium (a couple
versions
        ahead)
        it fires off lots of PLIs, perhaps there are some changes in
        chrome's
        webrtc stack there?

    I suspect there might be an issue with FB reporting in
    webrtc-internals in chrome stable -- number of NACKs sent stay at
0
    for me, even though I see them on the network. I'll try to confirm
    and open an issue tomorrow.

Yeah you may be right. Perhaps the reason for the differences I've
seen
in chrome stable vs. canary are some fixes there, have you tried
running
that test with a canary build and seeing if the stats match? Either
way, it's been very confusing...sometimes we do see stats update
properly and sometimes we get nothing there at all. We haven't run
wireshark traces for every call to compare, maybe I'll spend some time
on that.

You are right, it looks OK with canary.

Have in mind that RTCP FB messages are hard to spot because of SRTCP:
chrome usually sends them in a compound packet with an RR and only the
first packet's headers are readable.

        I'm also still mystified how Jitsi meet clients get video
        without any
        feedback being sent by the client. I believe the bridge will
        force a
        key frame when doing a switch, but I have no clue as to why
that
        logic
        doesn't seem to result in video for Client 2 when they join
in our
        scenario. We'll be looking at disabling bundle/rtcp-mux soon
to see
        what that shows.

    If RTCP feedback is broken for some reason, this could be caused
by
    this:
    https://github.com/jitsi/jitsi-meet/issues/274

    I only see it rarely, but there could be something that makes it
    happen more often for you...again :slight_smile:

This at least /sounds/ exactly like what we're seeing. What can I do
to
help you debug/reproduce?

You can check if this is indeed what you are running into by adding a
print here:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L799

For debugging -- I don't know. I don't think any of us is actively
looking into it right now (it is a low prio, since it only results in a
slight delay when RTCP FB works). It looks like for some reason the DTLS
connect thread is too slow to initialize the transformer:

https://github.com/jitsi/libjitsi/blob/master/src/org/jitsi/impl/neomedia/transform/dtls/DtlsPacketTransformer.java#L914

But this is all I know and I don't see how to debug it at the moment.

Regards,
Boris

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
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

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
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

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


#16

Hey Brian,

Ok, I think I've got a bit of info here:

RTCP with an ssrc of 1 gets dropped
in RtpChannelDatagramFilter::acceptRTCP. That method checks if the
sender ssrc is in the RTPChannel's ssrcs and, if not, drops it. The
RTPChannel's ssrcs get populated
via RTPChannel::acceptDataInputStreamDatagramPacket. When
acceptDataInputStreamDatagramPacket sees a packet with a new ssrc, it
adds it via addReceiveSSRC. RTCP is processed
in acceptControlInputStreamDatagramPacket and only RTCP bye messages are
examined (and handled via calling removeReceiveSSRC), logic for adding a
receive ssrc doesn't exist inside of
acceptControlInputStreamDatagramPacket, so it's not possible for an ssrc
of 1 (sent only via RTCP) to get added there.

The problem here stems from the way RTCP packets are demultiplexed between channels. With bundle both audio and video use the same socket, and RtpChannelDatagramFilter is used for each packet on the socket, and it's purpose is to determine whether the given packet belongs to its RtpChannel.

For RTP packets this is done on the basis of the Payload Type (which is why Payload Types for each channel must be signaled to the bridge). For RTCP packets, however, this is done on the basis of the Packet Sender SSRC.

Now, RtpChannel.accept*InputStreamDatagramPacket is only called for packets which have passed the RtpChannelDatagramFilter test, so if it executes for an RTCP packet, then the SSRC is already in receiveSSRCs.

The reason we update receiveSSRCs on reception of RTP packets, is to allow the recognition of RTCP packets for these streams in the absence of signaled SSRCs. However, for receive-only endpoints, this doesn't work, and their SSRCs (or "1" in your case) need to be signaled through COLIBRI.

As for 'ssrcs' and 'sources' in colibri, this is what I see:
1) The 'ssrcs' field is ignored when issuing a colibri patch to the
bridge, but when a get is requested, it is populated with the values
added via addReceiveSSRC.

I think this might be something used by the Jitsi client, in order to match the remove peers to SSRCs without signalling them in Jingle. AFAIK this isn't used anywhere in a Jitsi-Meet scenario, and I think you can just ignore it.

2) The 'sources' field will populate the 'ssrcs' value when issuing a
colibri patch (it will take those values and call addReceiveSSRC),
however when doing a get, the 'sources' field is populated with the
BRIDGE source ssrcs (the dummy audio and video streams). This comes
from RtpChannel::describe where it fills in the 'sources' field with its
local ssrc.

If I add the "1" ssrc as a source, it properly gets added as a receive
ssrc, which means that when RtpChannelDatagramFilter::acceptRTCP sees an
RTCP packet with a sender ssrc of "1", it will forward it correctly.

This is the intention, and this is the way we signal SSRCs in Jitsi-Meet/Jicofo.

So it seems that there are some conflicting definitions/usages of
'ssrcs' and 'sources' in a channel. It appears as though "sources" are
meant to reflect streams coming from the bridge (but they only ever seem
to contain the streams which *originate* at the bridge, not the ones it
forwards), and "ssrcs" are the streams that the bridge should expect to
receive on that channel (either via the rtp packet ssrc or the
senderssrc field in an rtcp packet).

I think the idea is that "sources" sent *to* the bridge contain the SSRCs which it should expect on the given channel, while "sources" sent *from* the bridge contain the SSRCs of streams that belong to the bridge.

So a couple options that came to mind were:
1) Signal the "1" ssrc via the 'sources' block in colibri. This works,
but seems to further contribute to the current confusion in how
'sources' and 'ssrcs' are used. Also, other ssrcs don't need to be
explicitly signaled (they get added automatically) so this doesn't seem
to be very consistent with existing behavior. This wouldn't break
existing clients, but failing to make this change will break clients
based on chrome when their in recvonly for video.

IIRC, we left this to the client/conference focus to take care of (i.e. make sure that SSRCs are signaled even for receive-only endpoints). I think this is reasonable, since WebRTC endpoints require the SSRCs anyway (except for that corner case where they know what to do with "1").

2) Have the acceptDataInputStreamDatagramPacket add any new sender ssrcs
it sees automatically, this matches what we do with normal rtp ssrcs and
would not require any changes from clients.
3) Always require ssrcs to be signaled explicitly. Never add a ssrc
implicitly, only accept those that have been signaled explicitly and
require the client to configure the ssrcs correctly. This would break
all clients :frowning:

We do what we can to work without explicitly signaled SSRCs, but I don't see anything practical that we can do in the case of receive-only endpoints.
At some point we discussed decrypting the RTCP packet, somehow finding its "destination" SSRC (which would depend on the type of RTCP packet), searching for another channel (either audio or video) which has the destination SSRC. But that's very involved.

Regardless of which option (the above or something else) we choose to
solve this, I think there is some cleanup to be done around the usage of
'sources' and 'ssrcs' as well.

I would suggest properly documenting both of them, and possibly adding an option to disable the use of "ssrcs".

···

On 05/11/15 17:58, Brian Baldino wrote:

On 06/11/15 16:31, Brian Baldino wrote:
> Slight correction, the fix described in #2 would actually be done in
> RtpChannelDatagramFilter::acceptRTCP (since this is where the RTCP is
> dropped now, and is called before
> RTPChannel::acceptControlInputStreamDatagramPacket). We have access to
> the channel there, so we would be able to call addReceiveSSRC.

The problem here is that for each RTCP packet we call RtpChannelDatagramFilter#acceptRTCP twice -- once on the audio channel, and once on the video channel.

Regards,
Boris


#17

Thanks Boris! Added some thoughts inline, but for now sounds like
explicitly signaling the "1" ssrc in the sources field of the video channel
is the way to go.

-brian

Hey Brian,

Ok, I think I've got a bit of info here:

RTCP with an ssrc of 1 gets dropped
in RtpChannelDatagramFilter::acceptRTCP. That method checks if the
sender ssrc is in the RTPChannel's ssrcs and, if not, drops it. The
RTPChannel's ssrcs get populated
via RTPChannel::acceptDataInputStreamDatagramPacket. When
acceptDataInputStreamDatagramPacket sees a packet with a new ssrc, it
adds it via addReceiveSSRC. RTCP is processed
in acceptControlInputStreamDatagramPacket and only RTCP bye messages are
examined (and handled via calling removeReceiveSSRC), logic for adding a
receive ssrc doesn't exist inside of
acceptControlInputStreamDatagramPacket, so it's not possible for an ssrc
of 1 (sent only via RTCP) to get added there.

The problem here stems from the way RTCP packets are demultiplexed between
channels. With bundle both audio and video use the same socket, and
RtpChannelDatagramFilter is used for each packet on the socket, and it's
purpose is to determine whether the given packet belongs to its RtpChannel.

For RTP packets this is done on the basis of the Payload Type (which is
why Payload Types for each channel must be signaled to the bridge). For
RTCP packets, however, this is done on the basis of the Packet Sender SSRC.

Now, RtpChannel.accept*InputStreamDatagramPacket is only called for
packets which have passed the RtpChannelDatagramFilter test, so if it
executes for an RTCP packet, then the SSRC is already in receiveSSRCs.

The reason we update receiveSSRCs on reception of RTP packets, is to allow
the recognition of RTCP packets for these streams in the absence of
signaled SSRCs. However, for receive-only endpoints, this doesn't work, and
their SSRCs (or "1" in your case) need to be signaled through COLIBRI.

Thanks, this helps clear things up and puts it all in better context.

As for 'ssrcs' and 'sources' in colibri, this is what I see:
1) The 'ssrcs' field is ignored when issuing a colibri patch to the
bridge, but when a get is requested, it is populated with the values
added via addReceiveSSRC.

I think this might be something used by the Jitsi client, in order to
match the remove peers to SSRCs without signalling them in Jingle. AFAIK
this isn't used anywhere in a Jitsi-Meet scenario, and I think you can just
ignore it.

2) The 'sources' field will populate the 'ssrcs' value when issuing a

colibri patch (it will take those values and call addReceiveSSRC),
however when doing a get, the 'sources' field is populated with the
BRIDGE source ssrcs (the dummy audio and video streams). This comes
from RtpChannel::describe where it fills in the 'sources' field with its
local ssrc.

If I add the "1" ssrc as a source, it properly gets added as a receive
ssrc, which means that when RtpChannelDatagramFilter::acceptRTCP sees an
RTCP packet with a sender ssrc of "1", it will forward it correctly.

This is the intention, and this is the way we signal SSRCs in
Jitsi-Meet/Jicofo.

Gotcha, will proceed with this method on our side then.

So it seems that there are some conflicting definitions/usages of
'ssrcs' and 'sources' in a channel. It appears as though "sources" are
meant to reflect streams coming from the bridge (but they only ever seem
to contain the streams which *originate* at the bridge, not the ones it
forwards), and "ssrcs" are the streams that the bridge should expect to
receive on that channel (either via the rtp packet ssrc or the
senderssrc field in an rtcp packet).

I think the idea is that "sources" sent *to* the bridge contain the SSRCs
which it should expect on the given channel, while "sources" sent *from*
the bridge contain the SSRCs of streams that belong to the bridge.

I see what you mean, but it is a bit confusing the way this is done because
you send a patch on a channel and the next time you get it, it's reversed
(i.e. you send an ssrc in "sources" and the bridge responds with it in
"ssrcs"). If I remember right, this isn't consistent with something like,
for example, "direction" on a channel...if you put "recvonly" in a patch
(meaning the client wants only to receive from the bridge), the bridge
doesn't translate it to "sendonly" (which is the direction from the
bridge's point of view) --the caller has to do that translation on their
own.

So a couple options that came to mind were:
1) Signal the "1" ssrc via the 'sources' block in colibri. This works,
but seems to further contribute to the current confusion in how
'sources' and 'ssrcs' are used. Also, other ssrcs don't need to be
explicitly signaled (they get added automatically) so this doesn't seem
to be very consistent with existing behavior. This wouldn't break
existing clients, but failing to make this change will break clients
based on chrome when their in recvonly for video.

IIRC, we left this to the client/conference focus to take care of (i.e.
make sure that SSRCs are signaled even for receive-only endpoints). I think
this is reasonable, since WebRTC endpoints require the SSRCs anyway (except
for that corner case where they know what to do with "1").

2) Have the acceptDataInputStreamDatagramPacket add any new sender ssrcs

it sees automatically, this matches what we do with normal rtp ssrcs and
would not require any changes from clients.
3) Always require ssrcs to be signaled explicitly. Never add a ssrc
implicitly, only accept those that have been signaled explicitly and
require the client to configure the ssrcs correctly. This would break
all clients :frowning:

We do what we can to work without explicitly signaled SSRCs, but I don't
see anything practical that we can do in the case of receive-only endpoints.
At some point we discussed decrypting the RTCP packet, somehow finding its
"destination" SSRC (which would depend on the type of RTCP packet),
searching for another channel (either audio or video) which has the
destination SSRC. But that's very involved.

Yeah, I agree at this point it feels cleaner to just have it signaled
explicitly.

Regardless of which option (the above or something else) we choose to
solve this, I think there is some cleanup to be done around the usage of
'sources' and 'ssrcs' as well.

I would suggest properly documenting both of them, and possibly adding an
option to disable the use of "ssrcs".

Yeah, I don't know if it's an artifact of the REST API, and maybe when
doing xmpp things are cleaner, but it can get a bit confusing determining
which 'point-of-view' things are being described from when sending patches
and receiving responses.

> Slight correction, the fix described in #2 would actually be done in
> RtpChannelDatagramFilter::acceptRTCP (since this is where the RTCP is
> dropped now, and is called before
> RTPChannel::acceptControlInputStreamDatagramPacket). We have access to
> the channel there, so we would be able to call addReceiveSSRC.

The problem here is that for each RTCP packet we call
RtpChannelDatagramFilter#acceptRTCP twice -- once on the audio channel, and
once on the video channel.

Gotcha, don't think I'd realized that--that helps. Thanks.

···

On Sun, Nov 8, 2015 at 8:57 AM, Boris Grozev <boris@jitsi.org> wrote:

On 05/11/15 17:58, Brian Baldino wrote:
On 06/11/15 16:31, Brian Baldino wrote:

Regards,
Boris

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


#18

Related:
https://codereview.webrtc.org/1438183002

If I am reading this correctly, chrome used to use an SSRC of "1" for audio as well (when no SSRC is signaled), but that's now switched to 0xFA17FA17.

Regards,
Boris

···

On 08/11/15 15:16, Brian Baldino wrote:

Thanks Boris! Added some thoughts inline, but for now sounds like
explicitly signaling the "1" ssrc in the sources field of the video
channel is the way to go.