Receiver SSRC in RR packets

[pablo platt]

Hi,

I have several questions about SSRC when using bundle and multiple SSRCs (plan B/unified plan).

It seems that Chrome ignores RTCP packets from SSRC it doesn't know of unless SSRC=1.

What's the use case of SSRC=1?

How does a client with recvonly stream announce his receiver SSRC to the other peer? With SDP?

When creating an offer with both audio and video in recvonly, Chrome doesn't include any SSRC in the SDP.

If there are multiple SSRCs in the same m line (plan B), do we need a separate receiver SSRC per stream SSRC in the m line or is it enough to have one receiver SSRC?

Does a client need a separate SSRC for audio and video when both are recvonly or can a single SSRC be used for RTCP RR reports? Can a sendrecv audio SSRC be used for reception blocks in recvonly video m section?

Is the SRTCP index (31 bits) incremented separately per SSRC in the same session or does each SSRC have a separate index?
https://tools.ietf.org/html/rfc3711#section-3.4

Thanks

[Peter Boström]

It's set as a default for all receivers under:

"static const int kDefaultRtcpReceiverReportSsrc = 1;" in talk/media/webrtc/webrtcvideoengine2.cc, which is completely arbitrary. In the case where we have a sender we'll guess that the first sender's SSRC is supposed to be the sender SSRC of following receivers.

As far as I'm aware there's no way to express a receiver SSRC in SDP, which is especially confusing in the receive-only case (at least for me). Please let me know if I've missed something.

--

---
You received this message because you are subscribed to the Google Groups "discuss-webrtc" group.
To unsubscribe from this group and stop receiving emails from it, send an email to discuss-webrt...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[pablo platt]

Peter, in my tests, any SSRC which is not 1 is ignored in a recvonly stream.

Any comment on my other questions regarding single/multiple SSRCs for different media (audio/video) and multiple tracks in sendrecv/recvonly?

[Peter Boström]

A recvonly video stream thinks that it is SSRC=1, we picked 1 arbitrarily to have something in the RR field because as far as I'm aware there's no signalling that would tell it to be sending as a specific SSRC, so we just have to guess/pick one.

I might've understood this question incorrectly, but should you be sending receiver reports to a recvonly stream?

I'm not sure whether this is different under bundle or audio though, so I might've incorrectly answered your question.

The rest of the stuff I don't know off the top of my head, no.

[Randell Jesup]

On 5/1/2015 6:45 PM, Peter Boström wrote:
> A recvonly video stream thinks that it is SSRC=1, we picked 1
> arbitrarily to have something in the RR field because as far as I'm
> aware there's no signalling that would tell it to be sending as a
> specific SSRC, so we just have to guess/pick one.

Well an SSRC should be allocated in the same fashion as all other SSRCs
(i.e. randomly), and it needs to deal with collisions even if you're not
sending (i.e. if the other side sends you SSRC=1 data, you need to do
normal SSRC collision behavior). And special rules for receiving SSRC=1
seem very wrong and imply something else is missing/broken.

>
> I might've understood this question incorrectly, but should you be
> sending receiver reports to a recvonly stream?

Even if you're recvonly, there's no reason you should be able to signal
your SSRC value. It just won't be used for sending RTP.

--
Randell Jesup -- rjesup a t mozilla d o t com
Please please please don't email randel...@jesup.org! Way too much spam

[Simon Perreault]

Correct. This is basic RFC3550.

Simon

[Randell Jesup]

On 5/4/2015 12:56 AM, Randell Jesup wrote:
> On 5/1/2015 6:45 PM, Peter Boström wrote:
>
>>
>> I might've understood this question incorrectly, but should you be
>> sending receiver reports to a recvonly stream?
>
> Even if you're recvonly, there's no reason you should be able to
> signal your SSRC value. It just won't be used for sending RTP.

"there's no reason you shouldn't be able to signal your SSRC value".
Ah, typos. It was pretty obvious though

[pablo platt]

I don't think receiver and default SSRCs are well defined:
https://github.com/rtcweb-wg/jsep/issues/79
https://bugzilla.mozilla.org/show_bug.cgi?id=1160280
https://code.google.com/p/webrtc/issues/detail?id=1772

RFC3550 doesn't know about BUNDLE.
RFC3550 says that a translator might forward RTCP packets from multiple clients but Chrome only handles the first SSRC or SSRC=1.

