您当前的位置是:  首页 > 新闻 > 国内 >
 首页 > 新闻 > 国内 >

SIP系列讲座-NAT解决方法探讨-STUN-TURN-ICE

2017-11-17 09:13:37   作者: james.zhu   来源:Asterisk微信公众号   评论:0  点击:


  前面的讲座中我们讨论了关于NAT的基本概念,NAT的类型和NAT在语音解决方案中的问题。今天,我们探讨一下几个NAT的解决方案和各自的问题,包括:NAT 方案的选择,STUN, TUNE, ICE。在接下来的章节中继续介绍 ALG, PNnP, MediaProxy,Symmetric RTP和SBC。
  NAT解决方案的选择
  目前,根据对NAT支持的不同,处理机制的不同,业内把解决NAT的方法一般有分为以下几种:
  这些方案都有其各自的特点。根据国外有关市场研究人员的报告指出,不同企业类型的要求不同,部署成本,安全因素,维护成本等因素的影响,所以它们对解决方案的要求也可能有所不同,以下是调查结果发布状态:
  • 一般家庭用户选择简单的NAT解决方案,例如UPnp,STUN,TURN, ICE
  • 小型企业用户大部分用户可能选择STUN,TURN, ICE 或者SBC,也可能选择UPnP的方案。
  • 一般中型企业则选择SBC,STUN, TURN和企业级的SBC加防火墙的方案。
  • 比较大的企业则会选择防火墙,SBC的解决方案。
  当然,选择是有成本的。对于VOIP的解决方案,安全是一个公司的非常重要的考虑因素,用户也要根据不同的安全要求对解决方案进行比较全面的分析,以下图例数据表示各种解决方案对安全的考虑和其可控性的考虑。
  从以上数据我们可以看到,如果用户需要更加安全的部署方式,需要对其访问有非常大的灵活性和可靠性,最好的方式还是选择SBC。
  关于STUN和TURN的讨论
  在实际生产环境中,我们客户通常使用的设备所支持的STUN和TURN都可能有所不同,所以这样就会导致一个解决方案兼容性的问题。例如,可能有的物理话机支持STUN和TURN,但是不支持ICE,有的软电话可能支持的旧版本的STUN,不支持新标准的STUN。
  下面,我们介绍一下关于STUN的流程机制。这里我们要注意,一般我们举例时使用的是RFC5389来解释的,相对比较旧的STUN版本是RFC3489(classic STUN)。在RFC5389的规定中,STUN定义为轻量级的工具,它不是一个完整的NAT穿透解决方案(RFC3489定义为完整的解决方案),它仅是一个解决穿透能力的工具。另外,RFC3489的规定有几个方面的不足,很难满足真正的NAT解决方案。根据RFC5389的解释,RFC3489的不足主要表现在:
  在实际部署环境中,IP和端口有时可以作为Peer来进行通信,有时则不能。Classic STUN没有提供准确的方法来处理这些问题。
  Classic STUN的算法对多层NAT可能发生错误。
  Classic STUN存在安全漏洞,可能有时骇客会利用某些端口重新映射时进行地址或者端口串改。
  目前,根据RFC5389对STUN所执行的功能包括:
  • 用于ICE连接支持(MMUSIC-ICE)
  • 用于客户端的初始化连接(SIP-OUTBOUND)
  • NAT行为发现(BEHAVE-TURN)。
  STUN 简单来说,内网SIP终端通过STUN对STUN发出请求,STUN回复一个响应,STUN服务器告诉使用指定的外网端口和IP地址。STUN使用UDP,默认端口是3478。它在响应的消息中包含了MAPPED-ADDRESS,RESPONSE-ORIGIN,OTHER-ADDRESS和XOR-MAPPED-ADDRESS这四个参数。通常来说,为了支持NAT的映射和过滤行为机制,STUN服务器必须支持两个公网IP地址和两个不同的端口,分别称之为主信息地址和可选消息地址。让我们看看具体的实现方式。
  具体的流程包括:第一步客户端A 通过设置的STUN地址查询STUN外网地址和端口。第二步,客户端A对客户端B发生信令消息,通知客户端B的外网地址和端口,可以对其发送媒体。客户端B然后对NAT路由器发送媒体,NAT路由器然后转发到客户端 A。
  以下图例是一个简单的STUN流程图(缺少对Symmetric 的支持,需要TURN支持):
  在上面的流程中,NAT是如何被检测的?RFC 5780 规定了三个阶段的NAT检测方式:
  NAT检测的具体步骤:
  研究人员Baruch 更加详细地描述了这个test的流程,用户可以查阅此研究人员的文档做进一步了解。具体Test的逻辑顺序请读者参考 RFC5780的4.5 部分。如果读者需要了解更多的相关定义,请参RFC 5780 相关协议:
  现在让我们看看在SIP中NAT请求和响应的示例。
  STUN 返回的IP和port number, SIP然后在SIP header 使用这个新的地址。
  大家需要注意以下SIP头中的rport 1024, 当在NAT后的终端收到消息时,这个rport 端口会覆盖原来的端口49300端口。这里,实际上,rport是做路由使用的。关于rport 端口的修改问题,读者查阅RFC3581 的Server Behavior中rport的修改规则。用户必须注意,在有一些网络环境中,系统管理机制可能对收到的消息和返回的消息地址端口非常敏感,如果是这样的话,RFC3581 标准建议开启TLS服务。另外,用户也应该注意到,如果修改rport了,这里可能涉及到了一个安全的问题,攻击者在路由路径中插入了一个中转服务器的话,可能导致安全问题。
  尽管STUN可以解决很多类型的NAT问题,但是仍然有很多局限性:
  • STUN不支持Symmetric NAT类型,因为每一个新创建的IP:port 的会话映射可能地址以前STUN检测到的数据失效。
  • 如果防火墙设置了对UDP丢弃数据包的参数,也会导致STUN失败。
  • 因为UDP不是一个长连接的方式,防火墙可能关闭一些存活动端口,这样可能导致会话失败。
  • 终端客户的网络环境可能导致STUN失败,因为有的终端可以抵达服务商的服务器地址,有的SIP终端可能可能不会抵达STUN服务器地址(例如,很多国内用户使用国外的STUN地址),这样的话,SIP之间可能存在多层的NAT问题。整个网络环境会变得更加复杂。
  关于TURN的讨论
  既然STUN存在那么多的问题,但是如何解决这些问题是技术研究人员必须面对的困难。俗话说,办法总比问题多。TURN是一个补充STUN不足的好办法。TURN的英文全称如下:
  • Traversal Using Relays around NAT (TURN)
  • Relay Extensions to Session Traversal Utilities for NAT (STUN)
  从英文全称就可以看出,它仅是STUN的一种拓展,使用了中继穿透NAT的方式。根据RFC5766的描述,TURN的设计目的是ICE的一部分,但是可以独立使用。
  在很多应用场景中,位于NAT后面的终端可能不能与外网的终端进行点对点的通信,如果需要双方通信的话,只能借助于一个外网的中转服务点来实现互通。TURN的作用就是帮助双方绕过阻挡的网络点,使用中继的方式,支持终端控制中继操作从而实现双方的数据交换,也可以支持终端对多点终端互通。
  TURN和STUN相比,因为TURN的它本身的拓展,所以它也支持更多的功能,以下是对于TURN的一个总结:
  除了本身工作方式类似以为,TURN可以支持SIP消息和媒体的转发,工作角色可以是一个代理的形式。
  TURN可以支持UDP和TCP,TCP可以支持长连接,从而保证防火墙对会话的连接不会断开。但是,这里要注意,根据RFC5766的规定,如果是TRUN server 到Peer则都使用UDP。大概20%以上的会话需要使用TURN。
  TURN可以支持Symmetric NAT, 但是STUN则不能支持。我们前面已经提及。
  TURN必须支持公网IP地址。
  TURN的本身要求服务提供商的TURN服务器部署成本相对比较高。因为,TURN需要考虑大量会话,大量转发数据,同时还要获取Relays 路径中的交换数据。
  以上我们讨论的是关于整个TURN的使用场景的各种因素,但是还有很多细节性的问题可能在实际应用中也可能出现,例如,以下图例是一个开发人员在测试WebRTC中关于使用P2P和SFU时的数据,使用P2P或SFU测试的结果是完全不同的。以下是其中一个数据。
  TURN服务器的表现因为地理原因,配置原因或者其他的原因造成的对语音时延也完全不同,以下示例来自于 Dag-Inge Aas, 在开发WebRTC时对于TURN服务器时延的实验数据,各个服务器的带宽不同,处理能力不同导致的各种不同的结果。
  如果用户选择TURN的话,可以参考Twillio的标准来做出决定:是否全球部署,是否靠近用户,是否支持拓展,是否优化时延。
  关于ICE讨论
  前面我们详细讨论了STUN和TURN的使用场景和各种影响。读者可能会看到,以上两种方式仍然存在一些问题。ICE的出现改善了两种NAT解决方法的很多问题。ICE英文全名是Interactive Connectivity Establishment。RFC5245(更新的RFC6336)对ICE做了规定。一般简单的定义是:ICE=STUN+TURN+协商机制+协商路径。以下图例中表示了ICE的架构。
  以下是一个Candidate的消息架构体,关于结构体中每个参数的含义,请参阅RFC3245的第三部分(Terminology)。
  ICE执行的几个步骤:
  1. 发现收集申请终端信息。收集到终端可通信的地址,终端申请者的类型(host, Reflexive和Relay candidate)。
  2. 根据优先级对candidate 进行处理,大部分情况下,首先使用Relay candidate。
  3. 解析candidate信息,发送到对端candidate。
  4. 对candidate进行配对处理,保证双方匹配。
  5. 检查配对的candidated的连接性。
  6. 计算ICE是否可以连接成功,如果成功,则发送确认消息。
  7. 然后进行语音流的通信。
  以下几个步骤比较详细地介绍了关于SIP ICE的协商过程:



  通过priority oder,结合两个pair check the ICE开始测试。如果双方测试成功,则进行下一步的信令交互,例如SIP 2 发送180消息,发送200 OK消息。如果开始发送到消息和收到的消息不一致,则需要SIP Phone 1 重新发送Re-INVITE消息,然后进行测试验证,最后收到200 OK消息。
  ICE 测试成功以后,则双方开始发送RTP语音。
  关于ICE的支持问题,在我们很多常见的环境中,有的终端可以支持ICE,但是有一些终端可能不支持。用户可以检查各种软电话的ICE配置功能。以下SIP消息中表示终端支持ICE:sip.ice。
  如果对端终端不支持ICE的话,终端只能有两种选择:1)继续连接,但是不使用ICE,ICE支持一个自动检测返回的机制,通知对端不支持ICE。2)或者继续执行一个可选授权支持的方式使用ICE,根据RFC5768对Mandating Support的规定, SIP终端可以在INVITE请求的Require中添加一个ice option。
  另外,用户可能有时看到这样的例子,在终端的SIP INVITE头中没有sip.ice, 但是在SDP中确实有ICE candidate的信息,这也是互相不兼容导致的结果,但是最终这是一种不支持ICE的标识。
  因为SIP技术本身的快速发展,其实ICE的版本也在不断更新。这里,我们简单介绍两个ICE的“升级”版本。这里,我称之为升级版本仅是对ICE的一种优化,它们并不是在ICE本身的升级或者更新:
  ICE-lite主要功能是简化了ICE的复杂性,例如,我们看到的SBC。
  Trickle ICE主要目的是缩短了ICE的协商处理时间,避免重新分配已被转发的candidate,如果需要则开启。不像ICE的标准处理流程,标准的ICE需要收集candidate的信息状态信息,它则一开始就和host candidate检查连接状态,同时并行处理其他的交换机制。所以,Trickle ICE相对较低了处理流程花费的时间。
  关于Near-NAT和Far-NAT讨论
  很多时候,大家可能会看到关于Near End NAT 和Far End NAT的解释说明。从字面意思也可以基本理解这两个概念的基本区别。
  Near End NAT是在本地NAT处理机制中通过本地ALG或者本地SBC修改了SIP 头消息,出局时SIP头消息变成了公网的IP地址,然后运营商SBC增加一个Via到SIP 头,最后呼叫到对端终端。下面图例中的五个处理流程解释了Near End NAT的完整过程。
  Far End NAT是本地网络对SIP头消息不做任何处理,运营商侧SBC修改SIP头消息,添加Via,然后呼叫远端终端。同时,运营商SBC会对内网SIP终端发送一个SIP OPTION 或者NOTIFY消息,保证终端SIP防火墙的端口不被关闭,通信端口一直处于存活状态。
  从以上介绍中,我们可以看到,两者之间的区别就在于在说明地方修改的SIP头的IP地址,而且Far End NAT的处理方式会引起路由器需要不断地接收从运营商SBC发送到大量的NOTIFY消息,这样可能会导致公司内网的不稳定。关于ALG和SBC的解决方案介绍我们会在下一个讲座中专门介绍这些内容。
  总结,在本章节中,我们首先讨论了关于STUN,TURN和ICE的原理和使用场景,同时,我们也介绍了它们之间的不同和各种在实际场景中所支持的功能和其局限性。另外,我们重点介绍了ICE的几个协商流程,最后多两个通常使用的NAT概念做了描述和介绍。ICE本身集合了STUN,TURN的各自的优势,在解决NAT方面可能是目前一种最佳的利器,但是因为网络环境不断变化,终端客户的设备类型也不断升级,所以ICE的技术应用仍然在不断升级来支持更多的要求。用户需要根据自身特点,网络资源,本身成本等不同方式来解决NAT问题。
  参考资料:
  http://manoftoday.wdfiles.com/local--files/nat/SIPNATtraversal.pdf
  https://medium.com/the-making-of-appear-in/webrtc-and-turn-latency-around-the-world-4d172dd59e8e
  https://bloggeek.me/turn-public-ip-address/
  关注我们的公众微信号:asterisk-cn 获得更多有价值的开源通信行业分享,访问技术论坛获得关于开源IPPBX的帮助和下载:www.issabel.cn/forum
【免责声明】本文仅代表作者本人观点,与CTI论坛无关。CTI论坛对文中陈述、观点判断保持中立,不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。请读者仅作参考,并请自行承担全部责任。

相关热词搜索: SIP NAT

上一篇:如何破解消费金融联络效率瓶颈?

下一篇:最后一页

专题