RTSP协议媒体数据发包相关的细节

最近完成了一RTSP代理网关，这是第二次开发做RTSP协议相关的开发工作了，相比11年的简单粗糙的版本，这次在底层TCP/IP通讯和RTSP协议上都有了一些新的积累，这里记录一下。基本的RTSP协议交互流程去读rfc2326就可以了，这里就不赘述了。这里说一些实际用VLC/MPlayer进行测试时，发现的与媒体数据收发相关的细节问题，如下

1，SETUP请求之后，播放器会向在SETUP请求中协商的通讯端口发送NAT穿透UDP消息（UDP作为底层传输协议时），其作用如下

当播放器与服务器之间隔有路由器时，这些消息可以触发这些路由器在NAT表中增加对应SNAT表项，实现打洞，服务端在接受到这些消息时，应该从UDP消息中取出对应NAT映射后的IP/端口作为实际媒体数据发送目的地，如此的话媒体数据包即可沿着刚才这些消息打的洞，逐级的返回到原始的播放器，否则由于NAT代理的原因，在外部是无法直接将媒体数据包发给路由器后面的播放器的。

2,Transport头：本身的作用是用于客户端与服务的协商通讯参数的，其中消息中的destination/source分别只是了本条消息的目的IP和源IP，若服务端在Transport中指定了IP，那么后续NAT穿透包即以此处指定的IP作为目的地。如果Server也是在在路由器后面，通过端口映射的方式对外提供服务，而在SETUP相应中，直接通过getsockname()获取服务接口的IP，那么对应获取到的是服务主机在内网的IP，若将此IP填入到Transport的source中，那么播放器后续会以此IP作为目的IP发送NAT穿透消息，这样自然是错误的。

解决方法是在SETUP响应中Transport头中可以不包含source字段，播放器会参考Content-Base头中的IP，或以RTSP链接的目的IP作为NAT穿透消息发送目的IP

3，Content-Base头：本身是用于指定相对路径的base路径，实际完整的路径是Content-Base指定的url+给定的相对路径组成的，这个在rfc2068-http 14.11节中有描述，但这也会影响播放器发送NAT穿透消息时的目标地址。见上面Transport头中描述的内容

4，采用UDP作为媒体数据发送数据时，最好也简单实现一个类似于TCP慢启动的机制，否则在non-block fd上短时间内快速的发送大量的数据时，会很容易出现EWOULDBLOCK的错误。其中原因请参考TCP慢启动相关的资料。

～～end