[jitsi-dev] jitsi videobridge rtcp handling


#1

We've built a client to connect to the jitsi video bridge (using our own
signaling which leverages the REST api of the bridge instead of jicofo) and
we're running into the following situation:

Client 1 joins
Client 2 joins
Client 1 sees Client 2's video (after just a second or two)
Client 2 does not get Client 1's video for quite some time (often 30+
seconds). Client 2 is sending lots of PLI messages but they never seem to
make it to Client 1.

I've verified with wireshark that Client 2's PLI messages are hitting the
bridge, but when adding debug code inside the bridge itself (I'm printing
the payloads inside of RTPConnectorInputStream), I see sender reports but
not PLI messages. I also can see that they never reach Client 1.

We're doing bundle and rtcp-mux, if that adds any other info. We haven't
done anything to explicitly set an RTCP termination strategy, so whatever
we're using is just the default. Calls with the normal jitsi meet client
using this same bridge work fine (though I have seen some instances of PLI
messages not making it all the way back to the sender). I will point out
we haven't implemented a lot of the xmpp signaling (or any of the
datachannel signaling) jitsi messages--I've been assuming that the normal
rtcp feedback should be enough to drive getting a key frame when a new
client joins/sees loss.

Happy to provide any other info that will help, we see this happening
basically every single time. We've gathered lots of logs and info but I'll
hold off on pasting everything here to start, maybe there's something
obvious we're missing or that we can check we haven't thought off.

Thanks!

-brian


#2

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?

···

On Thu, May 14, 2015 at 2:40 PM, Brian Baldino <brian@highfive.com> wrote:

We've built a client to connect to the jitsi video bridge (using our own
signaling which leverages the REST api of the bridge instead of jicofo) and
we're running into the following situation:

Client 1 joins
Client 2 joins
Client 1 sees Client 2's video (after just a second or two)
Client 2 does not get Client 1's video for quite some time (often 30+
seconds). Client 2 is sending lots of PLI messages but they never seem to
make it to Client 1.

I've verified with wireshark that Client 2's PLI messages are hitting the
bridge, but when adding debug code inside the bridge itself (I'm printing
the payloads inside of RTPConnectorInputStream), I see sender reports but
not PLI messages. I also can see that they never reach Client 1.

We're doing bundle and rtcp-mux, if that adds any other info. We haven't
done anything to explicitly set an RTCP termination strategy, so whatever
we're using is just the default. Calls with the normal jitsi meet client
using this same bridge work fine (though I have seen some instances of PLI
messages not making it all the way back to the sender). I will point out
we haven't implemented a lot of the xmpp signaling (or any of the
datachannel signaling) jitsi messages--I've been assuming that the normal
rtcp feedback should be enough to drive getting a key frame when a new
client joins/sees loss.

Happy to provide any other info that will help, we see this happening
basically every single time. We've gathered lots of logs and info but I'll
hold off on pasting everything here to start, maybe there's something
obvious we're missing or that we can check we haven't thought off.

Thanks!

-brian


#3

It only does that on recvonly streams IIRC. See https://groups.google.com/forum/#!searchin/discuss-webrtc/ssrc|sort:date/discuss-webrtc/5yuZjV7lkNc/fFlDhcGvpV0J for some discussion.

···

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?


#4

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

Boris

···

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


#5

I had read about chrome using 1 for the rtcp ssrc, but hadn't realized it
was tied to recvonly streams...we don't have anything that's set to
recvonly here (pasted the remote and local descriptions below) so not sure
why that'd be triggering. I've got a build of chromium going, maybe I can
find why it's setting the ssrc to 1 for PLI messages.

