关于VOIP系统中的NAT/FireWall穿越问题
2008-03-05 15:55
330 查看
VOIP系统中,媒体NAT穿越 有很大不确定因素,一般都是采用STUN、PROXY等模式,而且穿越的步骤是有问题的。主要有一下原因:
1、STUN等穿越技术单单靠判断NAT/FireWall类型来进行穿越太主观,没有考虑到防火墙规则(如果无防火墙的机器先发包到有防火墙的机器,这条链路可能建立不起来)。
2、采用PROXY模式似乎看起来穿越是最好的,但没有考虑到网络的区域性和成本问题。例如:有些地址访问不了222.IP段的服务器。很容易造成穿越无效。
3、现有的VOIP系统都是在通话开始的时候进行媒体数据穿越,选择这个时机进行穿越有可能通话计费已经开始,但媒体确通不起来。
我个人认为,VOIP系统应该采用ICE模式的穿越比较好,先通过VOIP寻址找到被叫地址,先进行多点(可以选择多个PROXY和点对点试探,这样可以可以探测基本的网络情况)试探性的网络连通(发送穿越报文),当连通以后发起呼叫信令,建立呼叫链路进行通话。在我工作中做采用这样的方式进行穿越,穿越的概率大大提升,也使得计费和通话保持一致性。如果这种模式结合P2P网络结构,不仅在成本上大幅降低,也在服务质量上大幅提升。SKYPE就是个例子。
1、STUN等穿越技术单单靠判断NAT/FireWall类型来进行穿越太主观,没有考虑到防火墙规则(如果无防火墙的机器先发包到有防火墙的机器,这条链路可能建立不起来)。
2、采用PROXY模式似乎看起来穿越是最好的,但没有考虑到网络的区域性和成本问题。例如:有些地址访问不了222.IP段的服务器。很容易造成穿越无效。
3、现有的VOIP系统都是在通话开始的时候进行媒体数据穿越,选择这个时机进行穿越有可能通话计费已经开始,但媒体确通不起来。
我个人认为,VOIP系统应该采用ICE模式的穿越比较好,先通过VOIP寻址找到被叫地址,先进行多点(可以选择多个PROXY和点对点试探,这样可以可以探测基本的网络情况)试探性的网络连通(发送穿越报文),当连通以后发起呼叫信令,建立呼叫链路进行通话。在我工作中做采用这样的方式进行穿越,穿越的概率大大提升,也使得计费和通话保持一致性。如果这种模式结合P2P网络结构,不仅在成本上大幅降低,也在服务质量上大幅提升。SKYPE就是个例子。
相关文章推荐
- 关于C# UDP 打洞穿越NAT的问题
- 关于vhd做为第二系统在迁移中遇到的奇怪问题
- 计算机系统的初次学习(持续更新)------关于showbytes的相关问题
- 系统设计时关于性能问题处理的几点心得
- 关于c# 中读取系统内存大小的问题。
- 关于linux系统和tomcat时间不一致的问题
- 关于window10和ubuntu16.04系统时间错乱的问题
- 关于HP 2M阵列卡安装windows系统的问题
- 关于Android6.0系统某些时候无法获取到相关权限的问题
- 关于在vmware中装苹果系统mac lion10.7无法安装vmtools或无法全屏的问题解决
- 关于android系统主题问题
- vc++关于64位PE环境下系统system目录重定向问题
- Dell R720上的系统安装问题的解决办法(关于RAID建立磁盘阵列的技术)
- 关于NAT 转换的问题
- 关于android gallery 在 3.0以上系统出错的问题
- 杂感-关于登录系统中用户不能重复登录的问题
- 关于推荐免试生申请系统中“本人自述”框不能粘贴问题的解决办法
- 关于tomcat连接池爆满导致系统崩溃的问题
- 关于 安装ubuntu16.04 和 win10双系统 后 怎样切换系统的问题
- 关于被安装到sdcard,无法接受到系统启动事件的问题, 修改安装路径