UDP, RTP, RTCP

[UDP]

Reference

UDP (Network Sorcery, Inc)

MAC header

IP header

UDP header

Data :::

UDP header:

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Source Port																Destination Port
Length																Checksum
Data :::

!!NOTES:

1) The checksum algorithm is the same as that of IP header.

2) Length = (UDP_header_length + UDP_payload_length)

[RTP header]

Reference

RTP (Network Sorcery, Inc)

MAC header

IP header

UDP header

RTP message

RTP header, version 2:

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Ver		P	X	CC				M	PT							Sequence Number
Timestamp
SSRC
CSRC [0..15] :::

!!NOTES:

1)

V(Version):
The current version of RTP is 2.

P(Padding):
is used to indicate that the payload has been padded out past
its natural length.
M:
is used to mark events of interest within a media stream;
its precise meaning is defined by the RTP profile and
media type in use.
PT(payload type):
identifies the media transported by an RTP packet
Sequence Number:
identify packets, and to provide an indication to the receiver
if packets are being lost or delivered out of order.
Timestamp:
denotes the sampling instant for the first octet of
media data in the packet and it is used to schedule
playout of the media data.
Synchronization Source (SSRC):
identifies participants within an RTP session.
Contributing Source(CSRC):
identifies participants who have contributed to
an RTP packet but were not responsible for its
timing and synchronization.

2) if P is set to 1, the last byte of the RTP payload shows the
number of padding bytes following RTP payload.

3) Timestamp wrap-around should be handled by all applications. A better design is to calculate timestamp using 32-bit modulo arithmetic. A 64-bit arithmetic is not recommended due to inefficiency.

4) Sequence number may be wrapped around, too. Using 32-bit arithmetic as extended_sequence_number is recommended.

[RTCP header]

Reference

RTCP (Network Sorcery, Inc)

MAC header

IP header

UDP header

RTCP header

Data :::

RTCP header:

00	01	02	03	04	05	06	07	08	09	10	11	12	13	14	15	16	17	18	19	20	21	22	23	24	25	26	27	28	29	30	31
Version		P	Count					Type								Length
Data :::

!!NOTES:

1) If Type == 200, it means RTCP conveys Sender Report, which is used for a/v synchronization.

The format of Sender Report is

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|Count | Type (200) | Length
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reporter SSRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NTP timestamp (high)

| NTP timestamp (low)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RTP timestamp
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's packet count
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's octet count
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver report block(s)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

psuedo code:

int64 ntp_high = ntohl(*((unsigned int*)(pRTCPBuffer+8)) );
int64 ntp_low = ntohl(*((unsigned int*)(pRTCPBuffer+12)) );
int64 timestamp = ntohl(*((unsigned int*)(pRTCPBuffer+16)) );

int64 rtcp_ntp_in_microsecond_base = ntp_high*1000000 + ((ntp_low*1000000) >> 32);
int64 rtcp_timestamp_base = timestamp;

absolute_PTSinMicroSec =
rtcp_ntp_in_microsecond_base +
(RTP_timeStamp - rtcp_timestamp_base)*1000000 / clock_rate;