type: offer, sdp: v=0
o=- ef649da4b18f1b49 1431704149951 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:audio
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxxx 10015 typ srflx raddr
10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4231486479 cname:mixed
a=ssrc:4231486479 label:mixedlabelaudio0
a=ssrc:4231486479 msid:mixedmslabel mixedlabelaudio0
a=ssrc:4231486479 mslabel:mixedmslabel
m=video 1 RTP/SAVPF 126 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:video
a=rtpmap:126 H264/90000
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxx 10015 typ srflx raddr 10.205.1.95
rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4010208404 cname:mixed
a=ssrc:4010208404 label:mixedlabelvideo0
a=ssrc:4010208404 msid:mixedmslabel mixedlabelvideo0
a=ssrc:4010208404 mslabel:mixedmslabel

type: answer, sdp: v=0
o=- 7359431293216528830 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
m=audio 9 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=maxptime:60
a=ssrc:994900336 cname:tdev9PhF2U7XYaOP
a=ssrc:994900336 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
216a8c4b-8447-479c-80d7-607d2e4a6851
a=ssrc:994900336 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:994900336 label:216a8c4b-8447-479c-80d7-607d2e4a6851
m=video 9 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:2500397614 cname:tdev9PhF2U7XYaOP
a=ssrc:2500397614 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
ef17cfc1-e63e-4693-a0b4-97c00d8c94ca
a=ssrc:2500397614 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:2500397614 label:ef17cfc1-e63e-4693-a0b4-97c00d8c94ca

···

DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1

On Thu, May 14, 2015 at 10:18 PM, Boris Grozev <boris@jitsi.org> wrote:

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

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

Boris

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


#6

So I looked into this some more and found that the issue is chrome creates
the receive stream before the send stream. Because the send stream isn't
created yet, the receive stream gets created with a default ssrc of 1.
When the send stream does get created, the receive stream doesn't get
updated with the correct ssrc (which seems like a webrtc bug to me?).

Unfortunately I keep running into the same problem with jitsi meet on my
chromium build, so I can't compare things when they work. (Jitsi meet
works in chrome stable, but fails on my chromium build...our client sees
this problem both on my chromium build and chrome stable)

···

On Fri, May 15, 2015 at 8:38 AM, Brian Baldino <brian@highfive.com> wrote:

I had read about chrome using 1 for the rtcp ssrc, but hadn't realized it
was tied to recvonly streams...we don't have anything that's set to
recvonly here (pasted the remote and local descriptions below) so not sure
why that'd be triggering. I've got a build of chromium going, maybe I can
find why it's setting the ssrc to 1 for PLI messages.

type: offer, sdp: v=0
o=- ef649da4b18f1b49 1431704149951 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:audio
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxxx 10015 typ srflx raddr
10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4231486479 cname:mixed
a=ssrc:4231486479 label:mixedlabelaudio0
a=ssrc:4231486479 msid:mixedmslabel mixedlabelaudio0
a=ssrc:4231486479 mslabel:mixedmslabel
m=video 1 RTP/SAVPF 126 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:video
a=rtpmap:126 H264/90000
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxx 10015 typ srflx raddr
10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4010208404 cname:mixed
a=ssrc:4010208404 label:mixedlabelvideo0
a=ssrc:4010208404 msid:mixedmslabel mixedlabelvideo0
a=ssrc:4010208404 mslabel:mixedmslabel

type: answer, sdp: v=0
o=- 7359431293216528830 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
m=audio 9 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=maxptime:60
a=ssrc:994900336 cname:tdev9PhF2U7XYaOP
a=ssrc:994900336 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
216a8c4b-8447-479c-80d7-607d2e4a6851
a=ssrc:994900336 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:994900336 label:216a8c4b-8447-479c-80d7-607d2e4a6851
m=video 9 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:2500397614 cname:tdev9PhF2U7XYaOP
a=ssrc:2500397614 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
ef17cfc1-e63e-4693-a0b4-97c00d8c94ca
a=ssrc:2500397614 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:2500397614 label:ef17cfc1-e63e-4693-a0b4-97c00d8c94ca

On Thu, May 14, 2015 at 10:18 PM, Boris Grozev <boris@jitsi.org> wrote:

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

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

Boris

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


#7

Hello Brian,

We have some filtering in place when bundle is used, but it shouldn't cause any problems for sendrecv channels. Can you check if disabling bundle/rtcp-mux makes any difference?

