WebRtcFreeswitch搭建视频通话讲述Word文档格式.docx
- 文档编号:6232754
- 上传时间:2023-05-06
- 格式:DOCX
- 页数:23
- 大小:646.18KB
WebRtcFreeswitch搭建视频通话讲述Word文档格式.docx
《WebRtcFreeswitch搭建视频通话讲述Word文档格式.docx》由会员分享,可在线阅读,更多相关《WebRtcFreeswitch搭建视频通话讲述Word文档格式.docx(23页珍藏版)》请在冰点文库上搜索。
1.过程中需要的一些库,系统没有提供,导致编译失败;
使用yuminstall的方法安装
2.可已通过modules.conf配置那些模块一起编译;
opus没有编译过,在此文件注释掉了
3.如果Freeswitch中的某个模块出现连接错误,可以clean后重新make试一下
修改配置
(1)修改vars.xml文件变量(黑色部分为添加的项)
<
X-PRE-PROCESScmd="
set"
data="
global_codec_prefs=PCMU,PCMA,GSM,H264,H263"
/>
data="
outbound_codec_prefs=PCMU,PCMA,GSM,H264,H263"
(2)修改配置文件conf/sip_profiles/interanl.xml,打开
中去掉ws-binding5066的注释
(3)关闭linux的防火墙(如不关闭客户端可能会有访问拒绝错误)
serviceiptablesstop
呼叫
Freeswitc默认设置了20个用户(用户名1000-1019)密码:
1234;
使用默认用户测试
环境:
ClientA:
PC端使用虚拟摄像头播放一段视频,用户名1012
ClientB:
笔记本,使用摄像头采集实时视频用户名1011
Freeswitch–SipIP:
192.168.12.244:
5060
Freeswitch–WSURL192.168.12.244:
5066
ClientA和ClientB可以通过音视频通信,同时可以发送文字chat
流程分析
在WebRTC的实现过程中对于音视频数据的传输有两种方式,一、网页点对点,只有信令通过服务器,而音视频数据通过P2P的方式直接传输;
二、音视频数据也通过服务器中转转。
网页点对点
WebRTC实现了网页点对点交流。
但,WebRTC仍然需要服务器,作用:
1.交换客户端元数据协调通讯,即信令(Signaling)。
2.应对NATs(NetworkAddressTranslators)和防火墙
让信令服务器和媒体服务器分开,只有信令交互通过服务器,而媒体传输通过P2P的方式,这样做的优势在于降低了服务器端的流量。
但这种方式主要用在一对一模式中,在一对多的情况下,还需要服务器端的媒体服务器,也是本文主要的讨论方式
[参考]
通过服务器中转
不管是信令还是数据,BrowserA想要传递给BrowserB的数据通过Server转发给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-BackUA)
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(NetworkAddressTranslation,网络地址转换),本地地址的主机在和外界通信时,都要在NAT软件将其本地地址转换成全球IP地址,才能和因特网连接。
NAT的作用
1.宽带分享
2.安全防护
NAT的实现方式有4种,分别如下:
1.
FullConeNAT
完全锥形NAT,所有从同一个内网IP和端口号发送过来的请求都会被映射成同一个外网IP和端口号,并且任何一个外网主机都可以通过这个映射的外网IP和端口号向这台内网主机发送包。
2.
RestrictedConeNAT
限制锥形NAT,它也是所有从同一个内网IP和端口号发送过来的请求都会被映射成同一个外网IP和端口号。
与完全锥形不同的是,外网主机只能够向先前已经向它发送过数据包的内网主机发送包。
3.
PortRestrictedConeNAT
端口限制锥形NAT,与限制锥形NAT很相似,只不过它包括端口号。
也就是说,一台IP地址X和端口P的外网主机想给内网主机发送包,必须是这台内网主机先前已经给这个IP地址X和端口P发送过数据包。
4.
SymmetricNAT
对称NAT,所有从同一个内网IP和端口号发送到一个特定的目的IP和端口号的请求,都会被映射到同一个IP和端口号。
如果同一台主机使用相同的源地址和端口号发送包,但是发往不同的目的地,NAT将会使用不同的映射。
此外,只有收到数据的外网主机才可以反过来向内网主机发送包。
STUN/TURN/ICE
STUN协议
(转自)
STUN流程,首先有client向Stun服务器发起Binding请求,
STUN消息头为20字节,后面紧跟0或多个属性。
STUN头部包含一STUN消息类型、magiccookie、事务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中定义,英文全称TraversalUsingRelaysaroundNAT(TURN):
RelayExtensionstoSessionTraversalUtilitiesforNAT(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
(wasBANDWIDTH)
0x0012
XOR-PEER-ADDRESS
0x0013
DATA
0x0016XOR-RELAYED-ADDRESS
0x0018
EVEN-PORT
0x0019
REQUESTED-TRANSPORT
0x001A
DON’T-FRAGMENT
0x0021
(wasTIMER-VAL)
0x0022
RESERVATION-TOKEN
B通过TURN的方式向A发数据
ICE
交互式连通建立方式ICE(InteractiveConnectivityEstablishment)并非一种新的协议,它不需要对STUN,TURN或RSIP进行扩展就可适用于各种NAT
WebSocket
1.定义
WebSocketprotocol是HTML5一种新的协议。
它实现了浏览器与服务器全双工通信(full-duplex)。
此处的双工说的是应用层面的,相对于http的单向Request-Response的方式。
WebSocket通訊協定於2011年被IETF定為標準RFC6455
webSocket基于http和tcp
,运行在Browser中
WebSocket协议构成
[参考]
在WebSocketAPI,浏览器和服务器只需要要做一个握手的动作,然后,浏览器和服务器之间就形成了一条快速通道。
两者之间就直接可以数据互相传送,不在发送Request。
两大好处:
1.Header很小
互相沟通的Header是很小的-大概只有
2.Bytes
2.ServerPush服务端的动作
为保证连接的持续性让服务器和客户端能够发送Ping/PongFrame
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.1101SwitchingProtocols
Sec-WebSocket-Accept:
fFBooB7FAkLlXgRSz0BT3v4hq5s=
Sec-WebSocket-Origin:
Sec-WebSocket-Location:
ws:
//
收到正确回复之后,连接算建立完成,即可以互通数据
(2)数据
官方文档提供了一个结构图
0123
01234567890123456789012345678901
+-+-+-+-+-------+-+-------------+-------------------------------+
|F|R|R|R|opcode|M|Payloadlen|Extendedpayloadlength|
|I|S|S|S|(4)|A|(7)|(16/64)|
|N|V|V|V||S||(ifpayloadlen==126/127)|
||1|2|3||K|||
+-+-+-+-+-------+-+-------------+---------------+
|Extendedpayloadlengthcontinued,ifpayloadlen==127|
+---------------+-------------------------------+
||Masking-key,ifMASKsetto1|
+-------------------------------+-------------------------------+
|Masking-key(continued)|PayloadData|
+-----------------------------------------------+
:
PayloadDatacontinued...:
+-------------------------------+
|PayloadDatacontinued...|
+---------------------------------------------------------------+
定义字节长度及相关含义的。
FIN1bit表示信息的最后一帧,flag,也就是标记符
RSV1-31biteach以后备用的默认都为0
Opcode4bit帧类型,稍后细说
Mask1bit掩码,是否加密数据,默认必须置为1(这里很蛋疼)
Payload7bit数据的长度
Masking-key1or4bit掩码
Payloaddata(x+y)bytes数据
Extensiondataxbytes扩展数据
Applicationdataybytes程序数据
SIP协议
会话初始协议(SessionInitiationProtocol)是一个控制发起、修改和终结交互式多媒体会话的信令协议。
它是由IETF(InternetEngineeringTaskForce,Internet工程任务组)在RFC2543中定义的。
后来又发布了一个新的标准RFC2361。
广泛应用于CS(CircuitSwitched,电路交换)、NGN(NextGenerationNetwork,下一代网络)以及IMS(IPMultimediaSubsystem,IP多媒体子系统)的网络中,可以支持并应用于语音、视频、数据等多媒体业务,同时也可以应用于Presence(呈现)、InstantMessage(即时消息)等业务
字段
SIP是一个基于文本的协议,类似Http。
Request
1.REGISTER
line1:
typeURI;
传输类型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.100trying
服务器收到Requst,告诉客户端进入处理阶段
2.180:
Ringing
UA收到INVITE通知user,用于响铃
3.183Sessionprogress
区别于180可以传递信息
4.200ok
请求成功处理
5.401:
Unauthorized
请求需要验证;
Request没有验证信息。
响应头中包含WWW-Authenticate:
用于REGISTER的响应
6.407:
ProxyAuthenticationRequired
区别于401用于INVITE的响应
以上只给出了本文中用到的信令字段,详细可以查看rfc文档
RTP协议
SDP协议
SDP(SessionDescriptionProtocol)是一种会话描述格式―它不属于传输协议;
它使用不同的适当的传输协议(包括SAP,SIP,RTSP,HTTP等)
SDP描述由许多文本行组成,文本行的格式为:
类型>
=<
值>
;
是一个字母;
是结构化的文本串,其格式依<
而定。
<type>=<
value>
[CRLF]
详见rfc4566文档
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- WebRtcFreeswitch 搭建 视频 通话 讲述
![提示](https://static.bingdoc.com/images/bang_tan.gif)