In my initial post I'm asking what SSRC a client should send when both audio and video are recvonly,
will he switch the SSRC when renegotiating to sendrecv and will he switch back to the initial SSRC when renegotiating back to recvonly.
If a client has sendonly audio and recvonly video, will he use his audio SSRC or a receiver SSRC for the video?

The MCUs I tested assume all participants are sendrecv so they don't need to deal with it
but it's important if you want to let users start with recvonly and use the mic/camera later.

[Robert Jongbloed]

One reason for wanting SR/RR on recvonly session is calculating round trip time. Even though no RTP is sent, unless Chrome sends an SR, and gets an RR in response containing a DLSR value, it cannot determine round trip time. And, I think, if it cannot do that, various other sub-systems such as NACK and lip-sync are degraded or disabled. Which is bad.

Or am I missing something?

 

Robert.

[Steve Mcfarlin]

I may be mistaken, but I believe RTT is calculated via the stun pings. Take a look at: https://chromium.googlesource.com/external/webrtc/+/master/webrtc/p2p/base/port.cc. It could be the case this RTT value is used for other purposes, and the RTP engine uses it's own calculation based on SR and RR.

[Steve Mcfarlin]

As to my previous post the RTT calculated in port appears to only be used for comparing connections.

[Brian Baldino]

I've run into this problem (RTCP SSRC of 1, specifically in PLI packets) not with receive-only streams, but when the receive stream was created before the send stream--I haven't gotten all the way to the bottom of why the receive stream is being created first, but I notice that when a send stream is created, it updates the rtcp_receiver_report_ssrc_ member variable in WebRtcVideoChannel2, but doesn't update any receive streams that have previously been created with the default SSRC of 1.  This is with a chromium 44 build.

[Peter Boström]

Thanks, that rings a bell. My guess is that it depends on remote/local offer/answer order and the way these configurations are pushed down.

Bug filed here: https://code.google.com/p/webrtc/issues/detail?id=4678, I'll take a look to make sure the receivers update their local SSRC.

--

[pablo platt]

Could this be the source of video freeze and lip-sync issues?

In a dynamic multistream session, we might send RTCP packets that are ignored because the SSRC doesn't match.

[Brian Baldino]

Thanks Peter,

When I saw the problem, I'd done things in the following order:

1) Create peer connection

2) Add local stream to peer connection

3) Set remote description (remote offer was sendrecv, had multiple ssrcs for audio and video)

4) Set local description (also sendrecv)

[Peter Boström]

Brian, I assume the problem doesn't manifest if you reverse 3 and 4. Is this correct? I've a CL out for review, once that lands I'll try to get it into Canary as soon as possible. Could you help verify then?

[Brian Baldino]

Hey Peter,

If I'm understanding you right, reversing 3 and 4 would involve changing that client from the "answerer" to the "offerer", correct?  The way we've got things set up right now, the bridge is always the offerer so it would involve a bit of work to change that up...I suspect you're correct though.  Will be happy to help verify once your change hits, thanks for the speedy fix!

-brian

[Peter Boström]

Submitted in tip of tree: https://review.webrtc.org/51099004/

Needs to roll into Chromium and get built into a Canary, hopefully you can verify early next week. :)

[Brian Baldino]

Awesome!  I'll keep an eye out for it.  Thanks Peter.

-brian

[Peter Boström]

Rolled into Chromium here: https://chromium.googlesource.com/chromium/src/+/5704b4543d70eb8716bac3a2371474b37b58514b, should be in Canary within a day so try tomorrow please. :)

[Brian Baldino]

Hey Peter,

Tried with canary today and initial testing looks good...I don't see any sender SSRC "1" in wireshark for feedback messages.  Will take a closer look soon (on a build where I have some extra logging) to double check, but looks like you got it.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sG4XzrCFHAfbMLZkPPqy0VU5oLAaPCmwv_541XBqfSwuQ%40mail.gmail.com.

[Peter Boström]

Thanks, merge request for M44 posted here if you're interested in M44 status: https://code.google.com/p/chromium/issues/detail?id=493016

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAAEyqM6F8K%2BLBH%2BQpFNJGgF3kqVQRvAQSPtDqPpyN4zJW3KDrA%40mail.gmail.com.

[pablo platt]

Using SSRC=1 for RR can be used as a temporary workaround until M44 stable will be released?

In the bug report you said that problem with audio-video sync depends on the sender/receiver and offer/answer side.

Can you explain in what case we'll have audio-video sync issue so we can fix it in the meantime?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sHfhuAYKKF5aTy_YuLn7fM8FidiCNHfNVPob6bwaO5r6Q%40mail.gmail.com.

[Peter Boström]

If you set up receiving SSRC=1 I think we'll use SSRC=2 for RR to avoid reporting that we are the remote stream.

Don't think there's a good workaround, sorry for this. I'm hoping we can get the merge in fairly quickly.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANdLC8W5eYHvbPZwvKA65rVtUN4%2Bp9aee75LrwHZ-Q%2BJ7x3YEA%40mail.gmail.com.

[pablo platt]

Peter, what SSRC I should use in RR in the following cases.

Peer1 is sending several audio and video streams.

1. Peer2 has recvonly audio and recvonly video.
Do I need one receiver SSRC for all audio and video streams or a separate receiver SSRC for each SSRC I'm receiving from Peer1?

Do I need to announce the recvonly SSRC in the SDP?

2. Peer2 started publishing audio so it has sendrecv audio and recvonly video.

Peer2 now will use his new audio stream SSRC, right?

Can I use the sender audio SSRC for the video streams as well or do I still need to use the receiver SSRC from 1 for video?

3. Peer2 started publishing video too so it has sendrecv audio and sendrecv video.

Do I need to use the audio SSRC for audio streams and the video SSRC for video streams or can I use one sender SSRC for both?

4. Peer2 stopped publishing audio and video so it has recvonly audio and recvonly video again.

Can I use the SSRC from 2/3 for RR or do I need to use the SSRC from 1 again or maybe generate a new receiver SSRC?

Thanks

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sEpHCoNWoOtObeu%2BDw14vtWmG1FeH2pnm6DmA7-NP2%3DTQ%40mail.gmail.com.

[Peter Boström]

I don't think you can signal it, but we should be generating a random one (I'll look into doing that) and it shouldn't be fixed to SSRC=1. This is a bit outside my comfort zone though, so I can't really answer the rest of your questions very well. :)

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANdLC8W_%3DLtncUVaDD1taD9Gs_VMG2u7tkZYKKzUmPUC9-iTcg%40mail.gmail.com.

[pablo platt]

Thanks Peter.

Who can answer the questions?

What SSRC MCU should use in RR in recvonly, sendonly, and back to recvonly?

What MCUs like jitsi, kurento and janus do?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sGmeeG9WSGB%3D7VfVyfB5H0ufRknTb39qd9moVYP06wTtw%40mail.gmail.com.

[Harald Alvestrand]

I asked on the avt list (list of the AVTCORE group in the IETF, the home of all things RTP), and got an answer back that sending RRs from a random SSRC is the correct approach. If later one needs to start sending, it's OK to reuse that SSRC for sending media (and OK not to, but care needs to be taken because in that case, both SSRCs will "exist" for a little while).

So SSRC=1 is wrong, and will be changed.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANdLC8VN5O7xHqwEzzU2xJTa87ePFDh1piMDFDDj7LnJgi%3D2Xw%40mail.gmail.com.

[pablo platt]

And what if you switch from sending to only receiving?

Can you still use the SSRC you used for sending?

Do you need one SSRC per session / m-section / received SSRC?

Thank you for asking on the list.

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAOqqYVEuTYcP6FXDeAZ02Xjk5ghZ8ULet9pmG7t5m3s4WKRuHQ%40mail.gmail.com.

[Peter Boström]

FYI bug filed here for non-random receiver report SSRCs, I'm working on getting a solution in. https://code.google.com/p/webrtc/issues/detail?id=4740

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CANdLC8UhxU0QnJC4ss9Ou7ihSMwH1seRJ4BF3WOa%2BeYeXnzFvA%40mail.gmail.com.

[pablo platt]

Thank you for submitting the issue.

I still don't understand what SSRC should a receiver use.

When a PeerConnection has recvonly audio and video it should create a separate random SSRC for each SSRC it is receiving?

When the PeerConnection start sending audio or video, should it still use the receiver SSRC from before or switch to the new sending SSRC?

To view this discussion on the web visit https://groups.google.com/d/msgid/discuss-webrtc/CAGFX3sHG%2BC1mpW9MdnF2yE3Sh12mep%3DfXTBwi%2BYSRoot%3Dx6FhA%40mail.gmail.com.