This blog is only to remind myself of what I've learned (from others or by myself) and only for knowledge sharing. External sources will be clearly stated in [Reference] of each article. I hope this blog won't infringe any copyrights and that it can be useful for interested blog readers.

2008年2月21日 星期四

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;

沒有留言: