由WebRTC谈起

IP电话是指基于IP网络来实现语音通信的一种通信方式。而IP网络是通过网络交换机、路由器、通信服务器等进行数据转发和传输的，IP电话正是依托这些设备进行语音通信的。因此，在正常情况下，IP电话需要连接到服务器才能进行语音通信。服务器不仅提供数据转发和传输的功能，还负责将数据包转换为语音信号，确保通信顺畅。但是，也有一些IP电话支持STUN和ICE协议，能够在防火墙或NAT路由器的条件下完成语音通信。这样，IP电话就可以“脱离”服务器进行使用。STUN协议通过向外部服务器发送请求，获得外网IP地址及端口，改善了UDP在对称NAT下的无法穿越。ICE则可以在客户端及中间节点的配合下，实现P2P及中继等多种传输方式的自主选择。因此，只有支持STUN和ICE协议的IP电话，才能够在脱离服务器的情况下正常使用。值得注意的是，即使采用了STUN和ICE协议，IP电话也需要正确设置防火墙、端口映射等参数，以便语音数据能够正确传递。同时，网络环境也会影响通话质量，需要确认带宽、延迟、丢包率等参数是否符合要求。因此，在实际使用中，脱离服务器的IP电话需要有技术支持人员进行调试和支持才能保证语音通信的质量。

浏览器本身不支持点对点建立信道进行通信，需通过服务器进行中转。因此浏览器之间一次通信需通过两段信道，通信效率同时受制于两段信道宽度，因此并不适合数据流的传输。

WebRTC是浏览器实时通信 RTC 的提供 JS 接口， JS 接口通过信令建立浏览器点对点(peer-to-peer,P2P)的信道，信道可发送任何数据并无需经过服务器。

WebRTC提供三个API

WebRTC使用 RTCPeerConnection 在浏览器之间传递流数据，此流数据通道是P2P的，无需服务器中转。但并不意味着能抛弃服务器，仍需服务器为传递信令(signaling)来建立信道。WebRTC没有定义用于建立信道的信令协议，信令并不是 RTCPeerConnection API 的一部分。

既然没有定义信令(signaling)的协议，可选择任意方式（如AJAX、WebSocket）任意协议（如SIP、XMPP）来传递信令，建立信道。

需要信令来交换信息分为：

通过服务器建立信道

WebRTC提供浏览器之间P2P信道进行数据传输，但建立这个信道必须有服务器的参与。

WebRTC需服务器提供：

NAT/防火墙穿越技术

在处于使用NAT设备的私有TCP/IP网络中的主机之间建立连接时需使用NAT穿越。NAT的行为是非标准化的，穿越技术大多使用公共服务器，使全球任何地方都能访问得到IP地址，在 RTCPeerConnection 中实用ICE框架来保证 RTCPeerConnection 实现NAT穿越。

ICE

