当前位置:首页 >> 旅行箱

完整SIPSDP媒体协商概论1开关元件长春消毒箱抗磨剂男士腰包

2022-07-27 03:38:28  注塑机械网

完整SIP/SDP媒体协商概论

在前面章节中,无论是关于发送offer还是关于接收answer消息的讨论中都没有离开一个重要的步骤,那就是执行连接性检查(connectivity checks)。因为侧重点的不同,笔者在前面的章节没有详细介绍连接性检查的具体细节,在这个章节,我们重点讨论连接检查的具体内容和执行流程。

所有ICE的部署需要符合RFC5389中STUN的规范(已经更新为RFC8489)。大家知道,全部署场景的agent才是ICE部署中核心内容。全部署场景agent需要扮演STUN客户端(生成检查)和STUN服务器端(接收检查)的两种角色。轻量级的agent则作为服务器端只能接收检查(check)。因此,我们所讨论的内容将以SUTN客户端生成流程日本注射机制造商希望用这类更低本钱的碳纤维复合处理技术制造碳纤维复合材料和服务器端接收流程两个部分的内容进行讨论。其中,STUN客户端流程主要包括:

创建权限支持转发候选地址

服务器端主要流程包括:

全场景部署agent的其他额外步骤处理

轻量级部署agent的其他额外步骤处理

笔者会根据以上的内容逐一进行讨论。首先,笔者将介绍关于STUN客户端的流程处理。

1STUN客户端流程总览

这里,笔者首先说明一下关于STUN客户端的发送流程。STUN客户端发送连接检查(connectivity 船用阀门checks),确认连接检查是一个ordinary还是triggered check。另外,笔者说明一下,以下讨论的流程仅支持全部署场景agent。

为了保证安全,笔者在前面的文章中也提到过,转发也需要一个权限要求。如果使用relayed 本地候选地址发送连接检查的话,如果以前没有创建转发权限的话,客户端必须首先需要创建一个转发权限,允许通过relayed本地候选地址进行转发。如果已经有已创建的转发权限的话,agent可以使用这个权限。如果需要创建转发权限的话,agent转发权限需要根据一定的流程来实现权限处理。具体的权限创建流程读者可以参与RFC和9章节。创建好的权限必须支持远端候选地址。一种情况需要特别处理,agent在正常情况下,发送CreatePermission请求进行连接检查创建时,RFC5245规范推荐agent要延迟TURN通道创建,直到ICE完成后再开始创建。一旦权限创建完成以后,agent必须维护权限的活动状态,一直到ICE结束此流程。

2发送请求

在STUN客户端处理流程中,本地候选地址对远端候选地址发送绑定请求(Binding request),发送此请求后生成一个check。关于绑定请求的具体构建和生成,读者可以参与RFC8489。连接检查的安全策略必须使用STUN短期安全机制来实现。关于STUN短期安全机制(用户名称/密码+时间限定)和长期安全机制笔者在以前也做过介绍,读者也可以查阅RFC.1章节了解更多细节。注意,不能使用RFC3489实现向后兼容的支持能力。连接检查必须使用FINGERPRINT机制来实现STUN消息区分。关于FINGERPRINT机制的定义,读者可以查阅RFC。

ICE通过定义四个新属性拓展了对STUN支持,这四个属性分别是PRIORITY,USE-CANDIDATE,ICE-CONTROLLED,和ICE-CONTROLLING。在接下来的章节中笔者分别介绍这四个新定义的拓展属性。注意,这四个STUN拓展的新属性仅支持ICE的连接检查。

3ICE定义的四个新STUN拓展说明

如果agent发送绑定请求时,它必须在其绑定请求中包含一个PRIORITY拓展属性。agent必须设定这个PRIORITY等于候选优先级排序中设定的那个权限设置。对于反射候选地址来说,这个优先级可以通过检查结果的学习来获得。除了反射候选地址中的偏好类型设置为此偏好设置以外,此优先级值计算和本地候选地址配对计算也是一样的。

在绑定请求中,被控方agent可以包含一个USE-CANDIDATE。但是,主控方一定不能在绑定请求中包含此拓展属性。此STUN拓展属性USE-CANDIDATE表示的意思是被控方agent希望退出此构件中的检查,使用来自于此构件中的候选配对执行检查。这里涉及了一个配对推荐的具体流程,笔者在未来的文章中将具体讨论此指导原则和此STUN拓展的使用。

其余两个拓展属性根据角色不同选择包含不同的属性。具体来说,如果agent是在一个主控方角色中的话,在agent发送绑定请求时,它必须在请求中包含ICE-CONTROLLED拓展属性。如果是在被控方agent中的话,它必须在绑定请求中包含一个ICE-CONTROLLING拓展属性。当然,两种角色可能会因为会话不同其内容也可能不同,具体关于其角色决定的内容处理,笔者在前面的文章中有非常详细说明。

4构建安全信息

除了agent发送绑定请求中需要各自包含所需要的拓展属性以外,agent同时也需要发送衬套一定的安全信息来实现安全验证。绑定请求作为一种连接检查,它也必须使用STUN短期安全机制。STUN短期安全机制需要用户名称和密码。安全策略中的用户名称是本地agent的用户名称和远端peer的用户名称的合并名称(通过括号分开),密码是远端peer提供的密码。这里的策略设置比较迷惑,读者一定要注意。

连接检查用户安全构件组合

具体连接检查的处理方式如上图示例,根据连接检查的方向不同,用户名称和密码的选择组合是不同的。如果从L侧发起,L端agent需要对R端agent进行连接检查的话,它的用户名称组合方式是(RFRAG:LFRAG),密码是RPASS;反之亦然,如果从R端发起连接检查,其用户名称组合是(LFRAG:RFRAG),密码是LPASS密码。返回响应时,响应处理使用的用户名称/密码和请求中的相同(USERNAME属性不会出现)。

5区分服务处理

如果agent在媒体数据中(例如在QoS中)使用了区分服务-Diffserv(遵从RFC2475),agent也应该对连接检查使用同样的标识方式。因为区分服务不在我们讨论的范围,具体关于Diffserv,读者查阅RFC2475,这里不做进一步讨论。

6处理响应

当收到响应以后,这个响应需要使用事务ID和其绑定请求关联在一起。这个绑定关联的处理流程在RFC5389或RFC8489中定义。然后agent把响应绑定到候选配对上,这个候选配对是绑定请求以前发送的候选配对。针对具体的STUN使用中关于失败响应和成功响应的不同场景,这个部分定义了额外的步骤来处理这些流程。下面,我们专门针对失败响应处理和成功响应处理做进一步的介绍。

7失败响应场景和成功响应场景详解

失败响应有很多种。如果STUN事务生成一个487错误码,这表示agent角色冲突。agent需要检查在请求绑定中是否包含了前面所说的拓展属性ICE-CONTROLLED或ICE-CONTROLLING。如果请求包含的是ICE-CONTROLLED属性,agent还没有完成角色切换的话,它必须切换到主控方角色。如果请求包含的是ICE-CONTROLLING属性,agent还没有完成角色切换的话,它必须切换到被控方角色。一旦agent完成切换的话,它必须对生成487错误的候选配对进行入队处理,然后这个队列进入到triggered check queue中。然后将此配对状态设置为等待状态。当triggered check发送以后,它将包含一个ICE-CONTROLLED或ICE-CONTROLLING属性,这个属性反映它新的角色。这里注意,tie-breaker的值一定不能重选。

角色切换以后,需要进一步的计算。因为不同角色具有不同的功能,因此agent需要重新计算配对优先级(前面文章有介绍)。另外,角色切换还会影响agent所负责的其他功能,例如基于ICE结果选择推荐配对,和生成更新的offer消息。除了ICMP错误以外,因为环境不同,可能STUN事务还能生成其他目前该分站已建成面积电声测试约1万平方米的错误响应。Agent也可以支持针对连接检查的ICMP错误接收的工作。如果STUN事务生成ICMP错误,agent将会设置此配对为错误状态。如果STUN事务生成的错误是不可恢复的错误或者超时错误的话,agent也会设置此配对的状态为错误状态。关于不可恢复的错误,读者可以查阅RFC.3.4章节关于错误的详解。

Agent必须检查源IP地址和响应端口是否等同于目的地地址和端口(目的地地址和端口是绑定请求发送过去的地址和端口),并且响应中的目的地地址和端口是否匹配源地址和端口(源地址和端口是从绑定请求中发送的)。换句话说,在请求和响应中的源地址和目的地传输地址是对称的。如果这两组地址不对称,agent将会设置此配对是失败状态。

以上笔者讨论的是检查失败响应的处理。现在,笔者讨论成功响应的处理。如果检查成功的话,检查成功,以下所有条件必须为真:

STUN事务生成成功响应。

响应中的源IP地址和端口等同于目的地IP地址和端口(绑定请求中发送的)。

响应中的目的地IP地址和端口匹配源IP地址和端口(从绑定请求发送的)。

获得成功响应以后,agent需要进一步对响应消息和候选配对进行处理。其流程需要经过四个步骤的处理。笔者继续分别介绍这几个流程。

第一个步骤是发现peer的反射候选地址。Agent需要从响应中检查映射地址。如果传输地址不能匹配agent获知的任何本地候选地址,映射地址表示一个新候选地址,此地址就是peer反射候选地址。此反射候选地址和其他的候选地址一样,同样具有类型,基准地址,优先级和foundation。这四个属性的计算方式如下:

它的类型等同于peer的反射地址。

它的基准地址等同于候选配对中的本地候选地址,从地址来自于STUN检查发送地址。

它的优先级设置为绑定请求中的PRIORITY属性值。

它的foundation是通过foundation计算获得。

计算以后,peer反射候选地址(peer reflexive candidate)会添加到媒体流的本地候选地址列表中。对此媒体流来说,其用户名称和密码和其他本地候选地址的相同。但是,peer反射候选地址不会和其他远端候选地址配对。在此流程中,也没有必要进行反射地址和远端地址的配对处理。一对有效的配对会立刻通过构建有效配对的流程进行处理(此章节第二个步骤介绍)。如果agent希望peer反射候选地址和其他远端候选进行配对的话(这个远端候选地址不在将生成的有效配对内),agent可以生成一个更新的offer,在此offer中包含peer反射候选地址。通过这样的方式,agent可以完成此peer反射候选地址和其他远端候选地址配对的流程。

发现了反射候选地址以后,第二步的流程就是构建有效配对。agent可以开始构建一对候选配对。候选配对中,它的本地候选地址等同于响应中的映射地址,它的远端候选地址等同于绑定请求中发送的目的地地址。因为它们的有效性已经通过STUN连接检查验证,这样的配对称之为有效配对。读者需要注意,有效配对可能来自于不同的配对。具体来说,有效配对可能等同于检查生成的配对,可能等同于检查列表中不同的配对,或也可能是一对当前不在检查列表中的配对。如果这个配对是来自于检查流程生成的配对或者在当前检查列表的配对,它也可以被添加到有效列表中(VALID LIST)。agent为每个媒体流维护此列表状态。在ICE处理流程启动时,这个列表是为空状态,检查流程开始执行后在列表中逐渐增加配对,最后生成一个有效候选配对。

Agent经常也会遇到一些特殊状态-配对不在任何检查列表中。为什么会出现这样的情况呢?我们可以回顾一下这样的情景,检查列表有一对配对,其本地候选地址从来就不是一个反射候选地址。这种配对已经获得了它们的本地候选地址(这些地址已经转换成了服务器端反射候选地址的基准地址),如果这些配对重叠的话,需要对这些配对进行过滤筛选处理。当针对STUN检查的响应返回时,如果两个agent之间存在一个NAT时,映射地址将会是一个反射地址。这种情况下,有效配对将有一个本地候选地址,这个地址不能逻辑IC匹配检查列表中的配对的任何候选地址。

如果一对配对不在任何检查列表中的话,还要首先进行关于优先级的计算处理。Agent将会为此配对计算优先级。优先级计算基于每个候选地址优先级,其计算方式根据构建检查列表的流程来进行。本地候选地址的优先级基于其类型来决定。如果它不是peer reflexive,优先级等同于SDP中候选地址指示的优先级。如果它是peer reflexive,优先级等同于agent完成的绑定请求中的PRIORITY属性值。远端候选地址的优先级来自于对端peer的SDP中。如果没有出现远端候选地址,检查流程必须启动一个triggered check来生成一个远端候选地址。这种情况下,优先级来自于triggered check完成的绑定请求中的PRIORITY属性值。然后,这个有效配对被添加到有效列表中(VALID LIST)。

完成有效配对的构建,agent还要进行第三步处理流程。这个步骤就是更新有效配对的状态。Agent设置配对状态,这个状态是一个生成检查成功的流程。这里一定要注意,作为一种响应结果,这里的配对(生成检查流程)和构建有效配对是不同的处理方式(前面介绍过)。检查的成功可能引起其他检查的状态也发生改变。Agent必须按照以下两个步骤来执行:

针对同样媒体流和同样foundation,agent修改所有其他封冻状态的配对到一个等待状态。通常来说,也不总是这样,它们的其他配对将有不同的component IDs。

对此媒体流的每个构件来说,如果在有效列表中有一对配对,这个检查的成功可能对其他媒体流关闭封冻检查。注意,按照这一步的流程执行的话,对每个媒体流的构件来说,不仅是第一次有效列表配对在这种情况下所需要使校企双方联合发展、互利双赢考虑按照这些流程执行,每一个后续检查获得的检查成功结果获得的配对都要添加到有效列表中。agent按照顺序对其他媒体流查询检查列表:

如果检查列表是在活动状态,agent修改检查列表中所有封冻状态的配对(它们的foundation匹配了有效列表中等待状态的配对的foundation值)。

如果检查列表是封冻状态,并且在检查列表中至少有一对配对,它的foundation匹配了有效列表的配对的foundation,在检查列表中所有配对中,如果其foundation匹配了有效列表中的一对配对的foundation的话,所有列表中配对的状态会设置为等待状态。这样的处理结果会导致检查列表变为活动状态,ordinary checks开始为其工作。具体细节查阅笔者历史文档中的定时检查设置。

如果检查列表是封冻状态,并且检查列表中没有配对,它的foundation匹配有效列表中的配对的foundation的话,agent将执行以下处理流程,agent将会对所有的配对分组设置,所有配对有同样的foundation,并且,针对每个组设置,具有最低component ID的则设置其配对状态为等待状态,如果有一个以上这样的配对的话,则启用最高优先级的配对。

Agent完成了更新配对状态以后,最后agent将会执行第四步进行更新推荐配对处理。如果agent是一个被控方agent,它已经在绑定请求中包含了USE- CANDIDATE属性的话,从check生成的有效配对已经有一个推荐配对设置flag,这个设置为true状态。如果此配对的优先级在所有标识的配对中具有最高的优先级,这个标识则表示此媒体流或所有媒体流将使用这一对有效配对。如果agent是一个主控方agent,这个响应可能是triggered check的结果,这个triggered check在响应中返回到请求,此请求自己包含一个USE-CANDIDATE属性。这样的情况就是一个更新推荐配对示例,它可能导致对这个配对(这个配对是从原始请求学习获得)进行推荐flag设置。

以上介绍了失败响应和成功响应的处理。在处理响应的流程中,除了对失败响应和成功响应进行处理以外,还要对检查列表和定时器更新进行处理。无论检查是否是成功还是失败,最后事务完成需要更新检查列表和定时器的状态。如果所有在检查列表中的配对是失败或者成功的状态:

针对每个媒体构件来说,在有效列表中没有一对配对,检查列表的这个状态设置为失败状态。

对每个封冻的检查列表,agent以同样的foundation对所有配对进行分组

并且针对每个组,把带最低component ID的配对的状态设置为等待状态。如果有超过一个以上这样的配对,则使用具有最高优先级的配对。

如果在检查列表中没有任何配对在封冻或者等待状态的话,这个检查列表则不再认为是活动的检查列表,并且针对ordinary checks,检查列表不会在定时器计算中计入N的值。这里N是指活动检查列表数量。具体就是流程,读者可以查阅笔者上一篇历史文档关于设定定时检查的讨论。

本章节重点介绍了关于ICE连接检查中的STUN客户端的处理流程。为了避免让读者引起歧义,方便读者阅读,笔者将STUN服务器端处理流程独立分为另外一篇文章发布,关于STUN服务器端的处理流程将在下一篇文章中加以介绍。STUN服务器端主要流程包括两个场景的处理流程:首先是关于全场景部署agent的其他额外步骤处理(检测和修复角色冲突,计算映射地址,通过学习获得peer反射候选地址,Triggered Checks讨论和更新推荐配对标识),然后是关于轻量级部署agent的其他额外步骤处理。

参考资料:

关注公众号:asterisk-cn,获得有价值的Asterisk行业分享

Asterisk freepbx FreeSBC技术文档:

融合通信/IPPBX商业解决方案:

如何使用FreeSBC,技术分享群:

黄冈制作西服
阜阳订做西装
泸州职业装
宜宾工作服
相关资讯
友情链接