专利名称：实时通讯数据流穿越网络地址转换设备和防火墙的方法
技术领域：
本发明涉及互联网实时通讯领域，特别是语音与视频数据流穿越网络地址转换设备和防火墙的领域。
背景技术：
防火墙为了网络的安全性，大部份公司的IT部门都会安装防火墙，用来保护网络资源免受外部的恶意破坏，并禁止内部网络访问某些预设的IP地址或端口号。防火墙所完成的功能就是分析进出其设备的数据包的IP地址和目的端口号，根据其设置的策略，决定容许通过或直接丢弃数据包。
网络地址转换网络地址转换(NAT)设备是一个基于Internet标准的，置于内部网络间的边界，其功能是将外网可见的IP地址与内网所用的地址相映射，这样，每一受保护的内网可重用特定范围的IP地址(例如192.168.x.x)，而这些地址是不用于公网的。从外网来的含公网地址信息的数据包先到达NAT，NAT使用预设好的规则(其组元包含源地址、源端口、目的地址、目的端口、协议)来修改数据包，然后再转发给内网接受点。对于流出内网的数据包也须经过这样的转换处理。NAT服务可以达到两个主要目的，一个是提高网络安全，对外部网络隐藏了内部网络细节，另外一个是节省了IP地址，内部网络的IP地址可以采用Internet网络无效的保留地址，如172.16.x.x等.在实际使用过程中，NAT的外网可见的IP地址和端口是按照内部网的发起的数据请求动态分配的，除非是该内部网络已经预先设置好对外提供服务(如WEB服务)，否则的话该内网内的机器应该首先向外部公网上的某一台机发送数据，外部网络机器的数据应该沿同一通路返回，才可能完成内与外网络机器之间的数据通信。
防火墙和NAT对IP语音和视频通讯影响为提供基于IP的语音和视频通讯，系统一般采用SIP/MGCP/H.248等协议作为呼叫控制信令以完成呼叫的建立/维护/拆除功能，其语音一般可以采用G.711，G.729，G.723.1算法，视频则采用H.261/H.263或MPEG2/MPEG4，音频与视频流都采用RTP协议进行传输，用RTCP协议完成RTP流的控制、统计功能。为满足实时传送媒体流的功能，在通用的IP网络上RTP是基于UDP传送，占用一个偶数UDP的端口，RTCP一般占用其下一个奇数端口，即如果某一音频流内容是用UDP的5000端口接收的话，则该机器上的5001 UDP端口是用于该媒体通道的RTCP通道，如图1所示意。一个普通的多媒体呼叫中，音频和视频媒体流一般推荐分开用两个独立的RTP流传送，相应的也有两个RTCP煤体控制通道，如果一个通话过程中有更多个音频(如左右通道分开传送的立体声，环绕声等)和视频流，相应会要求更多的RTP和RTCP通道。
普通的基于IP的语音和视频通讯中，SIP/MGCP/H.248的信令也是基于UDP传输，且一般可以用一个用户数据报协议(UDP)或传输控制协议(TCP)的知名(well-known)端口或通信处理系统双方配置或约定的UDP或TCP端口号上建立信令通道，如SIP的UDP 5060等。但呼叫建立过程中一般可以动态分配RTP和RTCP所占用的UDP端口号，从理论上来说媒体流可以占用除系统保留的小于1024之外所有UDP端口。这样会给IP网络设备会带来如下影响1.对防火墙来说，即使网络管理者打开防火墙上的一个端口来接收呼叫建立信令数据包，例如SIP的UDP 5060端口，但IP语音和视频通讯协议还要求打开许多别的端口接收呼叫控制信息来建立语音和视频通道，这些端口号事先并不知道，是动态分配的，这也就是说网络管理者为了允许语音和视频通讯将不得不容许防火墙上所有的UDP端口上的数据可以通过，防火墙也就失去了存在的意义。
2.对NAT而言，一方面NAT也不得不让通信双方的所有UDP端口号都能发送和接受数据，另外一个显而易见的影响是也会耗费大量的宝贵的公网IP和端口号资源，尤其是在跟公网上的媒体网关媒体交互的时候，这样会显著的提高网络运营成本。
3.对含有防火墙或NAT内外的通信网络中各系统来说还有一个系统开销的问题，以核心网络的媒体网关为例，由于它不得不同时维护众多的RTP/RTCP通道，在系统实现的时候如果用socket编程的话，对应操作系统而言就同时要打开众多文件句柄，而文件操作对所有的操作系统来说都是一项很耗费CPU或系统资源的操作。而对NAT和防火墙设备而言，每个RTP/RTCP流都要有相对应的公网IP地址和端口号与内部IP地址和端口号映射关系表或安全控制表项，显然表项(或称同时会话(concurrent sessions)数目)越多，CPU与内存资源也耗费越大，管理算法也更复杂，产品价格一般以同时会话数(concurrent session)为参考。也就是说由于采用RTP/RTCP传递语音与视频流，对通信网络的增加了很大的成本。
针对随机的RTP端口号对通信媒体流通过防火墙和NAT问题，J.Peterson和J.Rosenberg在2004年七月向IETF提交了一个草案″AMultiplexing Mechanism for the Real-Time Protocol(RTP)″，另外定义了一种RTP端口复用解决方案，但是仍然未能解决RTP与RTCP需要占用不同端口号，且需要应用程序支持复杂的SDP的Offer/answer模型。上述文献在此全文引作参考。
发明内容
为了解决上述问题，且不引入SIP/MGCP/H.248控制信令协议的具体流程与机制的修改，保持通信实体的兼容性，本发明采取了以下措施a.对RTP/RTCP协议进行扩展.对RTP包头进行在RTP协议容许范围内的扩展，增加扩展域名为Identity(标记)，以起到原来SDP协商中的RTP的端口号区别不同呼叫的作用，其目的是将所有RTP及其RTCP流所占用的UDP端口号都统一为某一知名(well-known)或双方约定的某一UDP端口，且RTCP流也承载到其所对应的RTP流内，无论是否有众多呼叫，或同一呼叫有多个语音或视频媒体流，对于通信双方的底层通信和网络中间部分的NAT和防火墙来说，对应同一个方向的媒体流，只有一个IP/UDP通路，以显著减低整个网络系统开销。
b.对信令协商过程中的SDP内容也进行扩展，以区分是否采用a所述方法扩展了RTP/RTCP流，即增加一个扩展域媒体描述段(以”a＝”开头)，即在SDP内容中增加a＝X-rtpyes如果SDP中含有“X-rtp”域，且其值为“yes”的话，则说明SDP中的原来RTP端口号表示扩展后的RTP头中的扩展”Identity”域，否则的话则为标准的SDP流程和标准的RTP/RTCP流程，相应的占用多个UDP端口号资源。
c.与此同时，为了达到媒体流能通过NAT的目的，通信双方都应该在SDP协商结束后，即使本端的RTP属性为“仅接收”(receiveonly)，也立刻向对方发送RTP内容为静音帧的媒体流，以打开NAT从内向外的通路，一旦接收到对方的媒体流，则用其网络传输层地址做为发送到对方的目的地址和端口号，在进入实际通话过程之前或通话过程中若无实际语音传送，都应该以某一时间为周期，向对方发送RTP内容为静音帧的媒体流以保持通过NAT的通路不被NAT因超时而拆除，以这种方法来建立通过NAT的双向通路。
根据本发明，提供了一种按照扩展的RTP/RTCP协议通过网络地址转换设备或防火墙传输数据的方法，包括步骤由通讯双方协商SDP；在通讯双方之间建立通过NAT的由内向外的通道；由接收方接收来自发送方的RTP数据包；根据RTP包中扩展的域名标记判断该RTP包属于哪个呼叫；根据Extension Type字段判断是RTP包还是RTCP包，并进行相应的处理。
图1示出现有技术中RTP包的结构；图2示出现有技术中RTCP包的结构；图3示出根据本发明扩展后的RTP包头的结构；图4示出根据本发明扩展后的RTP与RTCP包结构；图5示出信令与媒体通路。
具体实施例方式
如图1所示，RTP或RTCP用UDP承载时候，其报文包括IP包头，一般20字节的IP包头中有协议域指明其为UDP报文(即协议域值设为十进制17)，UDP包头内含有“源端口号，目标端口号，长度，校验和”四项，其中目标端口号就是接受端系统用来区分不同应用程序或呼叫接收的RTP流，如前所述，不同的煤体RTP流需要占用不同的偶数端口号，其对应的RTCP流也占用相应的加一的奇数端口号。
对应一个RTP媒体流，其相应的RTCP控制信息报文分为“发送机报告(SR)，接收机报告(RR)，源描述项(SDES)，会话终止(BYE)，应用(APP)”等五种RTCP报文，这五种RTCP报文都含有对应的定长的包头，在实际传送中应该根据需要，将这五种RTCP报文中至少两种RTCP报文组合成一个复合RTCP包(具体规则请参见RTCP协议)，传输层(UDP)将复合包作为一个包传输，并不关心具体组包模式。
根据本发明的一个实施例，对RTP包头进行了在RTP协议容许范围内的扩展，如图3所示，增加扩展域名为“Identity(标记)”，长度为四个字节。其中，灰色部分为标准的RTP头，白色部分为本发明引入的扩展部分。根据RTP协议规定，一般情况下比特X为“0”，即无RTP包头扩展，若为“1”则表明该RTP报文含有扩展部分。将Extension type设为“1”，表明为RTP流，将Extension type设为“2”，则表明该包内容是RTCP.“Length”域置为“1”，表明该RTP扩展头长度为“1”个32比特单位，其后是扩展的一个四字节的“Identity”域。
在实际应用中，采用该引入的“Identity(标记)”域来标志或区分某一RTP媒体流，起到原来SIP/MGCP/Megaco中SDP描述RTP流中”IP地址+UDP端口号”两元组中的原来UDP端口号的作用。这样进行SDP协商的时候所有信令流程不用做任何更改，但是通信的双方应该约定用某一知名端口，或可以灵活配置。在本发明的该实施例中，为统一起见，约定用UDP 5061(目前通用的SIP协议信令的知名端口为UDP 5060)端口做为统一的RTP/RTCP传输通道。考虑到大型通信系统中一般信令处理主机和媒体处理部分的IP地址不相同，此时也可以用不同的IP地址，但相同的UDP端口号(如共用SIP的UDP5060端口)来区分信令与媒体流。在一般通信系统中，RTP与其对应RTCP流是分别占用相邻的两个UDP端口，采用本方法后，RTCP可以与RTP共用一个UDP端口，而通过本扩展“Extension Type”域的具体值来区分是RTP包还是RTCP包。如图2所示，标准的RTCP的复合包并无另外的RTCP包头，但如用本方法与RTP包复用同一个UDP端口后，RTCP包将会多出无用的原来RTP包头，共计十六个字节。但是由于RTCP包在整个媒体流内所占用的比例一班不大(一般小于2％)，且与一个复合RTCP包内容一般会达到两三百字节长度，考虑到给整个通信网络系统带来的好处，传送这十六个无用的字节的系统开销是可以接受的。另外，在普通原有通信网络中，RTCP流占用比其控制的RTP流大一的UDP奇数端口号，所以SDP协商的时候只需要协商RTP的UDP端口号，而并不需要指明其相应的RTCP端口号。在根据本发明的方法扩展后，因已经有“Extension type”字段来区分RTP与RTCP，为减低系统计算负担，媒体流的RTP与其对应的RTCP流在扩展后的RTP包头中的“Identity”字段值设为相同。这样实际的RTP和RTCP包结构如图4所示。
通信信令与媒体通路如图5所示(以通过NAT为例)，为了表示清晰，图上的同一个呼叫的双向语音流，分别占用了两个UDP通路，但是实际系统实现中，可以合并这两个UDP通路，即收发共用同一个UDP端口号。信令处理流程仍然与原来的SIP/MGCP/Megaco协议定义的没区别，协商SDP后，双方都将先发送实际内容为静音帧的RTP/RTCP媒体流发向对方的UDP 5061端口，以建立通过NAT的由内向外的通路，在接收到对方RTP包后，用其网络传输层地址做为发送到对方的目的地址和端口号。在扩展后的RTP包头中含有SDP协商内容的原来UDP号码作为“Identity”，媒体网关或IP终端收到该RTP包后，先根据“Identity”判断其属于哪个呼叫，再根据“Extension Type”字段判断是RTP或RTCP包，以进行相应的处理。由于“Identity”和“Extension Type”在整个UDP包中位置(偏移量)是固定的，所以这两次判断所引入的系统开销是可以接受的，对大型通信系统也无性能影响。为了兼容标准的RTP/RTCP格式与流程终端与系统，通信双方首先检查SDP协商中有无“X-rtp”扩展域及其值是否为“yes”，如果是的话，则按照前述办法处理，如果没有则说明对方是采用标准的RTP/RTCP流程，则此时应该打开SDP内协商的RTP/RTCP所需要的UDP端口号，采用标准的RTP/RTCP发送与接收流程。
根据本发明的方法扩展RTP包头及SDP报文，并规定通信双方必须向对方先发送媒体流，从而建立通过NAT的通路，对相应的处理流程改变之后，多媒体通信仍可成功进行，并带来如下优点1.NAT/FW只需要打开UDP 5061或其它某一UDP端口就可以支持媒体流的穿越，而将其它端口设置为禁止通过，提高网络安全，这对希望应用VoIP却同时有IT安全管制的客户来说尤其有吸引力。
2.节省了NAT上的宝贵的公网IP地址和端口号资源，至少是省去了RTCP流所需要的独占公网IP和端口号资源，如果通信的双方是中继媒体网关，更是可以根据其媒体处理的密度不同而显著降低公网IP和端口号资源占用。
减低了通信网络上各节点系统开销，降低系统成本。
从上面通信流程与图示可以看出，采用本发明的方法要求通信的双方中至少一方是处于NAT外面(即有公网IP地址)，而对通信双方都处在不同的NAT所辖的内部网络时候媒体流不能正确穿越，解决问题的方法可以是在公网上放置一个媒体桥接服务器，为双方提供媒体流的中转服务。
以上讨论中没有涉及H.323协议体系的通信系统，是因为H.323采用TCP传输信令，采用H.245进行媒体通道协商，以完成类似SDP协商的过程，所以为了在H.323体系中应用本方法，需要在H.245协商流程中SDP类似扩展，而RTP/RTCP则可以直接采用本方法扩展，从而解决H.323通信系统穿越NAT/防火墙问题。
权利要求
1.一种按照扩展的RTP/RTCP协议通过网络地址转换设备NAT传输数据的方法，其中所述扩展的RTP/RTCP协议中，对RTP包头进行了扩展，使其包含扩展域名标记，且包括步骤a.由通讯双方协商SDP；b.在通讯双方之间建立通过NAT由内向外的通道；c.由接收方接收来自发送方的RTP数据包；d.由接收方根据RTP包中扩展的域名标记判断该RTP包属于哪个呼叫；和e.由接收方根据Extension Type字段判断接收到的是RTP包还是RTCP包，并根据判断结果进行相应的处理。
2.如权利要求1所述的方法，其中对信号传输过程中的SDP内容也进行了扩展，增加一个扩展域媒体描述字段，并且所述方法进一步包括步骤根据所述扩展域描述字段判断接收到的RTP数据包为标准RTP包还是扩展RTP包；如果是扩展RTP包，则继续进行步骤a-e的处理；如果是标准RTP包，则采用标准的RTP/RTCP发送和接收流程。
3.如图1或2所述的方法，其中步骤b通过以下步骤实现由通讯双方向对方UDP端口发送实际内容为静音帧的RTP/RTCP媒体流。
4.如权利要求1或2所述的方法，其中传输数据的通讯系统的体系为选自下面组中任意一种协议体系SIP，MGCP，H.323。
5.如权利要求1或2所述的方法，其中通讯双方中至少一方处于NAT外面。
6.如权利要求1或2所述的方法，其中通讯双方中都处于NAT所辖的内部网，并且在公网上提供一个媒体桥接服务器，为双方提供媒体流的中转服务。
7.如权利要求1或2所述的方法，其中所述数据为语音和视频数据。
8.一种按照扩展的RTP/RTCP协议通过防火墙传输数据的方法，其中所述扩展的RTP/RTCP协议中，对RTP包头进行了扩展，使其包含扩展域名标记，且包括步骤a.由通讯双方协商SDP；b.在通讯双方之间建立通过防火墙由内向外的通道；c.由接收方接收来自发送方的RTP数据包；d.由接收方根据RTP包中扩展的域名标记判断该RTP包属于哪个呼叫；和e.由接收方根据Extension Type字段判断接收到的是RTP包还是RTCP包，并根据判断结果进行相应的处理。
9.如权利要求8所述的方法，其中对信号传输过程中的SDP内容也进行了扩展，增加一个扩展域媒体描述字段，并且所述方法进一步包括步骤根据所述扩展域描述字段判断接收到的RTP数据包为标准RTP包还是扩展RTP包；如果是扩展RTP包，则继续进行步骤a-e的处理；如果是标准RTP包，则采用标准的RTP/RTCP发送和接收流程。
10.如图8或9所述的方法，其中步骤b通过以下步骤实现由通讯双方向对方UDP端口发送实际内容为静音帧的RTP/RTCP媒体流。
11.如权利要求8或9所述的方法，其中传输数据的通讯系统的体系为选自下面组中任意一种协议体系SIP，MGCP，H.323。
12.如权利要求8或9所述的方法，其中通讯双方中至少一方处于防火墙外面。
13.如权利要求8或9所述的方法，其中通讯双方中都处于防火墙所辖的内部网，并且在公网上提供一个媒体桥接服务器，为双方提供媒体流的中转服务。
14.如权利要求8或9所述的方法，其中所述数据为语音和视频数据。
全文摘要
公开了一种按照扩展的RTP/RTCP协议通过网络地址转换设备NAT传输数据的方法，其中所述扩展的RTP/RTCP协议中，对RTP包头进行了扩展，使其包含扩展域名标记，且包括步骤由通讯双方协商SDP；在通讯双方之间建立通过NAT由内向外的通道；由接收方接收来自发送方的RTP数据包；由接收方根据RTP包中扩展的域名标记判断该RTP包属于哪个呼叫；和由接收方根据Extension Type字段判断接收到的是RTP包还是RTCP包，并根据判断结果进行相应的处理。
文档编号H04L12/56GK1783877SQ20041009809
公开日2006年6月7日 申请日期2004年11月30日 优先权日2004年11月30日
发明者李建成, 谢林, 陈健 申请人:Ut斯达康通讯有限公司