Thanks.

Best regards,
George

···

On 15 May 2015, at 17:38, Brian Baldino wrote:

I had read about chrome using 1 for the rtcp ssrc, but hadn't realized it
was tied to recvonly streams...we don't have anything that's set to
recvonly here (pasted the remote and local descriptions below) so not sure
why that'd be triggering. I've got a build of chromium going, maybe I can
find why it's setting the ssrc to 1 for PLI messages.

type: offer, sdp: v=0
o=- ef649da4b18f1b49 1431704149951 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:audio
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxxx 10015 typ srflx raddr
10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4231486479 cname:mixed
a=ssrc:4231486479 label:mixedlabelaudio0
a=ssrc:4231486479 msid:mixedmslabel mixedlabelaudio0
a=ssrc:4231486479 mslabel:mixedmslabel
m=video 1 RTP/SAVPF 126 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:video
a=rtpmap:126 H264/90000
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxx 10015 typ srflx raddr 10.205.1.95
rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4010208404 cname:mixed
a=ssrc:4010208404 label:mixedlabelvideo0
a=ssrc:4010208404 msid:mixedmslabel mixedlabelvideo0
a=ssrc:4010208404 mslabel:mixedmslabel

type: answer, sdp: v=0
o=- 7359431293216528830 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
m=audio 9 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=maxptime:60
a=ssrc:994900336 cname:tdev9PhF2U7XYaOP
a=ssrc:994900336 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
216a8c4b-8447-479c-80d7-607d2e4a6851
a=ssrc:994900336 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:994900336 label:216a8c4b-8447-479c-80d7-607d2e4a6851
m=video 9 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:2500397614 cname:tdev9PhF2U7XYaOP
a=ssrc:2500397614 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
ef17cfc1-e63e-4693-a0b4-97c00d8c94ca
a=ssrc:2500397614 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:2500397614 label:ef17cfc1-e63e-4693-a0b4-97c00d8c94ca

On Thu, May 14, 2015 at 10:18 PM, Boris Grozev <boris@jitsi.org> > wrote:

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

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

Boris

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

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


#8

Hi Brian,

This is the remote/local description for your Client 1 I suppose, right? The remote description doesn't contain any streams from your other client. Can you paste the remote/local descriptions for Client 2 as well?

Also, can you please try with bundle/rtcp-mux disabled and let us know if it makes any difference?

Thanks.

Best regards,
George

···

On 15 May 2015, at 17:38, Brian Baldino wrote:

I had read about chrome using 1 for the rtcp ssrc, but hadn't realized it
was tied to recvonly streams...we don't have anything that's set to
recvonly here (pasted the remote and local descriptions below) so not sure
why that'd be triggering. I've got a build of chromium going, maybe I can
find why it's setting the ssrc to 1 for PLI messages.

type: offer, sdp: v=0
o=- ef649da4b18f1b49 1431704149951 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:audio
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxxx 10015 typ srflx raddr
10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4231486479 cname:mixed
a=ssrc:4231486479 label:mixedlabelaudio0
a=ssrc:4231486479 msid:mixedmslabel mixedlabelaudio0
a=ssrc:4231486479 mslabel:mixedmslabel
m=video 1 RTP/SAVPF 126 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:video
a=rtpmap:126 H264/90000
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxx 10015 typ srflx raddr 10.205.1.95
rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4010208404 cname:mixed
a=ssrc:4010208404 label:mixedlabelvideo0
a=ssrc:4010208404 msid:mixedmslabel mixedlabelvideo0
a=ssrc:4010208404 mslabel:mixedmslabel

type: answer, sdp: v=0
o=- 7359431293216528830 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
m=audio 9 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=maxptime:60
a=ssrc:994900336 cname:tdev9PhF2U7XYaOP
a=ssrc:994900336 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
216a8c4b-8447-479c-80d7-607d2e4a6851
a=ssrc:994900336 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:994900336 label:216a8c4b-8447-479c-80d7-607d2e4a6851
m=video 9 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:2500397614 cname:tdev9PhF2U7XYaOP
a=ssrc:2500397614 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
ef17cfc1-e63e-4693-a0b4-97c00d8c94ca
a=ssrc:2500397614 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:2500397614 label:ef17cfc1-e63e-4693-a0b4-97c00d8c94ca

