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.
Related
When transmitting a message, you have payload + control data.
While control data is there to help a receiver filter the right data, payload is just there as a state in time.
Given that there are uncountable amounts of data being broadcasted from all kinds of devices, how does a receiver know at any time that this data is meant for it and not another device?
Example:
time1: control
time2: payload
or even
time1: control-part1
time2: control-part2
...
timen: payloadn
How does a receiver of control-part2 know about control-part1 and is able to assign payloadn to control-part1?
In addition to this, communication might be encrypted and even if not, it probably looks like this:
time1: control-part1
time1.5: payload x by some random other device
time2: control-part2
...
timen: payloadn
timen+1: control by some random other device
And if it's encrypted how does it know where the next bit of information is.
An application I think of are light-modulations by distance measurement devices. The device basically has to wait for a full sequence to come back. But there is a lot of light diffraction going on, interfering with the receptor. Why does it just work?
If the broadcast message is not encrypted the receiver just see all the broadcast messages. In the case of ARP, when a device want to know the MAC address of other device send a arp request (broadcast) and the target device respond because in the ARP packet there is a field to identify it.
On the other hand, in a case of broadcast encryption there is a system to distribute keys and then the receiver device that have the that can decrypt the message just decrypted and can access the information (Broadcast Encryption).
So, when is done a broadcast and is not encrypted the packet has some information to identify the target host and when the message is encrypted there are first a distribution of keys and then only the devices that have the keys can see the information decrypted.
I hope that this help!
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.
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.
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
I'm currently studying how USB works. I read, that there are transactions, which are build from smaller pieces - packets. I read about all kinds of packets.
I can't understand one thing. As the book says - every transaction consists of 3 packets: token, data and hanshake.
The way I understand my book is depicted in the schema below.
In my opinion:
I think the first transaction should contain only token IN and data packet, but no hanshake packet (handshake for what?).
I think, that response should only contain ACK hanshake packet (that the data is written properly to the device).
Please, help me understand it in a proper way.
Best regards,
Tom.
A transaction is a series of one or more packets.
A typical IN transaction with no data looks like this:
The host sends an IN token.
The device sends a NAK handshake packet, which means it doesn't have any data to send.
A typical IN transaction with data looks like this:
The host sends an IN token.
The device sends a DATA0 or DATA1 packet with data.
The host sends an ACK handshake.
A typical OUT transaction looks like this:
The host sends an OUT token.
The host sends a DATA0 or DATA1 packet with data.
The device sends a NAK or ACK handshake depending on whether it accepted the data.
Note that I am just talking about full-speed (12 Mbps) USB 2.0 devices, and things can get a bit more complicated for the higher-speed devices.
Note that any of these packets could be lost due to noise issues. The USB specification specifically accounts for this, ensuring that packet loss doesn't result in incorrect operation of the device or host.