本身动手写RTP服务器—关于RTP协议

本文会带领着你一步步动手实现一个简单的RTP传输服务器，旨在了解RTP流媒体传输协议以及一些关于多媒体编解码的知识。

关于RTP协议的必备知识

要动手实现一个协议，固然首先须要阅读该协议的文档。RTP协议的文档，有rfc188九、rfc1890、rfc3550，其中rfc3550是如今的 版本，另外两个是过时版。这个协议能够在ietf的官网找到：http://tools.ietf.org/html/rfc3550

RTP packet

RTP是基于UDP协议的，RTP服务器会经过UDP协议，一般每次会发送一个RTP packet。客户端经过解析RTP packet，读取其中的数据而后进行播放了。

RTP packet的结构以下：

1. RTP Header：RTP 包的头部
   
2. contributing sources：个数为0-n个，因此能够为空。具体定义参考rfc3550
3. RTP payload：即RTP要传输的数据
   

RTP Header

这是RTP流的头部，在网上搜索RTP格式，就会搜到不少文章介绍这个头部的定义。咱们这里参考rfc3550的定义，在5.1节(http://tools.ietf.org/html/rfc3550#section-5.1)。

    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             |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

每行是32 bits，由此能够直观看到每一个表示部分所占的位数。简单介绍一下：

V(version)：2 bits，RTP的版本，这里统一为2

P(padding)：1 bit，若是置1，在packet的末尾被填充，填充有时是方便一些针对固定长度的算法的封装

X(extension)：1 bit，若是置1，在RTP Header会跟着一个header extension

CC(CSRC count): 4 bits，表示头部后contributing sources的个数

M(marker): 1 bit，具体这位的定义会在一个profile里

PT(playload type): 7 bits，表示所传输的多媒体的类型，对应的编号在另外一份文档rfc3551中有列出(http://tools.ietf.org/html/rfc3551)

sequence number: 16 bits，每一个RTP packet的sequence number会自动加一，以便接收端检测丢包状况

timestamp: 32 bits，时间戳

SSRC: 32 bits，同步源的id，没两个同步源的id不能相同

CSRC: 上文说到，个数由CC指定，范围是0-15

 

以上的一些概念是一些要实现RTP服务器所必备的知识。介绍的很是简略，详细的定义仍是要参考rfc3550原文。

动手实践

咱们既然已经知道了RTP packet的结构，那么咱们之前用到的RTP流是否也是这样的结构呢？如何验证呢？接下来，咱们就一步步验证RTP流的结构。

咱们知道RTP是基于UDP协议的，那么咱们就先作一个简单的UDP接受端，看看咱们能够从RTP服务器接受到什么信息。要实现这个接受端，你须要 有必定的网络编程经验，至于具体到操做系统、编程环境、开发语言等都不限制。为了简单，我这里用python给出一个小小的例子程序。

import socket

# Build a socket to receive data from RTP server.
# Here we use SOCK_DGRAM, because RTP is on UDP.
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
sock.bind(("localhost", 6666))

for i in range(5):
        # We just get 16 bytes to analyze the RTP Header.
        buf = sock.recv(16)

        # Output the result in octal.
        for c in buf:
                print "%x" % ord(c),
        print

sock.close()

这就是接受程序啦，很是短小，并且有简单注释，这里就不解释了。

接受端已经作好了，那么去哪里找RTP服务器做发送端呢？你能够用一些搭建流媒体服务器的工具，我这里选用的是强大的VLC。关于VLC搭建流媒体服务器的方法，请参考我前面的文章基于移动平台的多媒体框架——用VLC搭建简单的流媒体服务器。这里须要注意几个配置的地方，一是选择Destination的时候要选择RTP而不要选择RTSP，而后地址能够填写本机ip地址或直接写localhost，端口号填写的要和接受端一致，这里是6666。配置好以后的string应该相似于：

:sout=#rtp{dst=localhost,port=6666,mux=ts} :no-sout-rtp-sap :no-sout-standard-sap :ttl=1

服务端配置完成以后，开始Stream。这时打开接受端，就会接受到一些数据，我接收到的数据开头是：

80 a1 20 43 8c cf 76 3c 93 59 d 74 47 0 44 10
80 a1 20 44 8c cf 79 4b 93 59 d 74 47 40 42 36
80 a1 20 45 8c cf 7d 36 93 59 d 74 47 0 44 1a
80 a1 20 46 8c cf 81 21 93 59 d 74 47 40 45 1a
80 a1 20 47 8c cf 85 c 93 59 d 74 47 0 45 1b
这是十六进制的表示。咱们依照上面的Header的格式对其进行解读：
第一个byte 80 表示：

V(version)=2

P(padding)=0

X(extension)=0

CC(CSRC count)=0

第二个byte a1 表示：

M(marker)=1

PT(playload type)=33(对照rfc3551能够发现，33表示MP2T AV，正是咱们用VLC Stream的格式类型)

后面的2bytes的sequence number咱们能够直观的看出是在加一，4bytes的timestamp也是在不断递增的。再以后的93 59 d 74就是SSRC id了，因为CC为0，因此没有CCRC。再以后的几位都是RTP所要传输的数据了。

总结

对RTP协议的熟悉是实现它的基础。这里我只是作一个简单的介绍，须要详细了解，读官方的文档是必不可少的步骤。

经过写一个小程序打印出RTP流中具体的数据，并无对实现RTP服务器有直接帮助。可是可让你对协议自己以及编程环境更加熟悉，也方便了之后实现过程当中进行调试。不论你在什么环境用什么语言实现，都强烈建议写一个这样的小程序。