没有合适的资源?快使用搜索试试~ 我知道了~
温馨提示
本文是WebRTC工作组最新一次会议后的候选推荐标准,基于WebIDL定义了一组ECMAScript API,允许在实现了相关实时协议的浏览器或设备之间发送和接收媒体内容。同时也是对WebRTC的一个全面介绍,包括WebRTC中的各个术语,独有的概念,API的使用规范,详细的算法流程和一些注意点,并且对涉及的数据结构及其属性进行了剖析。在特定的使用场景下,草案的作者们还附上了示例代码。
资源推荐
资源详情
资源评论
W3C
推荐标准
WebRTC 1.0
浏览器间实时通讯
30
分钟构建流畅清晰的视频、音频通话
1
天实现稳定的APP私聊、群聊、聊天室功能
网易云信核心能力
IM
云
单聊
群聊
多人大群
聊天室
自定义消息扩展
音视频通话
音频通话
视频通话
点对点通话
多对多通话
录制
音视频通话
视频采集
短视频采集编辑
视频播放
CDN分发
频道管理
录制美颜、伴音等
点播
媒体存储
断点续传
视频转码
播放器
CDN加速
视频管理
短视频秒开管理
短信码通道
短信码验证
模板短信
营销短信
多通道切换
短信统计
专线电话
多人通话
分钟统计
拨打查询
多方通话
WebRTC1.0:
浏览器间的实时通信
1.
介绍
本规范涵盖了对等通信(peer-to-peer communications)和网页视频会议的多个方面:
利用
ICE,STUN,TURN等NAT穿透技术连接至远程对等终端。
将本地产生的媒体流发送至对端并接收对端产生的媒体流。
直接向远程对等终端发送任意数据。
本文档针对这些特性定义了一些API。本规范是在IETF RTCWEB
工作组的协议规范,和
Media Capture Task Force工
作组的访问本地媒体设备API规范[GEtUSERMEDIA],两者共同催动下发展出来的。系统的概览可以在引用列表中的
RTCWEB-OVERVIW
和RTCWEB-SECURITY
找到。
2.
一致性
关键词 MAY, MUST, MUST NOT, SHALL, SHOULD
的语义解释在RFC2119中都有描述。 本规范定义了适用于某个产
品的一致性标准:用户代理应实现规范包含的接口。 一致性的要求可以被表述为一些算法,或被实现为任意行为的
特定步骤,只要它们最终的结果是等效的。(特别地,规范中定义的算法更易理解,但性能也许不尽如人意。) 本
规范中定义的API,必须(MUST)以WEBIDL中规定的行为一致的ECMAScript绑定的方式实现,毕竟我们使用了它
们的规范与术语。
3.
术语
EventHandler
接口代表了一个事件回调,ErrorEvent接口定义在HTML51
任务入队(queue a task)和网络任务源(networking task source)的概念定义在HTML51
。
构造事件(
fire an event)的概念定义在DOM
。
事件(event),事件句柄(
event handler)和
事件句柄类型(event handler event types)定义在HTML51
。
performance.timeOrigin和performance.now()定义在HIGHRES-TIME
。
可序列化对象(serializable objects),序列化步骤(serialization step),反序列化步骤(
deserialization
steps)定义在HTML
。
媒体流(MediaStream),媒体流轨(MediaStreamTrack),媒体流约束(MediaStreamConstraints)定义在
GETUSERMEDIA
。
Blob 定义在FILEAPI
。
媒体描述(media description)定义在RFC4566
。
媒体传输(media transport)定义在RFC7656
。
地址(generation)定义在TRICKLE-ICE
的第二节。
RTCStatsType,stats object和monitored object 定义在WEBRTC-STATS
。
当引入异常时,WEBIDL-1
中定义了 throw和create。
"throw"作为INFRA
中的规定来使用:它会终止目前正在运行的操作。
Promises
的上下文中使用的 fulfilled, rejected, resolved, pending和settled 在ECMASCRIPT-6.0
中定义。
捆绑(bundle),只捆绑(bundle-only)和捆绑策略(bundle-policy)在
JSEP中定义。
OAuth客户端(OAuth Client)和授权服务(Authorization Server)在RFC6749
的1.1节被定义。
隔离流(isolated stream),对等身份(peer identity),身份声明请求(request an identity assertion)和身份
认证(validate the identity)在WEBRTC-IDENTITY
中定义。
想获取更多技术干货,欢迎访问https://yunxin.163.com/
注意:
通常使用Javascript API的原则包括: 同步运行
和 数据独立
,它们都在API-DESIGN-PRINCIPLES
中定义
了。也就是说,当一个任务正在运行时,任何外部事件都不会影响Javascript应用的可见性。例如,当
Javascript执行时,缓存在数据通道里的数据数量将会随着"send"的调用而增长,并且直到任务的检查点之后,
由于发送数据包导致的减少才被应用可见。 用户代理负责确保呈现给应用程序的的数据是一致的——例如
getContributingSources()
(同步调用)会返回当前所有被检测的数据源的值。
4.
对等连接
4.1 介绍
一个RTCPeerConnection
实例允许与另一个浏览器,或实现了制定协议的终端中的 RTCPeerConnection
实例建立对
等通信。双方在信令通道中通过控制消息(即自定义的信令协议)协商会话,信号通道并没有明确的制定,但通常是
服务页面中的一段脚本,例如
XMLHttpRequest,也可以是WebSockets
。
4.2 配置
4.2.1
RTCConfiguration
字典
RTCConfiguration
定义了一系列用于配置如何通过 RTCPeerConnection
建立/重建对等通信的参数。
RTCConfiguration
字典成员变量:
sequence
类型的的 iceServers
:描述可供ICE使用的服务对象数组,例如STUN服务和TURN服务。
RTCIceTransportPolicy
类型的 iceTransportPolicy
,缺省值为"all":指示哪个候选 ICE Agent
可用。
RTCBundlePolicy
类型的 bundlePolicy
,缺省值为"balanced":当收集候选ICE时指示使用什么媒体捆绑策
略。
RTCRtcpMuxPolicy
类型的 rtcMuxPolicy
,缺省值为"require":当收集候选ICE时指示使用什么RTCP复用策
略。
DOMString
类型的 peerIdentity
:为RTCPeerConnection设置目标对等终端的身份。只有成功地对身份进行
鉴权,RTCPeerConnection才能与远程对等终端建立起连接。
sequence
类型的 certificates
:RTCPeerConnection鉴权时所需的一系列证书。
此参数的合法值通过调用 generateCertificate
函数得到。
尽管任意给定的DTLS连接只会使用一份证书,但这一属性使得调用方可以供应多种证书以支持不同的算法。在
DTLS连接的握手阶段,它会最终选择一份允许范围内的证书。RTCPeerConnection的具体实现中完成了对给定
连接的证书选择过程,但证书是如何选择的并不在本规范的讨论范围之内。
如果值为空,则每个RTCPeerConnection实例都会生成默认的证书集合。
此选项还使得应用的密钥连续性成为可能。一个 RTCCertificate
可以被持久化存储在INDEXEDDB
中并被复
dictionary
RTCConfiguration {
sequence<RTCIceServer> iceServers;
RTCIceTransportPolicy iceTransportPolicy = "all";
RTCBundlePolicy bundlePolicy = "balanced";
RTCRtcpMuxPolicy rtcpMuxPolicy = "require";
DOMString peerIdentity;
sequence<RTCCertificate> certificates;
[EnforceRange]
octet iceCandidatePoolSize = 0;
};
想获取更多技术干货,欢迎访问https://yunxin.163.com/
用。持久化和复用避免了密钥重复生成的开销。
此配置选项的值在初始化阶段被选择后就不能再被改变。
octet
类型的 iceCandidatePoolSize
,缺省值为 0
:预先获取的ICE池的大小在
JSEP的第3.5.4节和4.1.1节被
定义。
4.2.2
RTCIceCredentialType
枚举值
枚举值简述:
password
:此凭据是依托于用户名和密码的长期认证方式,RFC5389
的10.2节有详细描述
oauth
:一个基于OAuth2.0的认证方法,在RFC7635
有描述。
对于OAuth认证,需要向ICE Agent供应3份证书信息: kid
(用于RTCIceServer成员变量username),
macKey
和 accessToken
(存在于RTCOAuthCredential字典类型内)。
注意:本规范并没有定义应用(起OAuth Client的作用)是如何从
Authorization Server
获取
accessToken, kid, macKey
这些证书的,因为WebRTC只处理ICE Agent与TURN Server之间的交互。例
如,应用可能使用PoP(Proof-of-Possession)的Token证书类型,使用OAuth 2.0隐式授权类型。RFC
的附
录B中有此示例。
OAuth Client应用,负责刷新证书信息,并且在 accessToken
失效前利用新的证书信息更新ICE Agent。OAuth
Client可以利用RTCPeerConnection的setConfiguration方法来周期性的刷新TURN证书。
HMAC密钥(RTCOAuthCredential.macKey)的长度应是一个大于20字节的整数(160位)。
注意:根据RFC7635
4.1节,HMAC密钥必须是对称密钥,但对称密钥会生成
大型的访问令牌,可能和单个
STUN信息不兼容。
注意:目前的STUN/TURN协议只是用了SHA-1/SHA-2族哈希算法来保证消息完整性,这在[RFC5389]的15.3
节和[STUN-BIS]的14.6节作了定义。
4.2.3
RTCOAuthCredential
字典
RTCOAuthCredential
字典被STUN/TURN客户端(内置于ICE Agent内)用于描述OAuth的鉴权证书信息,对
STUN/TURN服务器进行身份认证,RFC7635
有相关描述。注意 kid
参数并不在此字典类型中,而在 RTCIceServer
的 username
成员变量中。
RTCOAuthCredential
字典的成员变量:
DOMString
类型的 macKey
,非空:"mac_key"是一串base64-url格式的编码,在RFC7635
的6.2节有相关描
述。它被用在STUN的消息完整性哈希计算中(密码使用的则是基于密码的认证方式)。注意,OAuth响应里
的"key"参数是一个JSON Web Key(JWK)或JWK编码后JWE格式的消息。同样注意,这是OAuth中唯一一个不
被直接使用的参数,它只能从JWK的"k"参数中提取出来,"k"参数包含了需要的base-64编码的"mac_key"。
DOMString
类型的 accessToken
,非空:"access_token"是一串base64格式的编码,在RFC7635
的6.2节有相
关描述。这是一个自持有的令牌,应用不可见。认证加密被用于消息的加密和完整性保护。访问令牌包括了一
enum
RTCIceCredentialType {
"password",
"oauth"
};
dictionary
RTCOAuthCredential {
required DOMString macKey;
required DOMString accessToken;
};
想获取更多技术干货,欢迎访问https://yunxin.163.com/
剩余107页未读,继续阅读
资源评论
bose2365
- 粉丝: 25
- 资源: 226
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
最新资源
资源上传下载、课程学习等过程中有任何疑问或建议,欢迎提出宝贵意见哦~我们会及时处理!
点击此处反馈
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功