翻译自：https://www.kurento.org/blog/rtp-i-intro-rtp-and-sdp 

The Real-time Transport Protocol -- RTP

FFmpeg and GStreamer 是两个工具可操作rtp，也提供可编程。

rtp已经成为事实的标准用于webRTC或者其他工具传输音视频。原理是一个rtp会话包含一堆参与者，即peer。发送peer吧媒体拆开成chunks，即rtp packets，用udp发送给接收者peer。反之，接收者重新组合。

rtp packet包括固定长的头，可为空的源列表，负载数据payload。

 

(Bitmap)
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P|X|  CC   |M|     PT      |       sequence number         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           timestamp                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           synchronization source (SSRC) identifier            |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|            contributing source (CSRC) identifiers             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          payload  ...                         |
|                               +-------------------------------+
|                               | RTP padding   | RTP pad count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

rtp几十年前制定，现在很多属性已经不用。挑重点：

PT (Payload Type)

除了以前标准定义的，现在一般用自己动态定义的，范围为 [96-127]。比如chrome 96是video VP8， pt 98是vp9，102是h264.

sequence number

随机数开头，然后递增，来确定包的顺序。

timestamp

 

也是随机数开头，按时钟类型（clock rate）增长，通过相对增量确定改播放的时刻。

SSRC (Synchronization Source)

随机串，每个视频音频在rtp会话中唯一。通过这个识别自己属于哪个媒体。

RTP Control Protocol -- RTCP

由于缺失了tcp的保障，rtp的udp传输需要rtcp去控制。发送方提供RTP和RTCP Sender Reports，接收方接收。rtcp发送比rtp少，基本1秒；而rtp更快。

• SSRCs used by each media.
• CNAME, an identifier that can be used to group several medias together.
• Different timestamps, packet counts, and jitter estimations, from senders and receivers. These statistics can then be used by each peer to detect bad conditions such as packet loss.

另外还提供 RTCP Feedback (RTCP-FB)

• Google REMB is part of an algorithm that aims to adapt the sender video bitrate in order to avoid issues caused by network congestion. See Kurento | Congestion Control for a quick summary on this topic.
• NACK is used by the receiver of a stream to inform the sender about packet loss. Upon receiving an RTCP NACK packet, the sender knows that it should re-send some of the RTP packets that were already sent before.
• NACK PLI (Picture Loss Indication), a way that the receiver has to tell the sender about the loss of some part of video data. Upon receiving this message, the sender should assume that the receiver will not be able to decode further intermediate frames, and a new refresh frame should be sent instead. More information in RFC 4585.
• CCM FIR (Full Intra Request), another method that the receiver has to let the sender know when a new full video frame is needed. FIR is very similar to PLI, but it's a lot more specific in requesting a full frame (also known as keyframe). More information in RFC 5104.

这些RTP的功能有没有实现，需要看下面的描述协议sdp。

Session Description Protocol -- SDP

在会话前需要确定网络相关和媒体相关信息。sdp是文本型松散格式结构。偏向介绍WebRTC的SDP Offer/Answer 模型。

sdp对于发送方描述了想要什么类型接收者；接收者回应了想让发送者以什么格式发送。

a=行用了添加属性。