On Thu, May 14, 2015 at 10:18 PM, Boris Grozev <boris@jitsi.org> > wrote:

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

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

Boris

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

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


#9

Hey Brian,
Maybe that h264 offer in your sdp is causing a hiccup in codec negotiation and that’s what’s delaying the send stream. Is it possible to yank that out and see if the bad behavior goes away?

···

From: Brian Baldino
Reply-To: Jitsi Developers
Date: Friday, May 15, 2015 at 12:42 PM
To: Jitsi Developers
Subject: Re: [jitsi-dev] jitsi videobridge rtcp handling

So I looked into this some more and found that the issue is chrome creates the receive stream before the send stream. Because the send stream isn't created yet, the receive stream gets created with a default ssrc of 1. When the send stream does get created, the receive stream doesn't get updated with the correct ssrc (which seems like a webrtc bug to me?).

Unfortunately I keep running into the same problem with jitsi meet on my chromium build, so I can't compare things when they work. (Jitsi meet works in chrome stable, but fails on my chromium build...our client sees this problem both on my chromium build and chrome stable)

On Fri, May 15, 2015 at 8:38 AM, Brian Baldino <brian@highfive.com<mailto:brian@highfive.com>> wrote:
I had read about chrome using 1 for the rtcp ssrc, but hadn't realized it was tied to recvonly streams...we don't have anything that's set to recvonly here (pasted the remote and local descriptions below) so not sure why that'd be triggering. I've got a build of chromium going, maybe I can find why it's setting the ssrc to 1 for PLI messages.

type: offer, sdp: v=0
o=- ef649da4b18f1b49 1431704149951 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:audio
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxxx 10015 typ srflx raddr 10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1 DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4231486479 cname:mixed
a=ssrc:4231486479 label:mixedlabelaudio0
a=ssrc:4231486479 msid:mixedmslabel mixedlabelaudio0
a=ssrc:4231486479 mslabel:mixedmslabel
m=video 1 RTP/SAVPF 126 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:video
a=rtpmap:126 H264/90000
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxx 10015 typ srflx raddr 10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1 DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4010208404 cname:mixed
a=ssrc:4010208404 label:mixedlabelvideo0
a=ssrc:4010208404 msid:mixedmslabel mixedlabelvideo0
a=ssrc:4010208404 mslabel:mixedmslabel

type: answer, sdp: v=0
o=- 7359431293216528830 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
m=audio 9 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256 10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=maxptime:60
a=ssrc:994900336 cname:tdev9PhF2U7XYaOP
a=ssrc:994900336 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr 216a8c4b-8447-479c-80d7-607d2e4a6851
a=ssrc:994900336 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:994900336 label:216a8c4b-8447-479c-80d7-607d2e4a6851
m=video 9 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256 10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:2500397614 cname:tdev9PhF2U7XYaOP
a=ssrc:2500397614 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr ef17cfc1-e63e-4693-a0b4-97c00d8c94ca
a=ssrc:2500397614 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:2500397614 label:ef17cfc1-e63e-4693-a0b4-97c00d8c94ca

On Thu, May 14, 2015 at 10:18 PM, Boris Grozev <boris@jitsi.org<mailto:boris@jitsi.org>> wrote:
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
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


#10

Hey George,
You're right...I think I pasted the wrong SDPs. Here are the remote and
local descriptions from Client 2's perspective. I'll try it with
bundle/rtcp-mux disabled in the next day or so as well.

Thanks!
-brian

Remote:
type: offer, sdp: v=0
o=- f3ba8d65e91f97c2 1431795202527 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:audio
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=candidate:1 1 UDP 2130706431 10.205.1.95 10028 typ host generation 0
a=candidate:2 1 UDP 1694498815 54.184.33.175 10028 typ srflx raddr
10.205.1.95 rport 10028 generation 0
a=ice-ufrag:5okcp19leq9qaj
a=ice-pwd:1912ef1fvpo7ru8ptpli8hm1bc
a=fingerprint:sha-1
8F:DE:49:0D:A8:F4:FC:12:A1:6A:A3:3B:37:9B:1E:08:12:D6:25:5C
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:816665842 cname:mixed
a=ssrc:816665842 label:mixedlabelaudio0
a=ssrc:816665842 msid:mixedmslabel mixedlabelaudio0
a=ssrc:816665842 mslabel:mixedmslabel
a=ssrc:1215407363 cname:fwCELLZa4BhWZTBC
a=ssrc:1215407363 msid:cfiIhdfyFRP7vsm3isA42Qjk4dvt3Mu8k1tq
a3cc19d0-0c34-44cd-9128-bd21f391fc69
a=ssrc:1215407363 mslabel:cfiIhdfyFRP7vsm3isA42Qjk4dvt3Mu8k1tq
a=ssrc:1215407363 label:a3cc19d0-0c34-44cd-9128-bd21f391fc69
m=video 1 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:video
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=candidate:1 1 UDP 2130706431 10.205.1.95 10028 typ host generation 0
a=candidate:2 1 UDP 1694498815 54.184.33.175 10028 typ srflx raddr
10.205.1.95 rport 10028 generation 0
a=ice-ufrag:5okcp19leq9qaj
a=ice-pwd:1912ef1fvpo7ru8ptpli8hm1bc
a=fingerprint:sha-1
8F:DE:49:0D:A8:F4:FC:12:A1:6A:A3:3B:37:9B:1E:08:12:D6:25:5C
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:1023460165 cname:mixed
a=ssrc:1023460165 label:mixedlabelvideo0
a=ssrc:1023460165 msid:mixedmslabel mixedlabelvideo0
a=ssrc:1023460165 mslabel:mixedmslabel
a=ssrc:3298324324 cname:fwCELLZa4BhWZTBC
a=ssrc:3298324324 msid:cfiIhdfyFRP7vsm3isA42Qjk4dvt3Mu8k1tq
0d29cb81-eb6d-4436-aaeb-2224b70bd4b4
a=ssrc:3298324324 mslabel:cfiIhdfyFRP7vsm3isA42Qjk4dvt3Mu8k1tq
a=ssrc:3298324324 label:0d29cb81-eb6d-4436-aaeb-2224b70bd4b4

Local:

type: answer, sdp: v=0
o=- 736401372839882900 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS yCgYspcDKSfywGBJGwih5zuEks5lFuF5aHE6
m=audio 9 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:WPYFq9lO57X8mD68
a=ice-pwd:WpFxf7fww6q/6mHus+e8iL8v
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=maxptime:60
a=ssrc:3662438671 cname:i3kIwiv8SCF0wYO4
a=ssrc:3662438671 msid:yCgYspcDKSfywGBJGwih5zuEks5lFuF5aHE6
74975955-5248-490f-bb21-f058c5d482ab
a=ssrc:3662438671 mslabel:yCgYspcDKSfywGBJGwih5zuEks5lFuF5aHE6
a=ssrc:3662438671 label:74975955-5248-490f-bb21-f058c5d482ab
m=video 9 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:WPYFq9lO57X8mD68
a=ice-pwd:WpFxf7fww6q/6mHus+e8iL8v
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:3380334836 cname:i3kIwiv8SCF0wYO4
a=ssrc:3380334836 msid:yCgYspcDKSfywGBJGwih5zuEks5lFuF5aHE6
7e24c000-5a3d-4441-b959-8fb96eaeb9c8
a=ssrc:3380334836 mslabel:yCgYspcDKSfywGBJGwih5zuEks5lFuF5aHE6
a=ssrc:3380334836 label:7e24c000-5a3d-4441-b959-8fb96eaeb9c8

···

On Sat, May 16, 2015 at 2:39 AM, George Politis <gp@jitsi.org> wrote:

Hi Brian,

This is the remote/local description for your Client 1 I suppose, right?
The remote description doesn't contain any streams from your other client.
Can you paste the remote/local descriptions for Client 2 as well?

Also, can you please try with bundle/rtcp-mux disabled and let us know if
it makes any difference?

Thanks.

Best regards,
George

On 15 May 2015, at 17:38, Brian Baldino wrote:

I had read about chrome using 1 for the rtcp ssrc, but hadn't realized it

was tied to recvonly streams...we don't have anything that's set to
recvonly here (pasted the remote and local descriptions below) so not sure
why that'd be triggering. I've got a build of chromium going, maybe I can
find why it's setting the ssrc to 1 for PLI messages.

type: offer, sdp: v=0
o=- ef649da4b18f1b49 1431704149951 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:audio
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxxx 10015 typ srflx raddr
10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4231486479 cname:mixed
a=ssrc:4231486479 label:mixedlabelaudio0
a=ssrc:4231486479 msid:mixedmslabel mixedlabelaudio0
a=ssrc:4231486479 mslabel:mixedmslabel
m=video 1 RTP/SAVPF 126 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:video
a=rtpmap:126 H264/90000
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxx 10015 typ srflx raddr
10.205.1.95
rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4010208404 cname:mixed
a=ssrc:4010208404 label:mixedlabelvideo0
a=ssrc:4010208404 msid:mixedmslabel mixedlabelvideo0
a=ssrc:4010208404 mslabel:mixedmslabel

type: answer, sdp: v=0
o=- 7359431293216528830 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
m=audio 9 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256

10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=maxptime:60
a=ssrc:994900336 cname:tdev9PhF2U7XYaOP
a=ssrc:994900336 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
216a8c4b-8447-479c-80d7-607d2e4a6851
a=ssrc:994900336 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:994900336 label:216a8c4b-8447-479c-80d7-607d2e4a6851
m=video 9 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256

10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:2500397614 cname:tdev9PhF2U7XYaOP
a=ssrc:2500397614 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
ef17cfc1-e63e-4693-a0b4-97c00d8c94ca
a=ssrc:2500397614 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:2500397614 label:ef17cfc1-e63e-4693-a0b4-97c00d8c94ca

On Thu, May 14, 2015 at 10:18 PM, Boris Grozev <boris@jitsi.org> wrote:

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

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

Boris

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

_______________________________________________
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


#11

Thanks John,
Gave that a shot but still see the issue. From what I can tell, even in
working jitsi calls the same behavior (receive stream created before send
stream) seems to happen, so maybe this is an issue but something about the
way the jitsi meet client is written is working around it? Driving a key
frame in some other way, perhaps?

···

On Fri, May 15, 2015 at 2:59 PM, John Lightfoot <john@vizhn.com> wrote:

Hey Brian,
Maybe that h264 offer in your sdp is causing a hiccup in codec negotiation
and that’s what’s delaying the send stream. Is it possible to yank that
out and see if the bad behavior goes away?

  From: Brian Baldino
Reply-To: Jitsi Developers
Date: Friday, May 15, 2015 at 12:42 PM
To: Jitsi Developers
Subject: Re: [jitsi-dev] jitsi videobridge rtcp handling

  So I looked into this some more and found that the issue is chrome
creates the receive stream before the send stream. Because the send stream
isn't created yet, the receive stream gets created with a default ssrc of
1. When the send stream does get created, the receive stream doesn't get
updated with the correct ssrc (which seems like a webrtc bug to me?).

Unfortunately I keep running into the same problem with jitsi meet on my
chromium build, so I can't compare things when they work. (Jitsi meet
works in chrome stable, but fails on my chromium build...our client sees
this problem both on my chromium build and chrome stable)

On Fri, May 15, 2015 at 8:38 AM, Brian Baldino <brian@highfive.com> wrote:

