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

你可能感兴趣的:(数据)