用ice实现java和c++的通信,代理类型返回为空是什么原因

用ice实现java和c++的通信,代理类型返回为空是什么原因,第1张

有区别, ICE 在基本上的相同的,但很多都是基于slice上的。 换句话来讲只能是在slice上通用。

实际ICE是根据slice生成不同的原生语言(java,c++,php,c#)等,所以在语言上是等同于使用原生语言开发。 在数据上几乎是一样的,不过在显示中文的时需要注意字符集问题。

返回代理类型为空一般都是,ICE的配置属性是于相符, 代理是不是找不到。

课程地址:零声学院 WebRTC入门与提高 https://ke.qq.com/course/435382?tuin=137bb271

技术支持QQ群:782508536

更多音视频知识请点击: 专注音视频开发

交互式连接建立是一种标准穿透协议,利用Stun和Turn服务器来帮助端点建立连接。市面上已有不少介绍ICE的资料,像《WebRTC权威指南(第三版)》中的“9.2 交互式连接建立”。但看了那些后,有人还是不能理解,这里试着用一个实例来描述整个过程。ICE协议只是制定规范,没规定怎么实现细节,在细节实现上这里参考Google的WebRTC。

上图就是《WebRTC权威指南(第三版)》中的图9.1。呼叫要交换两种信息,一是候选地址,二是媒体信息。候选地址用于建立网络连接,它存储着和网络连接相关的参数。媒体信息(SDP)用于描述要在对等连接上传输的数据,包括音频、视频和数据。用路和车来比喻的话,候选地址用于造路,媒体信息于用指定要跑什么车。

在图中,双方是串行处理媒体、候选地址,但实际中是并发的。举个例子,主叫收到Answer后,它仍可能在收集候选地址,然后通过信令服务器发向被叫。

除了主叫必须创建Offer才开始收集候选地址、被叫必须创建Answer才开始收集候选地址外,ICE代理是相互独立地处理媒体和候选地址。 (这结论细节参考底下的“四:选定候选地址,并启动媒体”)。

和“9.2 交互式连接建立”一样, 这里也把ICE分为六个步骤。下图是例子使用的网络拓扑结构。

<ignore_js_op style="word-wrap: break-wordcolor: rgb(68, 68, 68)font-family: Tahoma, Helvetica, SimSun, sans-seriffont-size: 14pxfont-style: normalfont-variant-ligatures: normalfont-variant-caps: normalfont-weight: normalletter-spacing: normalorphans: 2text-align: starttext-indent: 0pxtext-transform: nonewhite-space: normalwidows: 2word-spacing: 0px-webkit-text-stroke-width: 0pxbackground-color: rgb(255, 255, 255)text-decoration-style: initialtext-decoration-color: initial">

</ignore_js_op>

一:收集候选地址

候选地址是或许可用于接收媒体以建立对等连接的<IP地址, 端口>对,它分四种类型。

| 类型 | 别名 | 如何传给对端 | 用法 |

| 主机候选项 | host | 信令服务器 | 从网卡中获取的本地传输地址,如果此地址位于NAT之后,则为内网地址 |

| 服务器反射候选项 | srflx | 信令服务器 | 从发送给Stun服务器的Binding检查中获取的传输地址。如果此地址位于NAT之后,则为最外层NAT的公网地址 |

| 对端反射候选项 | prflx | Stun Binding请求 | 从对端发送的Stun Binding请求获取的传输地址。这是一种在连接检查期间新发生的候选项 |

| 中继候选项 | relay | 信令服务器 | 媒体中继服务器的传输地址。通过使用TURN Allocate请求获取 |

具体到例子,以下是此阶段将至少能收集到的候选地址。为简单,不再写A的IP2、B的IP2的服务器反射地址。

| 别名 | 类型 | 值 |

| A Cand2 | srflx | 211.161.240.181(raddr: 192.168.1.105) |

| A Cand1 | host | 192.168.0.204 |

| B Cand3 | host | 192.168.0.181 |

二:交换候选地址

A通过信令服务器把A Cand2、A Cand1、B Cand3发向A。对端收到一个候选地址后会做什么?深入它之前让引入两种对象:P2PTransportChannel、Connection。

ICE代理用P2PTransportChannel管理通道(Component)上的网络传输。什么是通道?Webrtc有个概念叫轨道(Track),常见有视频轨、音频轨,而要发送一条轨道中数据,最多可能使用两个通道,分别是Rtp、Rtcp。肯定会有Rtp,Rtcp则可选。一个P2PTransportChannel对应一条通道,如果当前会话要同时处理音频、视频,每条轨道又都包括Rtp、Rtcp,那会话中就存在四个P2PTransportChannel对象。P2PTransportChannel用维护一张连接状态表来管理网络传输,表中一条记录对应一个Connection对象。这里让具体到A的视频Rtp对应的P2PTransportChannel,看它在收到B Cand1后,P2PTransportChannel会向连接状态表新增两条记录,即两个Connection。这时已到通道,地址须是ip:port对。

| 本地网卡地址(Port) | 对端地址 | 状态 |

| 192.168.1.105:60001 | 192.168.0.204:40001 | 未进行过Stun检查 |

| 172.16.40.6:60003 | 192.168.0.204:40001 | 未进行过Stun检查 |

此时A不知道该用哪个网卡IP才能把数据成功发向192.168.0.204,于是它只要在有可能的地址对就创建Connection。注意Connection只会基于网卡IP,即host,因为对发送源来说,host才可能是源,其它的只是中间转换出的地址,像srflx。当然,创建时会放弃明显不可能的<网卡地址, 对端地址>对,举个例子,网卡地址是ipv4,而对端地址是ipv6。

当收全B Cand2、B$Cand3,状态表中就有6条记录。

| 本地网卡地址 | 对端地址 | 状态 |

| 192.168.1.105:60001 | 192.168.0.204:40001 | 未进行过Stun检查 |

| 172.16.40.6:60003 | 192.168.0.204:40001 | 未进行过Stun检查 |

| 192.168.1.105:60001 | 11.92.14.8:50002 | 未进行过Stun检查 |

| 172.16.40.6:60003 | 11.92.14.8:50002 | 未进行过Stun检查 |

| 192.168.1.105:60001 | 192.168.0.181:40003 | 未进行过Stun检查 |

| 172.16.40.6:60003 | 192.168.0.181:40003 | 未进行过Stun检查 |

表中有一条、或多条、或没有,能够把A的视频Rtp数据发向B的视频Rtp通道,到底怎么个可能性就要执行接下的Stun检查。

三:STUN检查

在状态表新建一条记录,即一个Connection,很快就会在此Connection上进行Stun检查。Stun检查具体 *** 作是在此Connection上发Stun Binding请求。 由于要能支持Stun应答,每个ICE代理必须内置Stun服务器功能。 Stun检查具体步骤见下图。

<ignore_js_op style="word-wrap: break-wordcolor: rgb(68, 68, 68)font-family: Tahoma, Helvetica, SimSun, sans-seriffont-size: 14pxfont-style: normalfont-variant-ligatures: normalfont-variant-caps: normalfont-weight: normalletter-spacing: normalorphans: 2text-align: starttext-indent: 0pxtext-transform: nonewhite-space: normalwidows: 2word-spacing: 0px-webkit-text-stroke-width: 0pxbackground-color: rgb(255, 255, 255)text-decoration-style: initialtext-decoration-color: initial">

</ignore_js_op>

为什么说Stun检查会发现prflx候选项?假如A和Stun服务器之间连接状态不好,在它收到B发来的srflx(11.92.14.8)之后还没得出自个的srflx(211.161.240.181)。虽然A没得到自个的srflx,但这不妨碍对B的srflx这个候选地址进行Stun检查,于是会向11.92.14.8发Stun请求。B收到这个请求,从请求解析出211.161.240.181。虽然这个地址在值上等于A的srflx,但不是从信令服务器得到,而是来自对端的Stun请求。此时B就会以这个prflx向状态表新建Connection。

A在之后终于向Stun服务器拿到了自个的srflx,并通过信令服务器发向B。B发现这个srflx值对应的Connection已存在,就不会再创建了。

到此可得出个结论:两种原因会导致新建Connection,一是从信令服务器收到候选地址,二是Stun检查发现prflx。不同于从信令服务器得到地址而创建的Connection,Stun检查时创建的Connection一开始就基本能确定连接是畅通的。

四:选定候选地址,并启动媒体

P2PTransportChannel会维护连接状态表,并排序表中记录(SortConnectionsAndUpdateState)。排序指的是计算每条记录的连接“成本”,把成本最低的排在第一条。如何计算成本?这涉及到很多因素,比如发出Stun请求到收到应答经过了的时间,用时越少的“成本”自然会低些。

当A有视频Rtp数据要发送时,它检查状态表的第一条记录,如果判断出它的状态是发送就绪,就会用此Connection进行发送。否则直接放弃这个发送任务。 媒体模块在处理数据的采集、编码任务时,不用考虑候选地址方面进展怎样了,只是要到发送时才关注下,而即使不能发送也不会影响自个进度;同样,候选地址处理模块也不会关注媒体处理模块的进度。这正是之前写的一个结论:“除了主叫必须创建Offer才开始收集候选地址、被叫必须创建Answer才开始收集候选地址外,ICE代理是相互独立地处理媒体和候选地址”。

维护表任务包括新建、删除记录,以及修改记录中的状态字段。删除记录、修改状态都涉及到“长连接”。

五:长连接

为确保NAT映射和过滤规则不在媒体会话期间超时,ICE会不断通过使用中的候选项对发送Stun连接检查。具体到P2PTransportChannel,表现出来的是对状态表中所有记录隔段时间就要发送个Stun Binding请求。如果检测到本来是畅通的Connection上Stun应答超时了,那它就会更改该Connection状态,执行表排序时就有可能会向下掉,严重时会从状态表删除该记录。

一记录被删除后,如果之后那候选地址的连接又恢复了,则会基于该候选地址重新创建Connection。

六:ICE重新启动

分析长连接时,我们已能得出个结论,如果是网络拥堵或通断导致的状态表变化,P2PTransportChannel内部就能处理。但是,如果基地址发生改变,像一网卡被禁用,这就超出P2PTransportChannel可处理范围了,需重启ICE。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/yw/11910859.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-05-19
下一篇 2023-05-19

发表评论

登录后才能评论

评论列表(0条)

保存