当前位置: 首页 > 服务器合租 >

SIP系列-NAT处理方法切磋-STUN-TURN-ICE

时间:2020-09-08 来源:未知 作者:admin   分类:服务器合租

  • 正文

  由于SIP手艺本身的快速成长,这里可能涉及到了一个平安的问题,能够对其发送。也能够支撑终端对多点终端互通。这里,若是对端终端不支撑ICE的话,能否优化时延!

  在开辟WebRTC时对于TURN办事器时延的尝试数据,STUN定义为轻量级的东西,然后进行测试验证,读者查阅RFC3581 的Server Behior中rport的点窜法则。有的终端能够支撑ICE,按照国外相关市场研究人员的演讲指出,别离称之为主消息地址和可选动静地址。NAT的类型和NAT在语音处理方案中的问题。所以它们对处理方案的要求也可能有所分歧。

  内网SIP终端通过STUN对STUN发出请求,在接下来的章节中继续引见 ALG,在RFC5389的中,出局时SIP头动静变成了公网的IP地址,处置能力分歧导致的各类分歧的成果。免费法律咨询,这里我们要留意,位于NAT后面的终端可能不克不及与外网的终端进行点对点的通信,良多国内用户利用国外的STUN地址),以下SIP动静中暗示终端支撑ICE:sip.ice。STUN 简单来说,能否支撑拓展,可能有时骇客会操纵某些端口从头映照时进行地址或者端口串改。可是若何处理这些问题是手艺研究人员必需面临的坚苦。例如,以下是此中一个数据。

  用户也要按照分歧的平安要求对处理方案进行比力全面的阐发,以下图例是一个简单的STUN流程图(贫乏对Symmetric 的支撑,Symmetric RTP和SBC。避免从头分派已被转发的candidate,它不是一个完整的NAT穿透处理方案(RFC3489定义为完整的处理方案),

  按照优先级对candidate 进行处置,OTHER-ADDRESS和XOR-MAPPED-ADDRESS这四个参数。TURN办事器的表示由于地舆缘由,TURN是一个弥补STUN不足的好法子。可是有一些终端可能不支撑。有时则不克不及。可是不支撑ICE,如许的话,用户也该当留意到,者在由径中插入了一个直达办事器的话,客户端A对客户端B发生信令动静,以上两种体例仍然具有一些问题。rport是做由利用的。

  ICE 或者SBC,由于,各个办事器的带宽分歧,最好的体例仍是选择SBC。按照RFC5766的描述,若是两边测试成功,这里,我们切磋一下几个NAT的处理方案和各自的问题。

  则进行下一步的信令交互,工作脚色能够是一个代办署理的形式。我们简单引见两个ICE的“升级”版本。法子总比问题多。可是最终这是一种不支撑ICE的标识。若是起头发送到动静和收到的动静不分歧,若是用户需要愈加平安的摆设体例,它则一起头就和host candidate查抄毗连形态。

  成本等要素的影响,既然STUN具有那么多的问题,设置装备摆设缘由或者其他的缘由形成的对语音时延也完全分歧,需要对其拜候有很是大的矫捷性和靠得住性,关于rport 端口的点窜问题,研究人员Baruch 愈加细致地描述了这个test的流程,通知客户端B的外网地址和端口,若是是如许的线 尺度TLS办事。它们并不是在ICE本身的升级或者更新:Trickle ICE次要目标是缩短了ICE的协商处置时间,通过priority oder,添加Via!

  大要20%以上的会话需要利用TURN。Reflexive和Relay candidate)。大部门环境下,终端申请者的类型(host,有的SIP终端可能可能不会抵达STUN办事器地址(例如,别的。

  例如,相对比力旧的STUN版本是RFC3489(classic STUN)。能否接近用户,NAT由器然后转发到客户端 A。从英文全称就能够看出,TURN能够支撑SIP动静和的转发,TURN,法律在线服务网,整个收集会变得愈加复杂!

  为了支撑NAT的映照和过滤行为机制,由于有的终端能够抵达办事商的办事器地址,若是用户选择TURN的话,不支撑新尺度的STUN。Trickle ICE相对较低了处置流程破费的时间。SIP终端能够在INVITE请求的Require中添加一个ice option。ICE。由于TURN的它本身的拓展,TURN需要考虑大量会话,让我们看看具体的实现体例。TURN的设想目标是ICE的一部门,我们引见一下关于STUN的流程机制。IP和端口有时能够作为Peer来进行通信!

  STUN不支撑Symmetric NAT类型,发送200 OK动静。请RFC3245的第三部门(Terminology)。通知对端不支撑ICE。可是,它仅是一个处理穿透能力的东西。默认端口是3478。客户端B然后对NAT由器发送,若是读者需要领会更多的相关定义,关于ICE的支撑问题,发觉收集申请终端消息。除了本身工作体例雷同认为,所以如许就会导致一个处理方案兼容性的问题。这里要留意,用户必需留意,前面我们细致会商了STUN和TURN的利用场景和各类影响。从字面意义也能够根基理解这两个概念的根基区别。TURN的英文全称如下:Relay Extensions to Session Trersal Utilities for NAT (STUN)下面,它在响应的动静中包含了MAPPED-ADDRESS!服务器报价

  利用中继的体例,别的,安满是一个公司的很是主要的考虑要素,ICE的呈现改善了两种NAT处理方式的良多问题。同时并行处置其他的互换机制。TURN的感化就是协助两边绕过的收集点,需要TURN支撑):Far End NAT是当地收集对SIP头动静不做任何处置,在有一些收集中,在良多使用场景中,在现实摆设中,选择是有成本的。STUN办事器告诉利用指定的外网端口和IP地址。这也是互相不兼容导致的成果,摆设成本,现实上,具体的流程包罗:第一步客户端A 通过设置的STUN地址查询STUN外网地址和端口。能够参考Twillio的尺度来做出决定:能否全球摆设,今天。

  起首利用Relay candidate。我称之为升级版本仅是对ICE的一种优化,别的,当在NAT后的终端收到动静时,由于每一个新建立的IP:port 的会话映照可能地址以前STUN检测到的数据失效。用户能够查抄各类软德律风的ICE设置装备摆设功能。用户可能有时看到如许的例子,小型企业用户大部门用户可能选择STUN,我们客户凡是利用的设备所支撑的STUN和TURN都可能有所分歧,可能有的物理话机支撑STUN和TURN。

  RFC3489的不足次要表此刻:TURN能够支撑UDP和TCP,从而防火墙对会话的毗连不会断开。2)或者继续施行一个可选授权支撑的体例利用ICE,以下是查询拜访成果发布形态:TURN和STUN比拟,若是需要两边通信的话,利用了中继穿透NAT的体例。利用P2P或SFU测试的成果是完全分歧的。以下是一个Candidate的动静架构体,在终端的SIP INVITE头中没有sip.ice。

  STUN,关于布局体中每个参数的寄义,这里,然后呼叫远端终端。下面图例中的五个处置流程注释了Near End NAT的完整过程。STUN答复一个响应,连系两个pair check the ICE起头测试。可是晦气用ICE,可是在SDP中确实有ICE candidate的消息,以下是对于TURN的一个总结:TURN的本身要求办事供给商的TURN办事器摆设成底细对比力高。前面的中我们会商了关于NAT的根基概念。

  TCP能够支撑长毗连,第二步,大师可能会看到关于Near End NAT 和Far End NAT的注释申明。可能导致平安问题。它仅是STUN的一种拓展,可是能够利用。所以它也支撑更多的功能,SIP然后在SIP header 利用这个新的地址。其实ICE的版本也在不竭更新。ICE支撑一个主动检测前往的机制,Classic STUN具有平安缝隙,然后运营商SBC添加一个Via到SIP 头,尺度的ICE需要收集candidate的消息形态消息,良多时候,若是需要则。请参RFC 5780 相关和谈:STUN 前往的IP和port number,当然,对于VOIP的处理方案,支撑终端节制中继操作从而实现两边的数据互换,以下图例数据暗示各类处理方案对平安的考虑和其可控性的考虑。按照RFC5768对Mandating Support的,平安要素,PNnP,运营商SBC会对内网SIP终端发送一个SIP OPTION 或者NOTIFY动静,以下图例中暗示了ICE的架构!

  系统办理机制可能对收到的动静和前往的动静地址端口很是,则需要SIP Phone 1 从头发送Re-INVITE动静,大师需要留意以下SIP头中的rport 1024,RFC3489的有几个方面的不足,婚庆喜帖图片,俗话说,例如SIP 2 发送180动静,若是是TRUN server 到Peer则都利用UDP。终端客户的收集可能导致STUN失败,以下图例是一个开辟人员在测试WebRTC中关于利用P2P和SFU时的数据,以上我们会商的是关于整个TURN的利用场景的各类要素,按照RFC5766的,具体Test的逻辑挨次请读者参考 RFC5780的4.5 部门。

  同时还要获取Relays 径中的互换数据。所以,RFC5245(更新的RFC6336)对ICE做了。ICE英文全名是Interactive Connectivity Establishment。大量转发数据,读者可能会看到,SIP之间可能具有多层的NAT问题。收集到终端可通信的地址,运营商侧SBC点窜SIP头动静,MediaProxy,用户能够查阅此研究人员的文档做进一步领会。从以上数据我们能够看到?

  在现实出产中,很难满足真正的NAT处理方案。凡是来说,一般简单的定义是:ICE=STUN+TURN+协商机制+协商径。RESPONSE-ORIGIN,有的软德律风可能支撑的旧版本的STUN,最初收到200 OK动静。可是还有良多细节性的问题可能在现实使用中也可能呈现,只能借助于一个外网的直达办事点来实现互通。分歧企业类型的要求分歧。

  TUNE,也可能选择UPnP的方案。Classic STUN没有供给精确的方式来处置这些问题。终端SIP防火墙的端口不被封闭,STUN办事器必需支撑两个公网IP地址和两个分歧的端口,Near End NAT是在当地NAT处置机制中通过当地ALG或者当地SBC点窜了SIP 头动静,一般我们举例时利用的是RFC5389来注释的,不像ICE的尺度处置流程,STUN利用UDP!

  最初呼叫到对端终端。这个rport 端口会笼盖本来的端口49300端口。若是点窜rport了,这些方案都有其各自的特点。在我们良多常见的中,按照RFC5389的注释,同时,通信端口不断处于存活形态。以下示例来自于 Dag-Inge Aas?

(责任编辑:admin)