[jitsi-dev] jitsi videobridge rtcp handling

Archive
1

Is the ‘mixed*’ SSRC value the sources id from the API Post? What exactly is the purpose of the ‘mixed*’. stream?

“contents”: [

    {

        "channels": [

            {

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

                "sources": [

                    **3063051425**

                ],

…

On discuss-webrtc juberti said: “Note also that resetting a remote description to trigger a key frame is going away in M35. You should use RTCP FIR instead.”

···

2015-05-18 17:07 GMT+02:00 Boris Grozev boris@jitsi.org:

On 18/05/15 17:20, dr.andreas.rice@gmx.net wrote:

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

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

2

Precisely this -- allow the bridge to send RTCP packets if it needs to.

Boris

···

On 18/05/15 22:40, dr.andreas.rice@gmx.net wrote:

Is the'mixed*' SSRC value the sources id from the API Post? What exactly
is the purpose of the 'mixed*'. stream?

3

Maybe another data point: after changing the bridge to forward RTCP packets
with SSRC 1, I've been able to get PLI packets to the remote client, but I
run into authentication failures for PLI packets on the remote side (from
my example before: Client 2 sends a PLI, it gets to Client 1, but the
webrtc stack on Client 1 is unable to authenticate it (unprotect) for some
reason). It looks like this happens with all PLI & receiver report packets
(sender reports don't appear to have this problem).

···

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

On 18/05/15 22:40, dr.andreas.rice@gmx.net wrote:

Is the'mixed*' SSRC value the sources id from the API Post? What exactly
is the purpose of the 'mixed*'. stream?

Precisely this -- allow the bridge to send RTCP packets if it needs to.

Boris

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

4

So SRs make it through fine since they've got a real SSRC, RRs and PLIs
both use the "1" SSRC. I notice in SRTCPTransformer::transform it calls
getContext which tries to find the crypto context for the given SSRC.
Since it won't find anything with a "1" SSRC it tries to derive the
context...maybe there's a bug there? It seems like packets with that
derived context are failing on the receiving client.

···

On Mon, May 18, 2015 at 7:13 PM, Brian Baldino <brian@highfive.com> wrote:

Maybe another data point: after changing the bridge to forward RTCP
packets with SSRC 1, I've been able to get PLI packets to the remote
client, but I run into authentication failures for PLI packets on the
remote side (from my example before: Client 2 sends a PLI, it gets to
Client 1, but the webrtc stack on Client 1 is unable to authenticate it
(unprotect) for some reason). It looks like this happens with all PLI &
receiver report packets (sender reports don't appear to have this problem).

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

On 18/05/15 22:40, dr.andreas.rice@gmx.net wrote:

Is the'mixed*' SSRC value the sources id from the API Post? What exactly
is the purpose of the 'mixed*'. stream?

Precisely this -- allow the bridge to send RTCP packets if it needs to.

Boris

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