What is the sending interval of RTCP Receiver Report? In RFC 3550 I was only able to find computation the RTCP Transmission Interval for the server. But as a client I have no idea about members and senders (or do I?). So I'm a little bit confuse how to calculate the interval or should I send RTCP RR in periods or should I only send RR packet when SR is received?
Per RFC 1885 (granted its older than 3550) states this:
The calculated interval between RTCP packets is required to be greater than a minimum of 5 seconds to avoid having bursts of RTCP packets exceed the allowed bandwidth when the number of participants is small and the traffic isn't smoothed according to the law of large numbers.
In practice with WebRTC, I generally see reports about every second for SR and RR.
RFC 1885 Section 6.2
The RTP and RTCP protocols don't make a distinction between client and server. Both are members within the RTP session and both can send and receive RTP data. Members issue RTCP reports on an interval according to the algorithm in RFC 3550 Section 6.2.
Members issue a compound RTCP report that contains a Receiver Report and optionally a Sender Report if that member has sent any RTP data packets (other report types may be included in the compound report as well). RFC 3550 Section 6.4:
RTP receivers provide reception quality feedback using RTCP report packets which may take one of two forms depending upon whether or not the receiver is also a sender. The only difference between the sender report (SR) and receiver report (RR) forms, besides the packet type code, is that the sender report includes a 20-byte sender information section for use by active senders. The SR is issued if a site has sent any data packets during the interval since issuing the last report or the previous one, otherwise the RR is issued.
Both the client and server are RTP receivers even if your RTP data only flows in one direction. You should be able to observe a sender (your server) creating compound RTCP packets with SR and RR messages. Your client should be sending an RTCP packet with only a RR message
Related
I have been trying to figure out a way to calculate the following:
Bandwidth, Latency, Current Upload, and Download speed.
And have been confused with the values I am getting for the INBOUND-RTP, OUTBOUND-RTP, & REMOTE-INBOUND-RTP.
In my head, I was thinking about inbound-rtp as a collection of stats for all incoming data.
which apparently is wrong, since different stats for that type always stays Zero
The current setup uses chrome as a 2 connecting Clients, and a Media Server, with client instances running on "localhost"
The terminology used on MDN is a bit terse, so here's a rephrasing that I hope is helpful to solve your problem! Block quotes taken from MDN & clarified below. For an even terser description, also see the W3C definitions.
outbound-rtp
An RTCOutboundRtpStreamStats object giving statistics about an outbound RTP stream being sent from the RTCPeerConnection.
This stats report is based on your outgoing data stream to your peers. This is the measurement taken from the perspective of just that oubound RTP stream, which is why information that involves your peers (round trip time, jitter, etc.) is missing, because those can only be measured with an understanding of the peer's processing of your stream.
inbound-rtp
Statistics about an inbound RTP stream that's currently in use by this RTCPeerConnection, in an RTCInboundRtpStreamStats object.
By contrast to the Outbound RTP statistics, this stats report contains data about the inbound data stream you are receiving from your peer(s). Notice that if you do not have any connected peers your call to getStats does not include this report type at all.
remote-inbound-rtp
Contains statistics about the remote endpoint's inbound RTP stream; that stream corresponds to the local endpoint's outbound RTP stream. Using this RTCRemoteInboundRtpStreamStats object, you can learn how the well the remote peer is receiving data.
This stats report provides details about your outbound rtp stream from the perspective of the remote connection. That is to say that this stats report provides an analysis about your outbound-rtp stream from the perspective of the remote server that is handling your stream on the other side.
I'm on the MDN writing team at Mozilla and happened upon this just now. I've taken some of the information from this conversation and applied it back to the article about RTCStatsType. There's more to improve there still, but I wanted to thank you for that insight!
Always feel free to sign up for an MDN account and update any content you see that's inaccurate or incomplete! Or you can file an issue and we'll see what we can do.
We are making calls using JsSIP. We are seeing "Sender's packet count" is very high in Wireshark. Can some one explain what is this Sender's count and why this count is so much big?
It means "total number of RTP data packets transmitted by the sender".
RTCP packets contain statistics about an RTP session.
RTP packets carry audio and video stream data. So, high number of RTP packets is normal in most situations.
How do RTP packets relate to RTCP?
I expected them to share ssrc (synchronization source identifier) with the RTP stream it describes, but it sometimes matches (for Sender Reports) and other times not.
Which RFC or draft should I read for this?
RTCP packets, like RTP, are typically encrypted in WebRTC.
For RTCP Sender Reports one can relate it to RTP steams by SSRC (which is unencrypted). But for Receiver Reports and Generic Feedback the relevant SSRC is in encrypted part, so one should decrypt it first.
I'm a newbie with RRTCC and I really dont understand how RRTCC adjusts incoming media bitrate.
I tried to read Internet Draft of RRTCC but cannot figure it out: https://datatracker.ietf.org/doc/html/draft-alvestrand-rmcat-congestion-03
It calculates the estimated bandwidth based on delay and loss, so what's next?
How it can directly control the sending rate to control congestion?
The RTP receiver doesn't directly control the sending rate. It just sends status information to the RTP sender, which is the only one capable of controlling its own sending rate.
draft-alvestrand-rmcat-congestion has been replaced by draft-ietf-rmcat-gcc so I recommend that you use the later one.
In section 2. System model it explains that the RTP receiver should also act as a RTCP sender, in order to send REMB messages to the RTP sender. These messages should be sent by the RTP receiver as soon as it detects any congestion, and then keep sending it at a rate of once per second even if no congestion is happening. Then the RTP sender uses the information in the received message to decide if the transmission bitrate can be raised or should be immediately lowered.
I am one of the authors of the draft. If you are interested in understanding the design criteria you can also take a look at this paper:
G. Carlucci, L. De Cicco, S. Holmer, and S. Mascolo
Analysis and Design of the Google Congestion Control for Web Real-time Communication (WebRTC)
Proc. ACM Mmsys 2016, Klagenfurt, Austria, May 2016
which is available for download at http://c3lab.poliba.it/images/6/65/Gcc-analysis.pdf.
USB 2.0 specifies 4 types of transfers (in section 5.4 Transfer Types):
Control Transfers
Isochronous Transfers
Interrupt Transfers
Bulk Transfers
Section 5.8 says that Bulk Transfers provide:
Access to the USB on a bandwidth-available basis
Retry of transfers, in the case of occasional delivery failure due to errors on the bus
Guaranteed delivery of data but no guarantee of bandwidth or latency
(Emphasis mine.)
I don't see a similar statement for Control Transfers. Do they also guarantee delivery? If not, how are users expected to handle failures?
Please provide a citation(s) to support your answer.
The USB specification provides robust error detection and recovery for control transfers. The control transfer will either be completed or the USB host will know that it failed, and I think that's what "guaranteed delivery" is supposed to mean. This is important because control transfers are used to set up the device when you plug it into a computer and they are also used for many important purposes by the various USB device classes (e.g. they are used to set the baud rate of a serial port on a USB CDC ACM device).
From section 5.5.5 of the USB 2.0 specification:
The USB provides robust error detection and recovery/retransmission for errors that occur during control transfers. Transmitters and receivers can remain synchronized with regard to where they are in a control transfer and recover with minimum effort. Retransmission of Data and Status packets can be detected by a receiver via data retry indicators in the packet. A transmitter can reliably determine that its corresponding receiver has successfully accepted a transmitted packet by information returned in a handshake to the packet. The protocol allows for distinguishing a retransmitted packet from its original packet except for a control Setup packet. Setup packets may be retransmitted due to a transmission error; however, Setup packets cannot indicate that a packet is an original or a retried transmission.
The only transfer type without guaranteed delivery is isochronous. Also, the start of frame (SOF) packets don't have guaranteed delivery.