I had read about chrome using 1 for the rtcp ssrc, but hadn't realized it
was tied to recvonly streams...we don't have anything that's set to
recvonly here (pasted the remote and local descriptions below) so not sure
why that'd be triggering. I've got a build of chromium going, maybe I can
find why it's setting the ssrc to 1 for PLI messages.

type: offer, sdp: v=0
o=- ef649da4b18f1b49 1431704149951 IN IP4 0.0.0.0
s=-
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:audio
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxxx 10015 typ srflx raddr
10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4231486479 cname:mixed
a=ssrc:4231486479 label:mixedlabelaudio0
a=ssrc:4231486479 msid:mixedmslabel mixedlabelaudio0
a=ssrc:4231486479 mslabel:mixedmslabel
m=video 1 RTP/SAVPF 126 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:1 IN IP4 0.0.0.0
a=mid:video
a=rtpmap:126 H264/90000
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=candidate:1 1 UDP 2130706431 xxxxxxxxx 10015 typ host generation 0
a=candidate:2 1 UDP 1694498815 xxxxxxxxxx 10015 typ srflx raddr
10.205.1.95 rport 10015 generation 0
a=ice-ufrag:n2bb19lc3f4rl
a=ice-pwd:64l6m2dn83ramccr0qa527hfpo
a=fingerprint:sha-1
DE:85:FD:8F:04:B1:5C:F0:9D:78:14:6C:DA:79:F8:DF:88:75:69:E1
a=setup:actpass
a=sendrecv
a=rtcp-mux
a=ssrc:4010208404 cname:mixed
a=ssrc:4010208404 label:mixedlabelvideo0
a=ssrc:4010208404 msid:mixedmslabel mixedlabelvideo0
a=ssrc:4010208404 mslabel:mixedmslabel

type: answer, sdp: v=0
o=- 7359431293216528830 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio video
a=msid-semantic: WMS hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
m=audio 9 RTP/SAVPF 111
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10; useinbandfec=1
a=maxptime:60
a=ssrc:994900336 cname:tdev9PhF2U7XYaOP
a=ssrc:994900336 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
216a8c4b-8447-479c-80d7-607d2e4a6851
a=ssrc:994900336 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:994900336 label:216a8c4b-8447-479c-80d7-607d2e4a6851
m=video 9 RTP/SAVPF 100 116 117
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:ExRMCG1YESlCkS/b
a=ice-pwd:xQHwA0F6Qn1N+BJ6Kcli6qzG
a=fingerprint:sha-256
10:83:06:73:B7:F2:67:FA:3A:10:13:6A:EF:D0:87:6D:11:03:03:77:CD:73:83:51:E7:11:91:38:43:04:A7:39
a=setup:active
a=mid:video
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=sendrecv
a=rtcp-mux
a=rtpmap:100 VP8/90000
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 goog-remb
a=rtpmap:116 red/90000
a=rtpmap:117 ulpfec/90000
a=ssrc:2500397614 cname:tdev9PhF2U7XYaOP
a=ssrc:2500397614 msid:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
ef17cfc1-e63e-4693-a0b4-97c00d8c94ca
a=ssrc:2500397614 mslabel:hrzM4z3QnoEusD57OmPxGySwPn4UyRg3cBsr
a=ssrc:2500397614 label:ef17cfc1-e63e-4693-a0b4-97c00d8c94ca

On Thu, May 14, 2015 at 10:18 PM, Boris Grozev <boris@jitsi.org> wrote:

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

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

Boris

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

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


#12

Thanks John,
Gave that a shot but still see the issue. From what I can tell, even in
working jitsi calls the same behavior (receive stream created before send
stream) seems to happen, so maybe this is an issue but something about the
way the jitsi meet client is written is working around it? Driving a key
frame in some other way, perhaps?

try...
[...]

  type: offer, sdp: v=0

[...]

a=rtcp-fb:100 nack

adding
a=rtcp-fb:100 nack pli
here. Not sure what meet does these days but chrome has been explicitly signaling pli for about a year.

···

Am 15.05.2015 um 15:13 schrieb Brian Baldino: