SIP、NAT问题阐述及其解决方案分析(2)
来源:互联网 发布:实体设计软件 编辑:程序博客网 时间:2024/05/16 05:07
3.服务器端解决方案
服务器端解决方案主要包括:B2BUA(Back-to-BackUserAgent)、服务器端RTP中继。
B2BUA是一个接收请求并充当UAS处理请求的逻辑实体,主要是通过两个UA以Back-to-Back的工作模式控制经过它的呼叫。B2BUA与SIP代理服务器不同,B2BUA可以接收呼叫,并能对其进行修改,以其它形式代表发起呼叫的UA向终端目标发起呼叫,并能充当呼叫双方的媒体协商代表或对其进行监控管理。B2BUA可以对经过它的来自于私网的呼叫进行处理完成NAT的穿越。为适应所有类型NAT的环境,B2BUA也需要做媒体流的中介,因此,对于通信双方来说,呼叫控制信令和媒体流在传输过程中均增加了一跳,随着用户的增加,B2BUA将成为系统瓶颈。
服务器端RTP中继的方式相对B2BUA有所改进,它将B2BUA所完成的功能集成到了SIP代理服务器上,由SIP系统中的代理服务器完成信令部分的NAT处理修改,另外增设独立运行的媒体中继服务器来完成媒体流的中继。也就是说,将信令部分的NAT穿越和媒体流部分的NAT穿越分离开来,由不同的功能组件完成。服务器端RTP中继方式相对B2BUA来说,具有更好的可扩展性,目前已经被推认为在对称性NAT环境下的首选解决方案。
三、服务器端RTP中继的工作原理
通过中继RTP媒体流穿越NAT的方法,其工作原理可以简单描述为:SIP代理服务器对私网内用户呼叫的信令进行解析与处理,改写其中的某些头域,使得对应的响应消息以及随后的SIP信令可以顺利地在通信双方间传递;改写SDP中携带的RTP/RTCP地址信息,使得会话中随后的媒体流均经过指定的媒体中继服务器中继,从而完成信令和媒体流的NAT穿越。对于呼叫方和被叫方来说,媒体中继服务器均扮演着对方通信实体的角色。采用中继RTP媒体流穿越NAT方法建立会话的过程如图1所示。
SIP代理服务器需要修改的信息包括:
(1)最外层的Via头域:添加received和rport参数,记录下接收到消息的源地址,使得此消息对应的回应消息能顺利返回。
(2)Contact头域:修改成接收到消息的源地址,使得消息的接受者能将随后的消息发送到正确的地址。
(3)SDP中描述媒体的RTP/RTCP相应的IP地址和端口:对于需要NAT处理的会话邀请请求INVITE,SIP代理服务器请求媒体中继服务器分配地址和端口用以中继媒体流,并且将INVITE和200OK的SDP中的c=和m=参数修改成分配的地址,从而使双方媒体流通过媒体中继服务器中继。
媒体中继服务器的功能是中继转发会话双方的媒体流数据包。当一方的RTP数据包到达媒体中继服务器时,媒体中继服务器记录下发送数据包的源地址;当接收到另一方的数据包时,媒体中继服务器就知道了向何处转发。这是非常必要的,因为SIPUA媒体流只有真正穿过NAT 之后,NAT 地址映射关系才会建立,相应的映射地址才是可知的。
值得注意的是,媒体中继服务器只有在接收到通信两方发送的第一个RTP包之后,才能建立起中继路径,并转发会话双方的RTP媒体包。在对称性NAT的情况下,客户终端必须使用同一个IP地址/port端口来发送和接收RTP数据包,即为对称性RTP。
四、总结
综上所述,SIPNAT问题已有多种解决方案。客户端解决方案,虽然无需对现有NAT做任何改动,但对SIPUA的要求较高,需要支持相应的协议,而且到目前为止还无法解决通信双方均处在对称性NAT的情况;路由边界的各种解决方案,均需要对NAT设备升级,但目前网络实际已部署了大量的不支持相关特性的NAT设备,因而这种方式可行性较差;服务器端解决方案,通过中继RTP数据包来解决所有类型NAT的穿越,缺点就是增加了包的时延和丢包的可能性。具体采用哪种方式解决SIPNAT问题需要从以下角度进行综合考虑:(1)升级要求:哪些网络元素需要做升级;(2)网络业务量:应用这种解决方案后,是否会引入新的网络开销;(3)语音质量:此解决方案是否影响语音质量,增加时延或丢包率;(4)运营商的投资:运营商是否需要做大量投资;(5)企业投资:如果面向企业客户,企业是否需要做大量投资;(6)确定性:此解决方案是否只能在特定环境下生效,是否可以支持各种应用方案,是否可以穿越各种NAT;(7)扩展性:此方案是否支持大规模应用。
(结束)
服务器端解决方案主要包括:B2BUA(Back-to-BackUserAgent)、服务器端RTP中继。
B2BUA是一个接收请求并充当UAS处理请求的逻辑实体,主要是通过两个UA以Back-to-Back的工作模式控制经过它的呼叫。B2BUA与SIP代理服务器不同,B2BUA可以接收呼叫,并能对其进行修改,以其它形式代表发起呼叫的UA向终端目标发起呼叫,并能充当呼叫双方的媒体协商代表或对其进行监控管理。B2BUA可以对经过它的来自于私网的呼叫进行处理完成NAT的穿越。为适应所有类型NAT的环境,B2BUA也需要做媒体流的中介,因此,对于通信双方来说,呼叫控制信令和媒体流在传输过程中均增加了一跳,随着用户的增加,B2BUA将成为系统瓶颈。
服务器端RTP中继的方式相对B2BUA有所改进,它将B2BUA所完成的功能集成到了SIP代理服务器上,由SIP系统中的代理服务器完成信令部分的NAT处理修改,另外增设独立运行的媒体中继服务器来完成媒体流的中继。也就是说,将信令部分的NAT穿越和媒体流部分的NAT穿越分离开来,由不同的功能组件完成。服务器端RTP中继方式相对B2BUA来说,具有更好的可扩展性,目前已经被推认为在对称性NAT环境下的首选解决方案。
三、服务器端RTP中继的工作原理
通过中继RTP媒体流穿越NAT的方法,其工作原理可以简单描述为:SIP代理服务器对私网内用户呼叫的信令进行解析与处理,改写其中的某些头域,使得对应的响应消息以及随后的SIP信令可以顺利地在通信双方间传递;改写SDP中携带的RTP/RTCP地址信息,使得会话中随后的媒体流均经过指定的媒体中继服务器中继,从而完成信令和媒体流的NAT穿越。对于呼叫方和被叫方来说,媒体中继服务器均扮演着对方通信实体的角色。采用中继RTP媒体流穿越NAT方法建立会话的过程如图1所示。
SIP代理服务器需要修改的信息包括:
(1)最外层的Via头域:添加received和rport参数,记录下接收到消息的源地址,使得此消息对应的回应消息能顺利返回。
(2)Contact头域:修改成接收到消息的源地址,使得消息的接受者能将随后的消息发送到正确的地址。
(3)SDP中描述媒体的RTP/RTCP相应的IP地址和端口:对于需要NAT处理的会话邀请请求INVITE,SIP代理服务器请求媒体中继服务器分配地址和端口用以中继媒体流,并且将INVITE和200OK的SDP中的c=和m=参数修改成分配的地址,从而使双方媒体流通过媒体中继服务器中继。
媒体中继服务器的功能是中继转发会话双方的媒体流数据包。当一方的RTP数据包到达媒体中继服务器时,媒体中继服务器记录下发送数据包的源地址;当接收到另一方的数据包时,媒体中继服务器就知道了向何处转发。这是非常必要的,因为SIPUA媒体流只有真正穿过NAT 之后,NAT 地址映射关系才会建立,相应的映射地址才是可知的。
值得注意的是,媒体中继服务器只有在接收到通信两方发送的第一个RTP包之后,才能建立起中继路径,并转发会话双方的RTP媒体包。在对称性NAT的情况下,客户终端必须使用同一个IP地址/port端口来发送和接收RTP数据包,即为对称性RTP。
四、总结
综上所述,SIPNAT问题已有多种解决方案。客户端解决方案,虽然无需对现有NAT做任何改动,但对SIPUA的要求较高,需要支持相应的协议,而且到目前为止还无法解决通信双方均处在对称性NAT的情况;路由边界的各种解决方案,均需要对NAT设备升级,但目前网络实际已部署了大量的不支持相关特性的NAT设备,因而这种方式可行性较差;服务器端解决方案,通过中继RTP数据包来解决所有类型NAT的穿越,缺点就是增加了包的时延和丢包的可能性。具体采用哪种方式解决SIPNAT问题需要从以下角度进行综合考虑:(1)升级要求:哪些网络元素需要做升级;(2)网络业务量:应用这种解决方案后,是否会引入新的网络开销;(3)语音质量:此解决方案是否影响语音质量,增加时延或丢包率;(4)运营商的投资:运营商是否需要做大量投资;(5)企业投资:如果面向企业客户,企业是否需要做大量投资;(6)确定性:此解决方案是否只能在特定环境下生效,是否可以支持各种应用方案,是否可以穿越各种NAT;(7)扩展性:此方案是否支持大规模应用。
(结束)
- SIP、NAT问题阐述及其解决方案分析(2)
- SIP穿越NAT&FireWall解决方案
- SIP穿越NAT&FireWall解决方案
- SIP穿越NAT&FireWall解决方案
- SIP穿越NAT&FireWall解决方案
- SIP网络穿越所有类型 NAT的解决方案(2)
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- NAT的完全分析及其UDP穿透的完全解决方案
- struts2-注册
- 游戏脚本语言
- eclipse中加入tomcat插件后不出现小猫图标
- I'm coming
- AOL收购friendfeed竞争对手socialthing
- SIP、NAT问题阐述及其解决方案分析(2)
- 财富杂志评论Twitter步入盈利轨道,国内饭否、滔滔。。。跟吗
- google ad planner简单体验~~有兴趣可以去玩(老文)
- 写给WEB2.0的站长 不仅仅是泼冷水
- Windows下进程通信的几种方式
- You are what you believe you are
- SNS四处风起,linkedin中国SNS四处学期~~(老文)
- 单点登录JA-SIG研究分析
- 再来幻想下腾讯和操作系统