ICE(Interactive Connectivity Establishment， 综合性NAT穿越技术)框架整合各种NAT穿越技术如STUN、TURN(Traversal Using Relay NAT，中继NAT实现的穿透)，ICE先使用STUN尝试建立一个基于UDP的连接，失败后实用TCP(先尝试>Stun Server是开源的coTurn穿透服务器，Signal Server是开源的Apache Active MQ。

Signal Server用的是开源的Apache ActiveMQ，网上有很多花里胡哨的方法，这个是简单能搭建成功的过程， 搭建过程 。

穿透服务器用的是开源的coturn， 搭建过程

SDP交换
根据MQTT协议订阅发布机制：
订阅同一个主题：（实现接收消息）
发布同一个主题：（实现发布消息）

对于每一个客户端来说唯一标示是ClientId，客户端发布消息时设置的主题也是ClientId

1、客户端连接到ActiveMQ服务器

这里的ClientId，就是在ActiveMQ服务端添加的

这里主要是连接到ActiveMQ的流程

首先，呼叫方initCall，主要作用是创建PeerConnection对象，设备，将音视频数据封装成MediaStream添加到然后打开本地音视频PeerConnection中，显示呼叫页面。
然后呼叫方startCall，主要作用是CreateOffer,SendOffer，所以要发布Topic:呼叫方Message;
假如ClientA呼叫ClientB，首先ClientA订阅主题ClientB，然后ClientB订阅主题ClientA。

Client A给Client B发送消息时，发布主题Client_A_ID和Message。
Client B给Client A发送消息时，发布主题Client_B_ID和Message。

zjf001连接到服务器
根据前面文章，看一下基本流程

在不同的网络环境(带有摄像头/麦克风多媒体设备)中，为两个浏览器实现点对点实时视频/语音通信有什么困难

1、了解对方的媒体格式、支持的最大分辨率和其他媒体信息？

2、要了解彼此的网络，就有可能找到一条通信链路？

3、两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢
为了保证两端都有正确的编码和解码，最简单的方法就是取它们的交集H264

注:有一种特殊的协议叫做Session Description protocol (SDP)，可以用来描述上述信息 。

在webrtc中，参与视频通信的双方必须首先交换SDP信息，这样双方才能了解基本的SDP交换过程。
同样，在复杂的网络环境中，要在两端之间建立连接，必须有一个双方都可以访问的链路。
从图中可以看出，他们可以使用公用网段192沟通。

在web brtc通信过程中，这些与网络相关的信息也必须进行交换，以找到共同的交集。这个过程也被称为“网络协商”。
两个终端还没有建立连接时,如何交换“媒体信息”和“网络信息”呢

此时，所谓信号服务器信号服务器应该出现:
如上图所示,两个浏览器可以抽象的上层一层信令服务器(可以是一个或多个,根据实际的应用程序中,如果两个浏览器可以访问公共网络环境,如公共如果没有公共网络环境中,您可以设置一组服务器两端,即信号服务器A和信号服务器B，但这两套信令服务器必须能够相互通信)，在信令服务器的帮助下，可以实现上述SDP信息和网络信息的交换。
交换SDP的过程大致如图所示:
1 Amy(假设一个人的名字)通过setLocalDescription方法保存自己的SDP信息，然后通过offer方法发送给信令服务器。

2 信息服务器将Amy的SDP转发给另一端的Bob(另一个虚构的名字)，Bob将首先调用setremotedescription来保存Amy的SDP。

3然后Bob调用setLocalDescription方法来保存他的SDP，然后使用answer方法通过信令服务器将他的SDP发送给Amy

4 Amy收到Bob的SDP后，调用setRemoteDescription进行保存，双方完成SDP交换，找到交集。如果他们能达成协议，他们就可以建立一个p2p连接并开始通信。
但现实往往是残酷的。在中国的网络环境下，据统计，至少有一半的网络不能直接连接。我个人认为根本原因是:在互联网发展的早期，绝大多数IP4地址资源都被国外所占据。当轮到中国等发展中国家使用IP地址时，大多数计算机没有公网IP地址，只能通过路由器和交换机进行NAT转换，相当一部分NAT是对称的。基本上，没有办法播放它。在这种情况下，您只能使用前一节提到的转向服务器进行转移。此外，在视频对话框中，通常会有房间(或组)的概念，用来隔离一些服务。这部分逻辑也在信号服务器中实现。对端、信令服务器、stun/转接服务器后，整个1对1实时视频通信顺序图如下:
主要流程如下:

1 双方首先调用getUserMedia打开本地摄像头

2 向信令服务器发送apply_join请求以加入房间

3信令服务器通知我成功加入(joined)，同时向其他人广播加入消息(other_joined)

4 第二个端开始创建peerConnection连接

5 PeerB创建报价，同时将SDP保存到本地机器(setLocalDescription)，并通过信令服务器将SDP传递给peerA

6 在setLocalDescription之后，PeerB将异步触发“候选网络链接”的集合，这大致决定了它自己所有的NAT映射通过Stun退出。如果Stun返回的NAT是“对称的”，它将基本上无法穿透。再次通过Turn得到中继应答地址，并通过信令服务器将网络候选链接信息发送给peerA(即:启动网络协商)

7 peerA收到peerB的SDP后，开始响应(createAnswer)，仍然通过信令服务器将SDP发送给peerB

8 同时，peerA也会开始收集网络候选链路，并通过信令服务器(即网络协商)将自己的网络信息发送给peerB。

通过这种方式，peerA和peerB相互交换了媒体信息和网络信息。如果他们能达成一致(即找到交叉点)，他们就能开始沟通。

注：为了更好的体验，将内容复制到工具中效果才好

#coturn服务器配置

## *** 作系统：建议使用ubuntu16+

##安装步骤：

以下安装以ubuntu16为例

### 安装软件包

apt update

apt install coturn

### 配置coturn服务器

#### 复制DTLS、TLS支持的证书文件（目录中已经有相应的证书）

cp /usr/share/coturn/examples/etc/turn_server_certpem /etc/turn_server_certpem

cp /usr/share/coturn/examples/etc/turn_server_pkeypem /etc/turn_server_pkeypem

#### 编辑/etc/turnserverconf文件

listening-device=eth0 #网卡

listening-port=3478 #对外服务的商品，需要在防火墙、云服务器安全组放通，协议为UDP/TCP，出入站都需要

listening-ip=127001 #内网地址

tls-listening-port=5349 #备用端口

listening-ip=1721704 #局域网地址

relay-ip=1721704 #局域网地址

external-ip=8101870 #外网地址

lt-cred-mech

server-name=stunxxxcn #域名

realm=stunxxxcn #域名

min-port=50001 #穿透需要用到的开始端口 需要在防火墙，云服务器安全组中放通

max-port=50009 #穿透需要用到的结束端口

user=test:test #用户名:密码 测试或者客户端接入时需要用到

userdb=/var/db/turndb #数据文件的位置，如果没有该文件，启动会有错误提示

cert=/etc/turn_server_certpem #密钥相关 上面步骤准备的

pkey=/etc/turn_server_pkeypem #密钥相关 上面步骤准备的

no-stdout-log

log-file=/var/tmp/turnlog #日志文件

pidfile="/var/run/turnserverpid" #pid文件位置

no-stun #不使用stun服务 主要用于测试turn中继方式时来关闭stun  更多类容可以参考配置文件自带的说明

### 编辑/etc/default/coturn文件

默认是不需要改的，但还是检查一下

TURNSERVER_ENABLED=1

## 安装完成，重启服务

service coturn restart

## 端口放通

参考各系统、服务器，不赘述

## 测试

使用自带工具

turnutils_uclient ip或者域名 -u 用户名 -w 密码

## 客户端使用

iceServers: [{

                'urls': 'stun:stunxxxxcn:3478',

                'credential': "test",

                'username': "test"

            }

            ,{

                'urls': 'turn:stunxxxxcn:3478',

                'credential': "test",

                'username': "test"

            }];

---