im语音通话怎么搭建的？找哪家厂商比较好？

im语音通话一般都是通过用第三方im sdk来搭建才能实现的，im sdk你可以选择ZEGO即构，ZEGO 即时通讯提供50多种用户需要的APP内聊天功能，支持文字、、语音、视频、文件等多种类型消息传输，设立消息的优先级，保证重要消息最优先推送，保证所有消息必达。提供系统通知推送能力，助力产品运营；可针对自身业务场景，定制所需服务规格。

IETF的Sigtran协议是在IP网络中传送SCN信令协议的堆栈，称为Sigtran协议栈。它支持没有任何修改的SCN信令应用的标准原语接口，从而保证已有的SCN信令应用可以未经修改地使用，同时它利用标准的IP传送协议作为低层传送信令，通过增加协议自身的功能来满足SCN信令传送的要求。

图5　信令传送功能模型

图5所示是一个基于Sigtran协议的信令传送功能模型。其中信令网关终结电路交换网的信令，然后通过Sigtran将信令内容传送给媒体网关控制器处理，媒体网关控制器终结局间中继，并根据来自媒体网关控制器的控制指令的指示来控制中继。

No7信令适配层支持特定的原语，例如管理指示原语等，这些原语是特定的SCN信令协议所必需的。在IP网络中，Sigtran协议利用IP作为底层传送协议，用来传送SCN信令。它支持标准接口，从而不需要对现有的SCN信令进行任何修改，从而保证已有的SCN信令应用可以不必修改而直接使用。

依据Sigtran协议栈，一个用于No7信令网关的协议模型基本上可以分为信令应用层（如TUP、ISUP等）、信令适配层（如M2UA、M3UA等）和信令传输层（如SCTP），如图6所示。

图6　No7信令网关协议模型

（1）Q931：ISDN用户在网络接口第三层基本呼叫控制技术规范。

（2）QSIC：欧洲计算机制造者协会为ISDN制定的链路层协议。

（3）IUA：ISUP用户适配层，IUA是为在软交换网络中实现ISDN业务而开发的协议，是ISDNQ921/Q931用户适配层协议。

（4）MTP3：No7信令消息传递部分第3层。

（5）M2UA：MTP3的用户部分适配层，M2UA是MTP第二级用户的适配层协议，该协议允许信令网关向对等的IPSP（移动互联网服务、内容应用服务的直接提供者）传送MTP3消息，对No7信令网和IP网提供无缝的网管互通功能。

（6）TCAP：事物处理应用部分。

（7）SCCP：信令连接控制部分。

（8）ISUP：ISDN用户部分。

（9）TUP：电话用户。

（10）M3UA：MTP3的用户适配层，M3UA是MTP第三级用户的适配层协议，该协议允许信令网关向媒体网关控制器或IP数据库传送MTP3的用户信息（如ISUP/SCCP消息），对SS7信令网和IP网提供无缝的网管互通功能。

（11）SUA：SCCP用户适配层，SUA是SCCP用户的适配层协议，它的主要功能是适配传送SCCP的用户信息给IP数据库，提供SCCP的网管互通功能。

（12）SCTP：流控制传输协议，SCTP是面向连接的传输层协议，是新一代的通用IP传输协议，其基本功能是在SCTP用户之间提供可靠的基于消息的传输服务，该服务通过在SCTP两个端点之间建立的SCTP连接（称为SCTP偶联）实现。相对TCP等其他传输协议，它传输时延小，可避免某些大数据引起的阻塞，因此更适合传送对实时性和可靠性要求很高的电信网信令，该协议使得信令消息在一个基于IP的公共分组交换网上完成交换。

No7协议栈与Sigtran协议栈的对应关系如下。

为了实现软交换与现有的No7信令网呼叫连接控制的连接互通，SG首先需要终结No7信令链路，然后利用Sigtran协议将No7信令的呼叫连接控制消息的内容传递给软交换进行处理。由于软交换与SG的通信主要靠的是No7信令适配层协议，包括有M2UA、M2PA、M3UA等协议，No7协议栈与Sigtran协议栈的对应关系如图7所示。

图7　No7信令协议栈与Sigtran协议栈的对应关系

通常说的Sigtran协议主要指的是SCTP和No7信令适配子层，信令网关根据其实现的功能，No7信令适配层可以采用No7信令消息传递部分第二级用户适配层（M2UA）、消息传递部分第二级对等适配层（M2PA）、消息传递部分第三级用户适配层（M3UA）或信令连接控制部分用户适配层（SUA）等。公共的信令传送协议支持信令传送所需的公共且可靠的传送功能，它采用流控制传输协议（StreamControlTransmissionProtocol，SCTP）提供这些功能。

信令的基本传送过程是：首先，应用层的ISUP消息经过本地的No7协议栈，在SS7信令网中传输；到SG后，先经过其中的No7协议栈，到NIF，再经过M3UA/SCTP/IP，到IP网上传输；到达软交换设备时，先经过Sigtran协议栈，分解出ISUP消息。至此，相当于SP应用层中的ISUP信令透明地传送到了软交换的应用层，实现了No7信令网和IP网的互通。

Sigtran协议栈是No7信令网关软件系统的核心部分，用于实现No7信令与IP包之间的协议转换。可依据以上提出的协议模型，在原有No7信令系统的基础上增加信令网关特有的信令适配层和传输层的处理。根据系统功能可以将信令协议处理系统分为三个子系统：No7信令网接口子系统、协议处理子系统、IP网络接口子系统。No7信令网接口子系统主要完成信令网关与No7信令网的接口，实现与No7信令网的消息传送，属于协议模型中的信令应用层，如TUP、ISUP等。协议处理子系统实现No7信令在IP网上可靠高效传输，这是实现信令网关功能的关键技术，开发中必须完成协议模型中的信令适配层协议，包括M3UA、M2UA等协议以及传输层SCTP协议。IP网络接口模块实现信令网关与IP网络的接口，应能提供标准的TCP/IP协议的接口。

信令网关的协议栈结构如图8所示。

下面分别从信令网关的PSTN侧、IP侧的信令进行讨论。

1．PSTN侧的信令部分

作为SoftSwitch系统接入PSTN信令的部件，信令网关必须支持SS7。从信令网关的协议栈结构可以看出，为了支持各种类型的No7，信令网关在PSTN侧需要提供对各种类型的MTP1、MTP2、MTP3的支持，也就是说信令网关只要支持各种信令系统中相应于MTP1、MTP2和MTP3的规范部分。

2．IP侧的信令部分

在IP侧，信令网关必须支持图7所示的Sigtran协议栈，服从相应的IETFSigtran规范。SG对于No7信令网与IP网的互通所采用的协议是信令传送协议（Sigtran）。Sigtran是在IP网络中传统电路交换网SCN中信令协议的堆栈。在软交换的体系中，通过SG系统进行SCN侧No7信令和IP侧的Sigtran适配层协议的转换，实现No7信令在IP网的传送，从而达到Sigtran支持的标准原语接口，不需要对现有的SCN信令应用进行任何修改，从而保证已有的SCN信令应用可以不必修改而直接使用。

Sigtran协议栈包括SCTP协议与No7信令适配子层协议。

（1）公共的信令传输协议：它采用流控制传输协议（SCTP）提供这些功能。

SCTP即流控制传输协议，它是一个基于IP网的新的端到端传输控制协议，它最根本的目的是在IP网的基础上传输源于传统PSTN网上的信令数据，通过在无连接的IP网络上传送PSTN信令消息，从而可以在IP网上提供可靠的数据传输，它是一种新型的IP传送协议，与TCP、UDP处于同一层。SCTP通过确认方式，可以无差错、无重复地传送用户数据；根据通路的MTU（消息传输单元）限制进行用户数据的分段，并在多个流上保证用户消息的顺序递交；把多个用户的消息复用到SCTP的数据块中；利用SCTP偶联的机制来提供网络级的故障保证，同时SCTP还具有避免拥塞的特点，并能够避免遭受泛播和匿名的攻击。正是由于SCTP具有良好的安全性、可靠性和灵活性，以及它本身所具有的一些先进协议机制，如选择性确认、快速重传、无序递交、多宿主机制等，使得SCTP能够在一定程度上满足复杂网络环境下高性能传输的需求，这也给SCTP带来了更为广阔的应用空间。

SCTP协议使得信令消息在一个基于IP的公共分组交换网上完成交换，流量控制和差错控制被端到端地执行，通过使用一组“应用服务器进程”和“多归属节点”，使得有效性得到提高。这样，SCTP是可靠传输协议，SCTP的连接叫偶联。SCTP提供了两个端点间高可靠的冗余传输端口。

（2）No7信令适配层：该层支持特定的原语，这些原语是特定的SCN信令协议所必需的。SG根据其实现的功能，No7信令适配子层可以采用No7信令消息传递部分（MTP）第二级用户适配层（M2UA）、消息传递部分第二级对等适配层（M2PA）、消息传递部分第二级用户适配层（M3UA）、信令连接控制部分用户适配层（SUA）等，No7信令适配子层的适配层协议有以下几种。

①M2PA（MTPlevel2UserPeer-to-PeerAdaptation）。

②M2UA（MTPlevel2UserAdaptation）。

③M3UA（MTPlevel3UserAdaptation）。

④SUA（SCCPUserAdaptation）。

⑤IUA（ISDNUserAdaptation）。

根据No7信令与IP互通的不同实现方式，这些适配协议分别有不同的应用场合，下面对这些协议做详细的介绍。

协议模型的各层协议功能描述如下。

（1）M2PA协议的特点

M2PA协议可以用来在IP承载上传送No7信令的MTP3消息，该协议使用SCTP提供可靠传送、证实及避免拥塞等功能。M2PA的应用可以保证任何使用IP作为承载的信令节点均可以直接使用MTP3的信令消息处理功能和信令网管理功能。另外，它还利用SCTP协议提供的功能实现很多与MTP2相同的功能，下面是M2PA协议的特点。

①SG在TDM侧采用标准的No7信令信令协议（MTP1、MTP2、MTP3协议），在IP侧将MTP3及MTP3上层的信令封装在M2PA/SCTP协议中。另外，SG可以具备SCCP层功能，以及GT翻译功能。

②SG支持MTP3层协议，具备信令网管理功能，可以将SG与软交换机之间的IP信令链路状态信息传送给TDM交换机，也可以将SG与TDM交换机之间的TDM信令链路状态信息传送给软交换机。

③SG具备信令转接功能，支持No7信令消息在多个通过IP网络相连的SG之间转发。

