WebRtc-Freeswitch 搭建视频通话

简介

WebRTC

网页实时通信（Web Real-Time Communication），由google发布的一版开源项目，

目的主要是让Web开发者能够基于浏览器（）轻易快捷开发出丰富的实

时多媒体应用，而无需下载安装任何插件。使用支持webrtc的浏览器提供的接口，可以实

现对视频的采集、编码、显示、传输。目前WebRTC支持HTML5和JavaScript

WebRTC架构图

Web开发者只关注”The web” 层，即调用浏览器提供的javascript接口；从图中可以看

出WebRTC传输使用SRTP协议，NAT穿越使用的是ICE+STUN+TURN

[参考1]

JsSIP

提供了一个兼容WebRTC的JS SIP库；本文中使用的是JsSIP的一个Demo作为视

频通话的客户端。

Freeswitch

Freeswitch是一个CC++实现的开源的电话软交换平台，作为服务端在VOIP中应用比

较广泛。Freeswitch从版本1.4.4完全支持Webrtc。本文中使用Freeswitch(版本1.4.18)作为

视频通话的服务端，包含了SIP服务器、STUN服务器、视频转发服务器等。

本文实现场景

使用Freeswitch提供的默认账号，两个用户在不同的计算机上登录；通过拨号的方式双

发可以进行视频通话。

安装

JsSIP

JsSip 实现是嵌入在Html页面中，搭建一个页面服务器，然后把相关的文件拷贝到根

目录下；使用浏览器访问即可。本文中使用IIS作为网页服务器，Firefox浏览器测试

从截图中可以看出，需要一个用户名和密码；Sip的URL和WS(WebSocket)URL

Freeswitch

本文搭建的环境是在虚拟机上实现安装linux，版本是centos6；

安装过程保证能够连接外网，需要下载安装包

获取Freeswitch源码

git clone /stash/scm/fs/

转到Freeswitch目录下

./ –j

./configure –C –prefix=/usr/local/freeswitch

make

make install

安装声音插件

make sounds-install

make moh-install

注：

1. 过程中需要的一些库，系统没有提供，导致编译失败；使用yum install的方法安装

2. 可已通过 配置那些模块一起编译；opus没有编译过，在此文件注释掉

了

3. 如果Freeswitch中的某个模块出现连接错误，可以clean后重新make试一下

修改配置

(1)修改文件变量(黑色部分为添加的项)

(2) 修改配置文件conf/sip_profiles/， 打开

中去掉ws-binding 5066 的注释

(3)关闭linux的防火墙(如不关闭客户端可能会有访问拒绝错误)

service iptables stop

呼叫

Freeswitc默认设置了20个用户(用户名1000-1019) 密码：1234；使用默认用户测试

环境：

ClientA: PC端使用虚拟摄像头播放一段视频，用户名1012

ClientB: 笔记本，使用摄像头采集实时视频 用户名1011

Freeswitch – Sip IP:192.168.12.244:5060

Freeswitch – WS URL 192.168.12.244:5066

ClientA和ClientB可以通过音视频通信，同时可以发送文字chat

流程分析

WebRTC

在WebRTC的实现过程中对于音视频数据的传输有两种方式，一、网页点对点，只有

信令通过服务器，而音视频数据通过P2P的方式直接传输；二、音视频数据也通过服务器

中转转。

网页点对点

WebRTC 实现了网页点对点交流。但，WebRTC 仍然需要服务器，作用:

1.交换客户端元数据协调通讯，即信令(Signaling)。

2.应对NATs(Network Address Translators) 和防火墙

让信令服务器和媒体服务器分开，只有信令交互通过服务器，而媒体传输通过P2P的

方式，这样做的优势在于降低了服务器端的流量。

Server

信令传输

数据传输

BrowserA BrowserB

但这种方式主要用在一对一模式中，在一对多的情况下，还需要服务器端的媒体服务器，

也是本文主要的讨论方式

[参考]

通过服务器中转

不管是信令还是数据，BrowserA想要传递给BrowserB的数据通过Server转发给

BrowserB。这种方式可以较容易的实现一对多或多对多的方式；如直播的应用。

Server

信令传输

数据传输

BrowserA BrowserB

本文中的实现虽然是一对一的形式，但采用的传输的方式是此种

JsSIP+Freeswitch

信令交互

为了避免冗余，以及做到与现有技术的最大兼容，信令方法和协议都不由WebRTC标

准来指定。本文实现中选用SIP信令协议和WebSocket传输协议，并采用jssip库来实现Sip

的客户端。

Freeswitch实现对sip的支持，在sip网络中端用UA表示，UAS代表服务端，UAC代

表客户端；当bob要与alice通信时，首先bob与作为UAS的Freeswitch发起请求，然后

Freeswitch作为UAC在于alice通信，之后把alice返回的信息发送给bob；从而达成交互；

Freeswitch成为

背靠背用户代理（B2BUA，Back-to-Back UA）

SIP信令

注册

呼叫流程

Freeswitch对于SIP的支持使用的是开源的Sofia协议栈

[参考]

传输协议：用于信令传输协议可以是TCP、UDP或其他；在WebRTC中使用的是

WebSocket协议，其优点是：通信是全双工的客户端/服务器(消息可以同时双向传输)，可以

省掉多次连接和传输的数据量。当然，这也需要Freeswitch的支持，能够解析其内容

数据交互

通过SIP协议中INVITE用于交互音视频相关的信息；信息包含在的Request和Response

中的SDP中；从中获取到音视频传输的类型和使用的ip端口

本文中使用的是UDP+RTP包传递音视频数据；

NAT穿越

本文中的实例，无论是Client和Server都在同一个局域网内；ip不需要转换。

安全相关

1. 在SIP协议交互中 REGISTER 和INVITE 都需要验证请求；否则返回错误

2. 在UDP传输数据是使用DTLS协议 保证安全

协议介绍

NAT

NAT（Network Address Translation，网络地址转换），本地地址的主机在和外界通信时，

都要在NAT软件将其本地地址转换成全球IP地址，才能和因特网连接。

NAT的作用

1.宽带分享

2.安全防护

NAT的实现方式有4种，分别如下：

1.

Full Cone NAT

完全锥形NAT，所有从同一个内网IP和端口号发送过来的请求都会被映射成同一个外网IP和端口号，并

且任何一个外网主机都可以通过这个映射的外网IP和端口号向这台内网主机发送包。

2.

Restricted Cone NAT

限制锥形NAT，它也是所有从同一个内网IP和端口号发送过来的请求都会被映射成同一个外网IP和端口

号。与完全锥形不同的是，外网主机只能够向先前已经向它发送过数据包的内网主机发送包。

3.

Port Restricted Cone NAT

端口限制锥形NAT，与限制锥形NAT很相似，只不过它包括端口号。也就是说，一台IP地址X和端口P

的外网主机想给内网主机发送包，必须是这台内网主机先前已经给这个IP地址X和端口P发送过数据包。

4.

Symmetric NAT

对称NAT，所有从同一个内网IP和端口号发送到一个特定的目的IP和端口号的请求，都会被映射到同一

个IP和端口号。如果同一台主机使用相同的源地址和端口号发送包，但是发往不同的目的地，NAT将会

使用不同的映射。此外，只有收到数据的外网主机才可以反过来向内网主机发送包。

STUN/TURN/ICE

STUN 协议

(转自)

STUN流程，首先有client向Stun服务器发起Binding请求，

STUN消息头为20字节，后面紧跟0或多个属性。STUN头部包含一STUN消息类型、magic cookie、

事务ID和消息长度。

STUN头之后是0或多个属性。每个属性都采用TLV编码，16位的类型、16位的长度及可变长度的值。

每个STUN属性必须是4字节边界对齐。

属性类型

MAPPED-ADDRESS

标识了客户端反向传输地址（映射后的地址），这个属性只用于服务器向后兼容RFC3489的客户端。

XOR-MAPPED-ADDRESS

与MAPPED-ADDRESS属性是相同的，除了这映射后的地址经过了异或处理。（注意，异或运算是其自

身的逆运算，再异或一下就可以得出真实的MAPPED-ADDRESS）

USERNAME

用于消息完整性。它采用USERNAME和PASSWORD组合方式用于消息完整性检查。

MESSAGE-INTEGRITY

包含STUN消息的HMAC-SHA1。它可以出现在任何类型的STUN消息中。由于使用SHA1散列算法，

HMAC将会是20字节。用作HMAC输入的文本是STUN消息，包括头部，直到且包括

MESSAGE-INTEGRITY属性前面的属性。除了FINGERPRINT属性外，代理必须忽略其他出现在

MESSAGE-INTEGRITY属性后的任何属性。

STUN消息头中的长度字段的值必须包括直到MESSAGE-INTEGRITY属性本身，但不包括任何在它之后

的属性。

FINGERPRINT

可以存在于所有的STUN消息中，提供辅助区分STUN数据包与其他协议数据包的功能。属性的值为采用

CRC32方式计算STUN消息直到但不包括FINGERPRINT属性的的结果，并与32位的值0x5354554e

异或。

ERROR-CODE

被用于错误响应消息中。它包含一个在300至699范围内的错误响应号。

错误响应号定义如下：

300：尝试代替，客户端应该使用该请求联系一个代替的服务器。这个错误响应仅在请求包括一个

USERNAME属性和一个有效的MESSAGE-INTEGRITY属性时发送；否则它不会被发送，而是发送错误

代码为400的错误响应；

400：错误请求，请求是变形了，客户在修改先前的尝试前不应该重试该请求。

401：未授权，请求未包括正确的资格来继续。客户应该采用一个合适的资格来重试该请求。

420：未知属性，服务器收到一个STUN包包含一个强制理解的属性但是它不会理解。服务器必须将不认

识的属性放在错误响应的UNKNOWN-ATTRIBUTE属性中。

438：过期Nonce，客户使用的Nonce不再有效，客户应该使用响应中提供的Nonce来重试。

500：服务器错误，服务器遇到临时错误，客户应该再次尝试。

REALM

REALM属性可能出现在请求和响应中。在请求中表示长期资格将在认证中使用。当在错误响应中出现表

示服务器希望客户使用长期资格来进行认证。

NONCE

NONCE属性可能出现在请求和响应消息中。

UNKNOWN-ATTRIBUTES

UNKNOWN-ATTRIBUTES属性只在错误代码为420的的错误响应中出现。

SOFTWARE

SOFTWARE属性用于代理发送消息时包含版本的描述。它用于客户端和服务器。它的值包括制造商和版

本号。该属性对于协议的运行没有任何影响，仅为诊断和调试目的提供服务。SOFTWARE属性是个可变

长度的，采用UTF-8编码的小于128个字符的序列号。

ALTERNATE-SERVER

ALTERNATE-SERVER属性标识一个备份的传输地址表明一个STUN客户可以尝试的不同的STUN服务

器。属性格式与MAPPED-ADDRESS相同。IP地址族必须与请求的源IP地址的相同。

TURN

在RFC5766中定义，英文全称Traversal Using Relays around NAT（TURN）：Relay Extensions to Session

Traversal Utilities for NAT（STUN）

TURN与STUN的共同点都是通过修改应用层中的私网地址达到NAT穿透的效果，异同点是TURN是通

过两方通讯的“中间人”方式实现穿透

RURN是针对STUN失效时的一种补充；当ClientA无法直接有ClientB通信时，在中间添

加一个中间人，用于传递内容；STUN服务器作为中间人传递消息

新的STUN方法

下面给出了新的STUN方法的编号：

0x003 Allocate

0x004 Refresh

0x006 Send

0x007 Data

0x008 CreatePermission

0x009 ChannelBind

新的STUN属性

0x000c CHANNEL-NUMBER

0x000D LIFETIME

0x0010 Reserved (was BANDWIDTH)

0x0012 XOR-PEER-ADDRESS

0x0013 DATA

0x0016 XOR-RELAYED-ADDRESS

0x0018 EVEN-PORT

0x0019 REQUESTED-TRANSPORT

0x001A DON’T-FRAGMENT

0x0021 Reserved (was TIMER-VAL)

0x0022 RESERVATION-TOKEN

B通过TURN的方式向A发数据

ICE

交互式连通建立方式ICE(Interactive ConnectivityEstablishment)并非一种新的协议，它不

需要对STUN，TURN或RSIP进行扩展就可适用于各种NAT

WebSocket

1.定义

WebSocket protocol 是HTML5一种新的协议。它实现了浏览器与服务器全双工通信

(full-duplex)。此处的双工说的是应用层面的，相对于http的单向 Request-Response的方式。

WebSocket通訊協定於2011年被IETF定為標準RFC 6455

webSocket 基于http和tcp ，运行在Browser中

WebSocket协议构成

[参考]

在 WebSocket API，浏览器和服务器只需要要做一个握手的动作，然后，浏览器和服务

器之间就形成了一条快速通道。两者之间就直接可以数据互相传送,不在发送Request。

两大好处：

1. Header 很小 互相沟通的Header是很小的-大概只有

2．Bytes 2. Server Push 服务端的动作

为保证连接的持续性让服务器和客户端能够发送 Ping/Pong Frame

2.步骤

(1)建立连接

Browser 请求

GET / HTTP/1.1

Upgrade: websocket

Connection: Upgrade

Host:

Origin: null

Sec-WebSocket-Key: sN9cRrP/n9NdMgdcy2VJFQ==

Sec-WebSocket-Version: 13

ws-Server 回复

HTTP/1.1 101 Switching Protocols

Upgrade: websocket

Connection: Upgrade

Sec-WebSocket-Accept: fFBooB7FAkLlXgRSz0BT3v4hq5s=

Sec-WebSocket-Origin: null

Sec-WebSocket-Location: ws:///

收到正确回复之后，连接算建立完成，即可以互通数据

(2)数据

官方文档提供了一个结构图

0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

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

|F|R|R|R| opcode|M| Payload len | Extended payload length |

|I|S|S|S| (4) |A| (7) | (16/64) |

|N|V|V|V| |S| | (if payload len==126/127) |

| |1|2|3| |K| | |

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

| Extended payload length continued, if payload len == 127 |

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

| |Masking-key, if MASK set to 1 |

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

| Masking-key (continued) | Payload Data |

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

: Payload Data continued ... :

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

| Payload Data continued ... |

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

定义字节长度及相关含义的。

FIN 1bit 表示信息的最后一帧，flag，也就是标记符

RSV 1-3 1bit each 以后备用的 默认都为 0

Opcode 4bit 帧类型，稍后细说

Mask 1bit 掩码，是否加密数据，默认必须置为1 （这里很蛋疼）

Payload 7bit 数据的长度

Masking-key 1 or 4 bit 掩码

Payload data (x + y) bytes 数据

Extension data x bytes 扩展数据

Application data y bytes 程序数据

SIP协议

会话初始协议（Session Initiation Protocol）是一个控制发起、修改和终结交互式多媒体

会话的信令协议。它是由 IETF（Internet Engineering Task Force，Internet工程任务组）在 RFC

2543 中定义的。后来又发布了一个新的标准 RFC 2361。

广泛应用于CS（Circuit Switched，电路交换）、NGN（Next Generation Network，下

一代网络）以及IMS（IP Multimedia Subsystem，IP多媒体子系统）的网络中，可以支持

并应用于语音、视频、数据等多媒体业务，同时也可以应用于Presence（呈现）、Instant

Message（即时消息）等业务

字段

SIP 是一个基于文本的协议，类似Http。

Request

1. REGISTER

line1：type URI;传输类型 version

line2-via：SIP的消息路由，当经过多个代理服务器转发是，会有多条via

line3-Max-Forwards: 最多可以经过多少次转发，防止死循环

line4-Contact： 请求端的地址

line5-To：被叫用户的地址

line6-From：主叫用户的地址

line7-Call-ID: 本次SIP会话的标志

line8-CSeq: 请求的序号，用于UDP传输的重传机制

line9-Expires：本次注册的有效期，单位s；3600 说明有效时间为1小时，1小时内需要再

注册(一般几十s会重试一次)

line10-Allow: 说明请求端UA所支持的功能

line11-User-Agent: UA的型号

line12-Allow-Events: 允许哪些事件通知

line13-Content-Length: 消息体（body）的长度 此处没有消息体

2. INVITE

在此列出了Request头，还有594自己的SDP数据内容

响应处理

收到UAS的结果后(1xx不是),需要回复ACK

收到2xx的结果后，一个会话建立成功

收到407 送重新发送INVITE 并携带Proxy-Authenticate

3. BYE

用于结束当前会话

返回200ok 正确停止

Response

1. 100 trying

服务器收到Requst，告诉客户端进入处理阶段

2. 180 : Ringing

UA 收到INVITE 通知user，用于响铃

3. 183 Session progress

区别于180 可以传递信息

4. 200 ok

请求成功处理

5. 401 : Unauthorized

请求需要验证；Request没有验证信息。

响应头中包含

WWW-Authenticate: 字段

用于REGISTER 的响应

6.

407 : Proxy Authentication Required

区别于401 用于INVITE的响应

以上只给出了本文中用到的信令字段，详细可以查看rfc文档

RTP协议

SDP协议

SDP (Session Description Protocol)是一种会话描述格式 ― 它不属于传输协议；它使用

不同的适当的传输协议(包括SAP,SIP,RTSP,HTTP等)

SDP描述由许多文本行组成，文本行的格式为:

<类型>=<值>;

<类型>是一个字母;

<值>是结构化的文本串，其格式依<类型>而定。

＜type＞=[CRLF]

详见rfc4566文档