webrtc客户端测试和arm平台测试（待补充）

思而后行之

已于 2024-06-20 11:30:14 修改

阅读量425

点赞数 3

分类专栏：知识点总结汇总文章标签： webrtc

于 2024-06-04 10:08:14 首次发布

本文链接：https://blog.csdn.net/GeiGe123/article/details/139434706

版权

知识点总结汇总专栏收录该内容

29 篇文章 0 订阅

订阅专栏

前面的话

优秀的设计超越了纯粹的功能性，它还能触及人们的心灵
—计算机科学家Donald Knuth

一、关于API的使用研究

二、遇到的一些问题

1、snd_write Broken pipe

写音频数据到缓存不及时导致，codec没有数据可以播放。

默认编译出来的 libwebrtc.a 库，使用的音频编码率是 48000，修改成 16k或者8k，就没有这个问题了。
alsa总结

三、一些基础概念

1、jsep 协议

jsep协议在webrtc中是由目录pc中的代码实现。

引用一段话来说明jsep协议是什么东西

JSEP（JavaScript Session Establishment Protocol）协议是 WebRTC（Web Real-Time Communication）标准的重要组成部分，它负责在 WebRTC 会话中建立和管理媒体会话。
JSEP 协议规定了在 WebRTC 会话中交换信令消息的格式和过程，这些信令消息包括 SDP（Session Description Protocol）、候选地址和 ICE（Interactive Connectivity Establishment）候选。
JSEP 协议的工作流程如下：
创建会话（SDP）：发起方首先创建会话描述（SDP），SDP 描述了会话的媒体属性，例如媒体类型、编解码器、分辨率等。
发送 offer ：发起方将 SDP 描述封装在 offer 消息中，并发送给接收方。
接收 offer ：接收方收到 offer 消息后，解析 SDP 描述，并决定是否接受会话。
创建 answer ：如果接收方接受会话，则创建 answer 消息，answer 消息中包含了接收方的 SDP 描述。
发送 answer ：接收方将 answer 消息发送给发起方。
交换候选地址：双方交换 ICE 候选地址，以便建立媒体连接。
建立媒体连接：双方通过 ICE 候选地址建立媒体连接，并开始交换媒体数据。

文字来自 @细说JSEP协议：会议通信中的“超级英雄”

JSEP 协议解读
 玩转 WebRTC 通信：一文读懂 SDP 协议

2、ICE、STUN和TURN的功能

ICE是一个框架，用于选择最优的网络路径进行媒体流传输。
STUN（Session Traversal Utilities for NAT）协议帮助客户端发现其公网地址。
TURN（Traversal Using Relays around NAT）协议则允许媒体流通过中继服务器传输，以应对直接通信受阻的情况。

1）NAT的一些说明

网络地址转换技术NAT——主要用于实现位于内部网络的主机访问外部网络的功能。
当局域网内的主机需要访问外部网络时，通过NAT技术可以将其私网地址转换为公网地址，并且多个私网用户可以共用一个公网地址，这样既可保证网络互通，又节省了公网地址。

对于一包网络数据包，通常是这样的，
在这里插入图片描述
NAT的作用就是将IP包头内的IP地址替换掉。

一般在公网和私网（局域网）之间会有一个网关。
当收到的报文源地址为私网地址、目的地址为公网地址时，说明是私网想网公网网络设备发送数据，NAT会将源私网地址转换成一个公网地址。这样公网目的地就能够收到报文，并做出响应。

网络地址转换—NAT——总结

3、SDP协议说明

4、信令协议的选择

1）、tcp
2）、websocket
3）、sip
支持传统电话网络互操作。

5、多方通信以及3种方案

WebRTC 本身提供的是 1 对 1 的通信模型，在 STUN/TURN 的辅助下，如果能实现 NAT 穿越，那么两个浏览器是可以直接进行媒体数据交换的；如果不能实现 NAT 穿越，那么只能通过 TURN 服务器进行数据转发的方式实现通信。

在 1 对 1 通信中，WebRTC 首先尝试两个终端之间是否可以通过 P2P 直接进行通信，如果无法直接通信的话，则会通过 STUN/TURN 服务器进行中转。

服务是否可以类比为对端客户端？

名称	描述	特点
Mesh 方案	每个客户端之间都直接通信	超过 4 个人，问题比较大
MCU 方案	接收每个客户端的推流，解码、混流、编码，转发给每个人除了自己	对CPU资源要求很高，对媒体的二次处理导致延时
SFU 方案	接收每个客户端的推流，直接转发给除自己外的其他人	对 CPU 资源消耗很小，降低延迟，提高实时性，灵活	Simulcast 模式 SVC 模式