④采用M2PA协议，从SG的协议栈来看，SG可完全被看作为介于TDM电话网和软交换网之间的STP（信令转接点），在完成物理连接的基础上，SG将信令链路的承载（MTP1层定义的标准）转换基于IP承载，将MTP2层定义帧结构转换为M2PA的帧结构，同时将SLC信令链路适配至一个或多个SCTP连接，同时M2PA必须保存各条No7信令链路至它的SCTP偶联和相应目的IP地址的对应表。

因此，可以说采用M2PA协议能够构建一个TDM信令链路与IP信令链路无缝连接的信令网，而SG是连接TDM信令链路与IP链路链路的STP，作为可选功能，SG可具备SCCP层功能，实现MAP消息在TDMSP与IPSP之间的传送。采用M2PA协议，SG和软交换机均需具备独立的信令点编码，SG只能采用信令转接点方式工作。

（2）M2UA协议特点

除了M2PA协议外，IETF还定义了MTP2用户适配层的协议，该协议也用来在SCTP上传送MTP2用户的信令消息。在这种情况下，M2UA协议的功能与M2PA协议相同。由于在应用M2UA协议时，在No7信令用户适配协议中引入了AS和ASP概念，因此在M2UA协议中还应当包括对AS和ASP的状态管理功能。M2UA协议的应用主要是在同一物理实体中既包含了信令网关（SG）功能，又包含了媒体网关（MG）功能。

M2UA协议的功能如下。

①支持MTP2和MTP3的边界接口原语。

②支持完整的MTP3消息处理和网络管理功能。

③支持SG与MGC之间的层管理模块间通信。

④支持SG及MGC之间激活的连接的管理。

M2UA协议的特点如下。

①SG必须具备MTP1和MTP2层协议、M2UA/SCTP/IP协议，软交换机必须具备MISUP/MTP3/M2UA/SCTP/IP协议，同时还必须支持MTP2与MTP3层之间的层间原语。

②由于SG不处理MTP3层协议，因此不具备信令网管理功能，不能将SG与软交换机之间的IP链路状态告诉TDM交换机，即TDM交换机与软交换机之间通过两个以上的SG相连，当一个SG与软交换机之间的SCP/IP链路故障时，无法通知TDM交换机将所有信令消息均倒换至另一个SG。

③由于SG不具备MTP3层功能，因此SG不可能具备SCCP功能。

④由于SG不需要具备信令点编码，在软交换机不采用多信令点编码的情况下，软交换网网元对信令点编码数量的需求较少。

⑤SG只能采用信令代理方式工作，并且一个SG仅能代理一个软交换机，而一个软交换机可由多个SG代理。

⑥当软交换机通过SG与TDM交换机通过直联信令链路相连时，软交换机可采用不同的SG作为代理，连接不同的TDM交换机；当一个软交换机通过多个SG与TDM交换机通过经STP组织的准直联信令链路相连时，STP将与之相连的多个SG视为一个SG，且多个SG与一对STP之间最多仅能够设置16条信令链路。

⑦从SG的协议栈上看，SG完全等同于一个软交换机在TDM与IP网络交界处设置的一个代理点，且仅代理MTP1和MTP2层的功能，SG将信令链路的承载（MTP1层定义的标准）转换基于IP承载，对信令消息进行MTP2层解封装后，将需要调用的MTP2与MTP3层之间的层间原语封装在M2UA消息包后，通过SCTP连接送至其所代理的软交换机，因此可以把SG和其所代理的软交换机看作是同一个信令点，且信令点编码在软交换机，SG不需具备信令点编码。

采用M2UA协议，完全可以看作IPSP（SS）将MTP1和MTP2层功能延伸至了位于TDM电话网和软交换网之间的SG，与TDM电话网互通信令，由SG负责完成MTP1和MTP2层功能，由IPSP（SS）负责完成MTP3以及MTP3上层功能；MTP3以及MTP3上层的信令消息适配在M2UA/SCTP协议中，在SG与IPSP（SS）之间的IP网络中传送。

（3）M3UA协议特点

M3UA（MTP3UserAdaptationLayer）协议是该体系中的适配协议之一，M3UA协议允许信令网关向媒体网关控制器或IP数据库传送MTP3的用户信息，对No7信令网和IP网提供无缝的互通功能，下面是M3UA协议的特点。

①SG必须具备MTP1、MTP2、MTP3层协议、M3UA/SCTP/IP协议，软交换机必须具备MISUP/M3UA/SCTP/IP协议，同时还必须支持MTP3与ISUP层之间的层间原语。

②当SG采用信令转接点方式工作时，M3UA所能够实现的功能与M2PA基本相同，只是由于M3UA在SG终结了MTP3层协议，信令消息不能在采用IP网络相连的SG之间转发。

③从SG的协议栈上看，表面上SG完全等同于一个软交换机在TDM与IP网络交界处设置的一个具备MTP1、MTP2、MTP3层协议代理点，但由于SG具备MTP3层协议处理的功能，因此SG既可以作为某个软交换机的代理，也可以作为STP为具备信令点编码的软交换机提供信令消息功能。

④当SG采用代理方式工作时，M3UA所能够实现的功能与M2UA基本相同，M3UA具有MTP3层功能，能够实现信令网管理功能。另外，由于SG具有MTP3层功能，因此SCCP功能也是SG的可选功能。

采用M3UA协议，SG既可以用作SS连接TDM信令网的代理，也可以用作连接TDM信令网的代理；几乎具备了M2PA和M3UA的所有优点，但其唯一的不足在于与M2PA相比，信令消息不能在IP网内经多个SG转发。

除了将MTP3用户部分的数据进行适配以在IP网络中传输外，M3UA还提供了与MTP3层相对应的部分信令网管理功能，即将MTP3中的管理原语映射为M3UA中的消息，并将其在SG（信令网关）的MTP3和软交换中的MTP3用户部分之间进行传输，从而实现从No7到IP网络中端到端的信令传输和管理。

M3UA在流控制传输协议和使用MTP3服务的应用之间提供一个接口，即对No7信令中的MTP3用户消息进行适配后使用SCTP协议在IP网中传输，使SS7的节点与IP网的节点可以互相传送MTP3用户消息。在IP网中，使用M3UA收发MTP3用户消息的节点称为应用服务器（AS），相当于SS7中的信令点，M3UA支持所有MTP3的用户，它对上层用户提供的原语和MTP3提供的原语一致，而底层使用SCTP在IP网上传输，M3UA和SCTP使IP网上的MTP3用户和SS7上相应的用户之间可以进行无缝的对等通信，使用M3UA协议的信令网关在组网时可以采用信令点代理或信令转接点方式，使用信令点代理方式组网时，信令网关与所联的IP网中的信令点使用相同的信令点码，如果需要为多个IP网节点服务，则信令网关要支持多信令点功能，使用信令转接点方式时，信令网关单独分配一个信令点码，可以为IP网内多个不同信令点码的节点服务。

M3UA协议可以用来支持在IP网络上对No7信令的MTP3用户消息的传送，MTP3用户消息可以是基于呼叫连接的ISUP/TUP消息，也可以是基于无连接应用的SCCP消息。此协议可以在信令网关与MGC或IP数据库节点之间使用，也可以在两个IP信令点之间使用。通过M3UA协议对MTP3用户消息的适配，MTP3用户消息可以在传统No7信令节点与IP信令点间进行传送。M3UA协议的应用也可以包括直联或准直联两种方式。

M3UA协议功能如下。

①支持所有的SS7MTP3用户部分的消息传送（如ISUP、SCCP、TUP等）。

②支持MTP3用户协议对等层的无缝操作。

③支持SCTP传输连接和会话管理。

④支持MGC的故障倒换和负荷分担。

⑤支持对管理实体的异步状态变化报告。

⑥M3UA带路由标签的用户消息的传送功能。

⑦M3UA层管理功能。

⑧IP网络中MTP3网间管理功能。

⑨支持SCTP连接管理功能。

⑩系统倒换切换时的协议保护。

协议层重要数据实时观察功能。

（4）M2PA、M2UA、M3UA协议的应用分析比较

通过对M2PA、M2UA、M3UA协议的分析可得以下结论。

①M2PA协议产生较早，其目的在于将传统的基于TDM的No7信令网完全改造为基于IP网络的No7信令网，因此M2PA具备较为强大的IP信令网组网能力，适用于利用IP网组建与传统No7信令网功能基本相同的信令网情况，但对于网络结构相对较为简单的软交换汇接网来说基本用不到，由于这种应用在实际组网中很少有机会应用，因此发展较为缓慢。

②M2PA协议是目前Sigtran协议栈中唯一一个能够组建IP信令网的协议。M2UA协议较为简单，M2UA协议降低了对SG处理能力的要求，但同时增加了对软交换机处理能力的要求，代理软交换机的SG与TDMSP/STP连接的所有信令链路，均需要在SS中配置，可以看作SS通过SG直接与SG所连接的所有TDMSP/STP直接相连；同时，信令网管理功能较差；因此M2PA协议适用于软交换机通过SG直接与少量的TDM交换机设置直联信令链路或与TDM交换网中少量STP设置信令链路的组网模式，而对于软交换机通过SG经STP与TDM交换机通过准直联信令链路相连的组网模式，则存在一定的缺陷。

③在采用M3UA协议的情况下，SG既可以工作在信令转接点模式，又可以工作在信令代理模式，在网络组织上具有较大的灵活性。工作在信令转接点方式时，具备M2PA协议几乎所有的优点，虽然不能够实现信令消息在IP网内经多个SG转接，但在不需要支持MAP、CAP协议的软交换汇接网上不需要此功能。由于SG的TDM侧的No7信令链路编号（SLC）与IP侧的IP信令链路（SCTP链路）没有一一对应关系，因此SG工作在信令转接点模式的情况下，软交换机与SG（此时SG可以被看作IPSTP）之间不再有16条信令链路的限制，即软交换机与SG之间的传送带宽不再成为“瓶颈”；在信令网管理方面，SG工作在信令转接点模式的情况下也不存在任何问题；同时SG支持类似于TDM交换网中的STP成对配置的组网模式，配对的SG之间可以设置C链路，提高了信令网络的安全可靠性；但对于SG工作在信令代理模式的情况下，虽然略优于M2UA，但相差不大。

（5）SUA协议的特点

SUA协议可以用来在IP网络上支持对No7信令SCCP用户消息的传送，SCCP的用户消息可以是TCAP消息，也可以是RANAP消息。这个协议可以在信令转接点与IP数据库节点之间使用，也可以在两个IP信令点之间使用，但其主要应用是针对非电路呼叫型业务的，协议的应用也可以包括信令中继和非中继方式两种模式。

SUA协议功能如下。

l支持No7用户部分的消息传送（如TCAP等）。

l支持SCCP无连接的业务。

l支持SCCP用户部分对等层的无缝操作。

l支持分布式的基于IP的信令节点。

IUA协议功能如下。

l支持Q921、Q931界面接口传输原语。

l支持SG与MGC之间的层管理模块间通信。

l支持SG及MGC之间激活的连接的管理。

l支持点对点方式及点对多点方式的通信。

SCTP协议功能如下。

lSCTP连接的建立和拆除。

l数据流的顺序发送。

l用户数据分段。

l确认和避免拥塞。

l块复用的组合与拆离功能。

lSCTP路径管理功能。

l消息的合法性确认功能。

l系统倒换切换时的协议保护。

l协议层重要数据实时观察功能。

lIP层接口功能。

没有信令服务器，各个WebRTC之间是没办法通信的。

传递媒体数据有两个信息，必须经过信令服务器进行交换

通过SDP来表示，如编解码器是什么？是否支持音频视频？编码方式是什么？等

这些信息是通过SDP协议描述出来，通过信令服务器中转的

两个WebRTC客户端会尽可能选择P2P进行连接，那么进行连接前是如何发现对方的？就是通过信令服务器。

首先将你所有网络相关信息传到信令服务器，服务器帮你交换到对端，对端拿到你的信息后，

若在同一局域网内，直接通过P2P传输；若不在，首先进行P2P穿越，看是否能打通，打通则传输，打不通则中转等。

还有一点也需要信令服务器进行传输，比如加入房间，离开房间，禁言等功能

在传输时，一般有两种协议 TCP和 UDP

底层协议使用 UDP主要用于流媒体传输（音频视频）还有文本，文字聊天等，但 UDP是不可靠传输，是可以丢包的，当然音频视频是可以丢包的，丢失一帧只会卡顿下，还可以继续工作。

但信令服务器不能丢失数据，所有的包必须保证到达，否则断开连接，所以信令服务器一般使用TCP可靠性传输。

websocket底层使用的就是 TCP协议， socketio 使用的也是TCP

在websocket官方中，是有三个服务器的，ROOM服务器（提供用户进出房间服务）、信令服务器、流媒体（中转）服务器

选用socketio 即不用单独写ROOM服务器，这里ROOM和信令是同一个服务器

socketio是一个基于Nodejs的库，在现有的Node Server上增加个socketio即可

在任何终端都可以引入socketio客户端的库，通过客户端的库就可以连接到 Nodejs中 socketio服务器上

这样就可以建立连接，然后就可以创建，加入房间，这样房间内的人就可以通信了

多个 sockeio可以串行通信。

   原生支持： iOS13开始，使用URLSessionWebSocketTask类可实现像发送HTTP请求一样的WebSocket功能。如果要对Web套接字（包括客户端和服务器支持）进行较低级别的控制，请查看Network框架： https://developerapplecom/documentation/network 。

一、Socket

    是对TCP/IP 协议的封装，本质并不是一个协议，是应用层与 TCP/IP 协议族通信的中间软件抽象层（类似于对底层的封装），它是一组接口，让你在使用的时候更方便操作。

二、WebSocket协议

    是HTML5下一种新的协议，也是基于TCP的一种网络协议，它实现了 浏览器/客户端 与 服务器 全双工(full-duplex)通信——连接成功以后允许服务器或客户端的任何一方主动发送信息给对方。WebSocket协议由两部分组成： 握手 和 数据传输 。Websocket是一个持久化的协议，只需要一次成功的HTTP握手，服务端会一直保留握手成功时的信息，直到客户端或服务端关闭请求。

    创建了WebSocket后，会有一个HTTP请求发送到服务器以发起连接。取得服务器响应后，建立的连接使用HTTP升级，从 HTTP协议 交换为 WebSocket协议 。WebSocket使用了自定义的协议，未加密的连接不再是 http:// ，而是 ws:// ，默认端口为 80 ；加密的连接也不是 https:// ，而是 wss:// ，默认端口为 443 。即，使用标准的HTTP服务器无法实现WebSocket，只有支持WebSocket协议的服务器才能正常工作。一旦WebSocket连接建立后，后续数据都以 帧序列 的形式传输。

    WebSocket协议的特点包括：

    （1）建立在 TCP 协议之上。

    （2）与 HTTP 协议有着良好的兼容性。握手阶段采用 HTTP 协议，默认端口也是80和443，因此握手时不容易屏蔽，能通过各种 HTTP 代理服务器。

（3）数据格式比较轻量，性能开销小，通信高效。如何体现通信高效？WebSocket通信格式没有HTTP协议那么多的固定报头，且不用重复建立连接。

（4）可以发送文本，也可以发送二进制数据。

（5）没有同源限制，客户端可以与任意服务器通信。（什么是同源限制？协议相同，域名相同，端口相同。目的是为了保证用户信息的安全，防止恶意的网站窃取数据。）

（6）协议标识符是ws（如果加密，则为wss），服务器网址就是 URL。

（7）WebSocket通信协议于2011年被IETF定为标准RFC 6455，WebSocket API被W3C定为标准。

WebSocket如何实现长链接 ？创建了WebSocket后，会有一个HTTP请求发送到服务器以发起连接。取得服务器响应后，建立的连接使用HTTP升级，从HTTP协议交换为WebSocket协议。只需要一次成功的HTTP握手，服务端会一直保留握手成功时的信息，直到客户端或服务端关闭请求。WebSocket之所以能持久连接原因是它运行在TCP协议上，TCP协议自身是长连接协议，所以WebSocket当然可以长连接啦。

WebSocket如何管理连接 ？RFC6455-55意见稿指明：WebSocket协议定义了Control Frame 控制帧。WebSocket的控制帧有： Close 、 Ping 、 Pong 。

Close帧 ：发起关闭请求；

Ping帧 ：通信发起方确认链路是否畅通的报文；

Pong帧 ：通信接收方回应链路是否畅通的报文。

WebSocket在建立连接之后，通信的基本数据帧格式如下图（来源RFC6455-52）没有Http协议那么多固定的报头，且不用重复建立连接，所以通信效率高：

WebSocket连接的生命周期：

CONNECTING ：使用Http发起请求，RFC6455-4（ https://toolsietforg/html/rfc6455#section-4 ）规定了Client和Server的报文格式。Server在响应时使用Http状态码是101（切换协议）。在握手时，WebSocket连接处于CONNECTING状态。

OPEN ：握手成功之后，进入OPEN状态。

CLOSING ：如果一方发起了CLOSE帧，那么便标志着WebSocket连接进入了CLOSING状态；

CLOSED ：当TCP连接关闭之后，那么WebSocet连接便进入了CLOSED状态。

三、WebRTC

    名称源自 网页实时通信 （Web Real-Time Communication）的缩写，是谷歌2010年以6820万美元收购Global IP Solutions公司而获得的一项技术，由Google、Mozilla和Opera等支持的、免费的开放式项目。通过简单的API为浏览器和移动应用程序提供跨平台的 音视频实时通信 （RTC：Real-Time Communications ）功能。WebRTC使得开发者在浏览器无需安装任何插件就可以实现音视频通信。

    WebRTC提供了跨平台的音视频核心技术，包括音视频的采集、编解码、网络传输、显示等功能，支持的平台：Windows、Linux、Mac、Android及iOS。RTCPeerConnection是用于进行WebRTC调用以流式传输视频和音频以及交换数据的API，WebRTC使用RTCPeerConnection(对等连接)在浏览器之间传递 流数据 ，但也需要一种协调通信和发送控制消息的机制，这一过程称为 信令 。信令处理过程需要客户端之间来回传递消息，这个过程在WebRTC里面是没有实现的，需要自己创建。即WebRTC未指定信令方法和协议，需要开发者确保使用安全协议。所有WebRTC组件都必须进行加密，即 WebRTC是安全的 （如何保证安全？）。WebRTC这种技术可以让开发者的精力集中在用户体验上而不是媒体流本身，因为API就会处理好媒体引擎的相关工作。

    WebRTC 10 的重点是提供给开发者更多对媒体、数据通道的控制。而根据此前的提案（见后面的提案连接）显示，下一版本的 WebRTC 将有可能使数据处理脱离主线程。使用 RTCDataChannels 传输数据，相比使用 WebSocket 会有更好的拥塞控制。（该段内容笔者未确认）

参考连接： http://wwwsohucom/a/275427719_458408

提案连接： https://wwww3org/2011/04/webrtc/wiki/images/5/5c/WebRTCWG-2018-06-19pdf

如何保证安全 ：当连通性检测完成后，WebRTC会开启 DTLS （Datagram TLS）握手，用于协商出SRTP中加密RTP包的 对称秘钥 。该过程称为DTLS-SRTP，保证了数据传输的安全性。

参考： https://imwebio/topic/5a4a6cb2a192c3b460fce37f

RTP/RTCP 和 SRTP/SRTCP协议是什么？参考： https://blogcsdnnet/thinkerleo1997/article/details/80233530

基本概念：

SDP ： 即会话描述协议（Session Description Protocol ），主要保存当前会话的媒体和传输信息，其中媒体信息包括 媒体类型 、 传输协议 、 媒体格式 等，传输信息包括媒体的远程 地址信息 、 带宽 等；它由多行KV格式的文本信息组成，具体可参考这里（ https://toolsietforg/pdf/draft-nandakumar-rtcweb-sdp-08pdf ）。WebRTC通过 信令 建立一个SDP握手的过程，只有通过SDP握手，双方才知道对方的信息，这是建立p2p通道的基础。

Offer ： 通信的发起方对自己的sdp描述

Answer ： 通信的接收方对自己的sdp描述

信令 ：协商通信过程，传递基本的数据信息，其中包括SDP描述信息、会话控制信息（节点加入、退出及各类的业务控制信息等）、网络信息、错误信息等。是指控制建立连接和断开连接的状态的数据。在建立连接之前，信令必须发生在 带外 （通过服务器），但一旦建立连接，就可以通过已经建立的通道发送更新信令（如挂断）。（这里要了解一下什么叫“带外（OOB：Out-Of-Band）”，： https://baikebaiducom/item/out-of-band/15801641fr=aladdin ）

OOB概述 ：传输层协议使用 带外数据 （out-of-band，OOB）来发送一些重要的数据，如果通信一方有重要的数据需要通知对方时，协议能够将这些数据快速地发送到对方。为了发送这些数据，协议一般不使用与 普通数据 相同的通道，而是使用另外的通道。linux系统的套接字机制支持低层协议发送和接受带外数据。但是TCP协议没有真正意义上的带外数据。为了发送重要协议，TCP提供了一种称为 紧急模式 （urgent mode）的机制。TCP协议在数据段中设置 URG 位，表示进入紧急模式。接收方可以对紧急模式采取特殊的处理。很容易看出来，这种方式数据不容易被阻塞，并且可以通过在我们的服务器端程序里面捕捉 SIGURG 信号来及时接受数据。

信令通道 ：与服务端建立连接和断开连接的通道，对于WebRTC而言就是信令通道。

STUN 服务器：是用来取外网地址的。

TURN 服务器：是在P2P失败时进行转发的，中继转发。

STUN 和 TURN 服务器的作用主要处理打洞与转发，配合完成 ICE协议 。

ICE ：Interactive Connectivity Establishment，交互式连接建立。

WebRTC通信

基于WebRTC的点对点音视频通信流程如下：

1）客户端A初始化本地音视频设备，创建一个用于Offer的SDP对象，该对象中保存当前音视频的相关信息；

2）客户端A通过信令服务器将SDP信息发送给客户端B；

3）客户端B接收到A的SDP信息后保存，初始化本地音视频设备并创建用于Answer的SDP对象；

4）客户端B通过信令服务器将SDP信息发送给客户端A；

5）客户端A、B通过交换SDP等信息，建立P2P通道进行音视频传输；

示意图如下图所示：

WebRTC ICE（交互式连接建立）(ICE：Interactive Connectivity Establishment)

    以下是呼叫信令期间发生的消息交换的高级过程，即： WebRTC 信令交互流程图 ：

开始

##关键词

--[SOMETHING]-->：表示从主叫方发送给被叫方的“SOMETHING”类型的消息。另一解释是： 主叫方所要执行操作 。

<--[SOMETHING]--：表示从被叫方发送给主叫方的“SOMETHING”类型的消息。另一解释是： 被叫方所要执行的操作 。

SS (Signal Service)：通过服务器发送的信息（通过BCM 服务器发送的信息）

DC (Data Channel)：通过WebRTC 数据通道 发送的消息

### Message Exchange / State Flow Overview （消息交换/状态流概述）

|          Caller（主叫方）          |          Callee（被叫方）    |

+----------------------------+-------------------------+

开始拨出电话：`handleOutgoingCall`

                        --[SSCallOffer]-->

…并开始生成iceCandidate候选，先保存在本地。iceCandidate里面包含了SDP、公网地址、用来标识当前ice中流媒体的id(sdpMid)，这个公网地址是由STUN、TURN Server发过来的。

当生成iceCandidate候选后，将会调用方法`handleLocalAddedIceCandidate` ，并把这些iceCandidate保存起来。

                                                    被叫方收到来电，通过 `handleReceivedOffer` 发送呼叫应答

                                                    <--[SSCallAnswer]--

                                                    1 开始生成iceCandidate候选。

                                                    2 立即通过`handleLocalAddedIceCandidate` 将它们发送给主叫方。

                                                    <--[SSICEUpdate]-- (多次发送)

主叫方收到应答后调用方法: `handleReceivedAnswer`，接着发送所有前面保存的iceCandidate候选 (在此之后生成的iceCandidate候选会立即发送)

--[SSICEUpdates]--> (多次发送)

完成交换iceCandidate候选后…（此时表示双方身份已确认，接下来会通过P2P通道建立音视频会话，这里会涉及NAT技术，有可能失失败。如果失败，主叫方会一直显示呼叫中，被叫方不会显示任何界面）双方都调用方法: `handleIceConnected`

显示远程铃声用户界面

1连接到提供的数据通道

2显示来电界面

3如果被叫人接听电话

4发送连接消息

                                                    <--[DCConnectedMesage]--

接收到的连接消息后显示呼叫已连接。

主叫方挂断（被叫方同样可以挂断）调用方法：

--[DCHangup]-->

--[SSHangup]-->

结束

上面的消息交换可以整理为如下的简化版的WebRTC建立连接过程：

1）主叫方通过 createOffer 生成 SDP 描述

2）主叫方通过 setLocalDescription，设置本地的描述信息

3）主叫方将 offer SDP 发送给被叫方

4）被叫方通过 setRemoteDescription，设置远端的描述信息

5）被叫方通过 createAnswer 创建出自己的 SDP 描述

6）被叫方通过 setLocalDescription，设置本地的描述信息

7）被叫方将 anwser SDP 发送给主叫方

8）主叫方通过 setRemoteDescription，设置远端的描述信息。

只有通过 SDP握手 ，双方才知道对方的信息，这是建立p2p通道的基础。 通过SDP握手后，客户端之间就会建立起一个点对点的直接通讯通道。但是由于我们所处的网络环境错综复杂，用户可能处在私有内网内，使用p2p传输时，将会遇到 NAT (网络地址转换)以及防火墙等阻碍。这个时候我们就需要在SDP握手时，通过STUN/TURN/ICE相关 NAT穿透技术 (也有称为 打洞 或 穿墙 技术)来保障p2p链接的建立。

WebRTC的视频部分 ，包含采集、编解码(I420/VP8)、加密、媒体文件、图像处理、显示、网络传输与流控(RTP/RTCP)等功能。

    视频采集支持多种媒体类型，比如I420、YUY2、RGB、UYUY等，并可以进行帧大小和帧率控制。

    WebRTC采用I420/VP8编解码技术。VP8是Google收购ON2后的开源实现，并且也用在WebM项目中。VP8能以更少的数据提供更高质量的视频，特别适合视频会议这样的需求。

    视频加密是WebRTC的video_engine一部分，相当于视频应用层面的功能，给点对点的视频双方提供了数据上的安全保证，可以防止在Web上视频数据的泄漏。

    视频加密在发送端和接收端进行加解密视频数据，密钥由视频双方协商，代价是会影响视频数据处理的性能；也可以不使用视频加密功能，这样在性能上会好些。

视频加密的数据源可能是原始的数据流，也可能是编码后的数据流。估计是编码后的数据流，这样加密代价会小一些，需要进一步研究。

WebRTC的音频部分 ，包含设备、编解码(iLIBC/iSAC/G722/PCM16/RED/AVT、NetEQ)、加密、声音文件、声音处理、声音输出、音量控制、音视频同步、网络传输与流控(RTP/RTCP)等功能。

    WebRTC采用iLIBC/iSAC/G722/PCM16/RED/AVT编解码技术。

    WebRTC还提供NetEQ功能---抖动缓冲器及丢包补偿模块，能够提高音质，并把延迟减至最小。

    另外一个核心功能是基于语音会议的混音处理。

    声音处理针对音频数据进行处理，包括回声消除(AEC)、AECM(AEC Mobile)、自动增益(AGC)、降噪(NS)、静音检测(VAD)处理等功能，用来提升声音质量。

丢包补偿原理是什么？

自动增益（AGC：Automatic Gain Control）概念？

TCP协议 ：属于传输层，是可靠的、面向连接的。主要解决如何在IP层之上可靠地传递数据包，使得网络上接收端收到发送端所发出的所有包，并且顺序与发送顺序一致。TCP连接的建立依靠“三次握手”，而释放则需要“四次握手”。

IP协议 ：属于网络层，主要解决 网络路由和寻址 问题。

Http协议 ：属于应用层协议，一个简单的请求-响应协议，是一种无状态、非持久的协议，是被动性的，也就是只能客户端发起。服务端不保留上一次与客户端交互时的任何状态，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁。HTTP的长连接和短连接本质上是TCP长连接和短连接。HTTP11支持keep-alive。

Http与WebSocket区别与联系

（1）Http与WebSocket是两个完全不同的协议，都是基于TCP的。两者唯一的联系是WebSocket利用Http进行握手；具体说明请看：RFC6455-17( https://toolsietforg/html/rfc6455#section-55 )

（2）WS默认也使用80端口；WSS默认也使用443端口。

（3）Http协议局限性一大堆，比如明文传输、无法保证信息完整性、没有身份验证等。而WebSocket的出现则是为了解决Http协议只能由Client发起通信请求的问题。WebSocket是 全双工通信 。

（4）HTTP是运行在TCP协议传输层上的应用协议，而WebSocket是通过HTTP协议协商如何连接，然后独立运行在TCP协议传输层上的应用协议。

    WebSocket仅仅是利用了HTTP协议做连接请求。WebSocket相当于一个简化版的TCP传输子层（实际上WebSocket也是应用层协议）。WebSocket之所以能持久连接原因是它运行在TCP协议上，TCP协议自身是长连接协议，所以WebSocket当然可以长连接啦。如果你要问为什么HTTP不是长连接，原因是早期的HTTP在发起每个请求，响应完成后就会关闭Socket。但是后来加了多路复用KeepAlive协议后HTTP协议已经可以实现长连接了，可以处理长连接事务了。至于添加WebSocket特性，是为了更好、更灵活，轻量的与服务器通讯。因为WebSocket提供了简单的消息规范，可以更快的适应长连接的环境，其实现在HTTP协议自身就可以做，但是不太轻便，因为HTTP是一种无状态、非持久的协议，是被动性的，也就是只能客户端发起。服务端不保留上一次与客户端交互时的任何状态，每次都要重新传输 identity info （鉴别信息），来告诉服务端你是谁，每次请求和应答都带有完整的Http头，占用网络传输带宽，增加了每次传输的数据量。为什么HTML4不支持WebSocket？原因是WebSocket的协商机制HTML4底层API没有实现。

WebSocket与Socket是没什么关系的

WebSocket协议 和 Http协议： 都是基于TCP的，所以他们都是可靠的协议，是在应用层。

Socket： 是对TCP/IP 协议的封装，本质并不是一个协议，是应用层与 TCP/IP 协议族通信的中间软件抽象层（类似于对底层的封装），它是一组接口，让你在使用的时候更方便操作。

WebSocket与WebRTC(Web Real-Time Communication)是什么关系？

WebSocket： 是WebRTC的基础，为WebRTC负责客服端发现和数据转发。

TCP协议 ：参考 https://blogcsdnnet/Awille/article/details/79748193

SocketRocket ：Facebook的开源框架

WebRTC开发和VoIP开发之间有什么区别与联系？

待完善知识点：WebRTC移动端兼容性检测，如何配置MediaStreamConstraints， 信令(iceCandidate, sessionDescription)传输方式的选择，iceCandidate和sessionDescription设置的先后顺序，STUN和TURN的概念，如何实现截图及录制视频及上传和视频功能，如何高效跟踪错误？

WebRTC拥塞控制和码率调节策略是怎么样的？在弱网环境下如何保证图像不失真？

猜：好像是改RTCRtpEncodingParameters这个类里的ssrc参数。是改采样频率？

参考资料：

WebRTC百科： https://baikebaiducom/item/WebRTC/5522744fr=aladdin

WebRTC基础知识： https://webrtcorgcn/category/basic/

GoogleWebRTC-pod安装文档：https:// cocoapodsorg/pods/GoogleWebRTC

GoogleWebRTC-iOS官网： https://webrtcorg/native-code/ios/