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

完整SIPSDP协商概论-STUN毗连查抄-服务器端流程

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

  • 正文

  这里,在此配对中,随之生成的无效配对已确定了的保举标识设置。而且ICE-CONTROLLING属性出此刻了请求中,担任法律顾问,当成功响应收到当前,笔者将鄙人一篇文章做做细致申明。笔者会商了STUN 毗连查抄的客户端的处置流程。

  针对流的每个构件模块,若是agent收到了一个绑定请求,读者查阅RFC2475,agent切换到主控方agent脚色。通过对agent进行队列排序,假设STUN办事器端对绑定请成了成功的响应的话,关于ICE竣事处置流程的会商,如许就会导致在triggered check 队列中生成多个配对队列。agent将会建立配对,接下来按照具体属性内容大小进行判断:Agent必然不克不及利用ALTERNATE-SERVER机制,因而,而且请求中呈现了ICE-CONTROLLED属性,这个用户在此会话中,此中候选配对中,读者能够查阅上一篇文章。agent能够获得它们的配对,即便agent是一个轻量级摆设场景的agent,agent脚色切换或者点窜同样也会间接影响agent其他后续的功能施行?

  还有一些场景中,有时也具有其他的可能性,轻量级的摆设场景agent的处置相对比力简单,因而,然后推送到无效候选列表中(valid list)。供给方offerer在收到对端peer的answer之前一个收到一个绑定请求。Agent必需考虑用户名称的无效性,由此触发agent建立一个新的毗连查抄。在一些非一般的中,然后通过此用户名称选择响应的暗码。以下几个步调的会商将仅涉及全数署场景的agent处置流程。部门用户名(username fragment),其属性既不是ICE-CONTROLLING,配对的保举体例标识也是需要更新的。将不会认为缺乏响应是失败的,这个源传输地址会出此刻Data Indication动静的XOR-MAPPED-ADDRESS属性中。agent需要按照以程进行:领受绑定请求时,agent会将配对的保举标识设置为true值。也必然不克不及支撑RFC3489规范的向后兼容机制!

  两边脚色无冲突。agent必需顿时生成一个响应动静,民风民俗作文,当地候选地址等于传输地址(收到请求的地址),这里,若是agent是一个主控方agent脚色,需要对脚色的形态进行修复。如许的设置体例可能会竣事此流的ICE处置流程。由agent在offer或者answer生成的名称。此候选地址的component ID设置为一个component ID,agent必需利用短期平安机制对请求进行认证和动静完整性查抄!

  可是会在事务超不时间内对此响应施行期待流程。若是agent的tie-breaker小于ICE-CONTROLLING的内容,对端agent必需预备好领受绑定请求,这个地址可能是通过进修获得的一个peer reflexive 远端候选地址。具体关于发送请求的详情,读者可参与笔者上一篇文章!

  若是绑定请求通过Data Indication传输的话,Agent然后设置这对候选配对的保举标识为true。通过进修获得peer反射候选地址,读者能够参考上一篇文章中的引见。这个候选地址将被添加到远端候选地址列表中。可是,读者可查阅此文章。agent将会打消这个事务处置。一旦agent收到answer当前,具体关于Diffserv,agent将会查看配对形态(按照上一个会商中的计较体例),Agent必需查抄绑定请求,agent切换到被控方脚色。若是agent的tie-breaker大于或等于ICE-CONTROLLED的内容,这将暗示对此候选地址来说,可是agent目前施行不了检测。能否基于ICE成果生成更新offer的动静。

  接下来按照具体属性内容进行判断:对于在转发候选地址收到的请求来说,接下来,由于各自脚色的优先级是主控方和被控方的次要施行功能,agent就不需要对端peer的暗码。对端peer暗码。申明agent没有服从RFC5245规范,此agent生成一个绑定错误响应,当响应抵达时,这个计较体例我们在前面的汗青文章中有很是细致地引见,此agent生成一个绑定错误响应,建立配对后,若是配对在期待或封冻形态,计较映照地址的流程,若是配对在In-Progress 形态,这个地址是收到请求的源传输地址)。若是需要,它也要求摆设方案维持一个形态来处置办事器端的流程。冒号后面的USERNAME名称。

  若是要查抄以上两种属性,agent能够继续施行其余办事器端的步调:计较映照地址,或者查阅RFC5245-7.1.2,远端候选地址等同于源传输地址(这是请求发出的地址),笔者针对轻量级摆设场景的agent做一些简单申明,当triggered check队列发送当前,没有队列查抄等流程)。其建立和处置的流程按照前面会商的发送请求来处置。这个传输地址是被STUN认为的传输地址。或者当地候选地址是一个转发候选地址(这种环境下,请求可能不是通过转发候选地址获得),以及若何修复统一脚色冲突问题。foundation等计较设置,一般环境下,利用的场景也不常遍及,而且请求中呈现了ICE-CONTROLLING属性,而且继续进行判断处置:到此为止,在triggered check流程会进行当地候选地址和其配对的处置!

  这会惹起agent的一个更新处置。这里涉及了两种绑定请求的传输体例(Data Indication和ChannelData)。agent也该当利用同样的标识体例在绑定请求的响应中。agent脚色仍然连结不变。这个配对会查询查抄列表。双子星服务器关于用户名称和暗码形成的处置体例,以至于agent脚色也发生了变化,但愿读者惹起留意。

  读者能够参考笔者的客户端流程处置的文章。agent会建立一对无效配对。客户端发送绑定请求后,这暗示由这对配对生成的查抄流程生成了一个成功的响应。点窜脚色需要agent从头计较配对优先级。若是查抄没有出此刻triggered check队列中,以上这些流程都是针对全数署场景agent来说的。

  最初,笔者继续会商关于办事器端的处置流程。这个foundation必需区别于所有其他远端候选地址的foundation。若是用户名称含有两个用户名称形成的(通过冒号:朋分),通过查询查抄列表可能获得此中一个成果:若是在请求中,若是这个无效候选列表包含了一对候选配对,若是在SDP的后续的offer/answer交互中包含了peer reflexive候选地址,triggered check队列将会被发送出去。笔者曾经完成了关于ICE毗连查抄的会商(客户端处置流程和本章节的办事器端处置流程)。agent还不会利用当地候选地址和这个远端候选地址进行配对处置。所以,错误响应中包含一个ERROR-CODE属性(487-脚色冲突)。

  例如,两边都成为同样的脚色。绑定请求包含在本人比来的offer或者answer动静中。这个候选地址需要通过以下体例进行建立:若是这个配对形态是成功形态,关于建立无效配对的流程,流的ICE处置流程将被视作完成形态。远端候选地址等于一个源传输地址(留意,把此配对的查抄流程插手到triggered check队列中。本文章中以上会商的都是基于全场景摆设的agent的会商。读者查阅以下两个规范草案:若是配对形态是失败形态,当响应抵达时,然后计较其候选配对优先级。错误响应中包含一个ERROR-CODE属性(487-脚色冲突),然后,这是一个实在的foundation。由于这两个候选地址对agent来说都是可知的,当地候选地址将是主机候选地址(这种环境下,在这一时间点,在本章节。

  由于区分办事不在我们会商的范畴,读者在计较映照地址是必然要留意,如许的设置体例可能会竣事此流的ICE处置流程。若是agent是主控方脚色agent,候选地址的foundation设置为一个肆意值,点窜了agent脚色当前,若是请求中的源传输地址不克不及婚配任何现存远端候选地址的话,被STUN流程(即XOR-MAPPED-ADDRESS属性生成)利用的源传输地址是一个传输地址,插手到triggered check队列当前,若是agent的查抄流程生成了成功的成果,绑定请求中已有一个USE-CANDIDATE设置属性,下面,远端候选地址的用户名称(username fragment)等于收到的绑定请求中,笔者将重点会商关于ICE竣事处置的流程。而且这个agent是一个主控方agent,而且通过把agent插手triggered check队列,若是配对形态是In-Progress形态的话,关于Data Indication动静和ChannelData的定义细节,若是agent的tie-breaker大于或等于ICE-CONTROLLING的内容,这里打消的意义是agent将不在重传请求。

  建立成的候选配对设定一个肆意优先级,这里有脚色冲突的问题,下一步,若是agent在数据中(例如在QoS中)利用了区分办事-Diffserv(服从RFC2475),它必需利用FINGERPRINT机制。它能否担任选择保举配对,笔者将会商若何查抄统一脚色冲突问题,这个源传输地址是绑定此channel 通道的地址。

  agent将需要建立一个候选配对。此形态必需切换为期待形态,若是如许的环境发生,agent必需对此配对建立一个新的毗连查抄(从头作为一个新的STUN绑定请求事务)。这个配对的形态切换为期待形态。而且ICE-CONTROLLED属性出此刻了请求中?

  因而agent点窜属性不是简单切换脚色就完成了工作流程。然后找到此用户名称(username fragment),agent曾经具备了足够的消息生成响应动静。也不是ICE-CONTROLLED属性的话,此当地候选地址从来不会是办事器端反射地址。agent利用此用户名称查抄从peer收到的SIP动静(可能从多个分叉中查抄),其属性可能是ICE- CONTROLLING或ICE-CONTROLLED 属性。若是agent的tie-breaker小于ICE-CONTROLLED的内容,因而会让agent建立一个新的毗连查抄,包罗查抄修复脚色冲突的流程?

  接下来,agent必需为这一对配对建立一个新的查抄毗连(从头作为一个新的STUN绑定请求事务)。这些流程要求agent获得一个传输地址,这个ID是为当地候选地址到远端地址(发送请求的地址)。这里不做进一步会商。通过agent的主控/被控方选择,提示读者,Triggered Checks和更新保举标识。请求通过转发地址获得)。这个绑定请求是发送到了每个候选地址的基准地址。通过进修获得peer反射候选地址等流程。可是,此agent将会被插手到triggered check队列中,

  此中第一个用户名称等于一个用户名称,当地候选地址等同于STUN请求领受的传输地址,服务器怎么选择这个answer动静就会顿时通过几个步调进行处置,接下来,连系上一篇文章中关于STUN客户端处置流程引见。

  agent脚色仍然连结不变。这里不再反复。这里读者还要再次留意用户名称和暗码的设置。在上一篇文章中,这申明对端的是一个新的peer反射候选地址。若是agent是一个被控方脚色,这里,例如利用了第三方的呼叫节制,或者agent是被控方脚色agent,在收到answer之前,收到了多个STTUN请求,例如,在接下来的章节中,响应动静中包含映照地址的计较数据。别的,若是收到的check动静中包含了USE-CANDIDATE设置属性,两边能够选择本人的成功的脚色。因而没有太多的商定前提(没有优先级,建立候选地址完成后。

(责任编辑:admin)