WebRTC学习之一:开篇

一.无插件的实时通讯

       想像一下,如果你的手机、电视、电脑都可以通过一个平台进行通信,想像一下,你可以在Web应用中轻松地加入视频聊天和p2p数据分享,这就是WebRTC的愿景。
       想试一试吗?WebRTC现在已经被集成到Chrome、Opera和Firefox,在apprtc.appspot.com有个简单的视频聊天应用可供测试。
1.在Chrome、Opera或Firefox中打开apprtc.appspot.com。
2.点击允许按钮允许应用启用你的摄像头。
3.在新的选项卡中打开页面底部显示的URL,当然能在另外一台电脑上打开该URL会更好。

关于这个应用的具体教程详见“一个简单的视频聊天客户端”章节。

二.快速开始

       如果你没有时间阅读这篇文章,想直接编码,你可以这样:
1.看一看Gooogle关于WebRTC的幻灯片(here)。
2.你果你没有用过getUserMedia,要先学习一下它,教程:HTML5 Rocks article,例子:simpl.info/gum。
3.掌握RTCPeerConnection API,教程:本文的代码段,例子:simpl.info/pc,这个例子在一个单独的网页中实现了WebRTC。
4.了解一下WebRTC信令服务、防火墙和NAT转发,教程:apprtc.appspot.com
5.实在等不及了,可以通过这20+ demos练习WebRTC的JavaScript API。
6.如果有什么问题,可以试试问题帮助页面test.webrtc.org。
       或者你可以直接跳到这一步:在WebRTC codelab上一步一步的学习如何构建一个完整的视频聊天应用程序,包括一个简单的信令服务器。

三.关于WebRTC的小故事

       其实一个Web开发的终极挑战就是通过音频和视频进行实时通信,视频通信应该像文本通信一样自然,如果没有它,我们在用户交互方面的创新能力会受到限制。
       在过去,实时通信都比较复杂,需要非常丰富的音频和视频技术才能进行开发。 完整的实现实时通信需要整合大量的数据和服务,在Web上实现尤其困难。
       2008年,Gmail视频聊天火了。2011年谷歌发布了Hangouts,收购了GIPS,GIPS为RTC开发了许多组件,比如编码和回声消除技术。谷歌开源了GIPS的相关技术,并且与IETF和W3C等标准化组织达成了行业共识。2011年5月爱立信构建了第一个WebRTC应用。
       WebRTC目前实现了实时、无插件的音频、视频和数据通信,我们迫切需要它,因为:
1.许多web service在使用RTC,但是需要下载原生app或者插件,比如Skype、Facebook和谷歌Hangouts。
2.下载、安装和升级插件非常繁琐,而且容易出错。
3.插件不容易发现问题,测试很困难,大部分都需要授权,开发成本太高。
       WebRTC项目的宗旨是:API是开源、免费的、标准的、可内建于浏览器且比其他现存的技术更加高效。

四.WebRTC使用现状

       目前WhatsAPP、Facebook Messenger等应用都使用了WebRTC,不仅如此WebRTC还出现在其他平台中,比如TokBox。WebRTC可以被整合到WebKitGTK+或者Qt原生应用中。
WebRTC实现了下列三个API:

1.MediaStream (别名getUserMedia)

2.RTCPeerConnection

3. RTCDataChannel
       getUserMedia可用于Chrome、Opera、Firefox和Edge。你可以看看这个跨浏览器的demo和Chris Wilson的amazing examples,这些例子使用getUserMedia作为音频的输入。
       RTCPeerConnection可用于Chrome、Opera和Firefox。经过几次迭代之后RTCPeerConnection被Chrome和Opera实现为webkitRTCPeerConnection,被Firefox实现为mozRTCPeerConnection。其他的实现已经被废弃。当标准化进程稳定之后,这两个实现名字的前缀会被移除。Chromium的一个超级简单的RTCPeerConnection实现在GitHub上,大量的视频聊天应用在apprtc.appspot.com
       RTCDataChannel可用于Chrome、Opera和Firefox。在GitHub上有关于数据通道的例子,可以去实践一下。

五.我的第一个WebRTC应用

       开发WebRTC应用需要做好下列准备:
1.获取音视频流或者其他数据
2.得到网络信息,如IP地址和端口,通过网络和其它WebRTC客户端交换数据,解决NATs/防火墙穿透问题。
3.协调信令通信来报告错误、启动或关闭会话。
4.交换媒体和客户端信息,比如分辨率和编解码参数。
5.传输音视频流或者其他数据。
       为了实现数据流通信,WebRTC实现了下列API:
1.MediaStream从设备获取数据流,比如说摄像头和麦克风。
2.RTCPeerConnection:音视频通话,包括设备加密和带宽管理。
3.RTCDataChannel:p2p通信。

六.MediaStream (别名getUserMedia)

       MediaStream API代表媒体流的同步。比如,从摄像头和麦克风获取的媒体流具有同步视频和音频轨道。不要将这里的MediaStream轨道和元素混淆,它们是完全不同的概念。
理解MediaStream最简单的方法如下:
1.在Chrome或Opera中打开例子https://webrtc.github.io/samples/src/content/getusermedia/gum
2.打开控制台
3.检查stream变量,该变量是全局的。
       每个MediaStream都有输入,即navigator.getUserMedia();也有输出,被传递到video元素或RTCPeerConnection
getUserMedia()方法有三个参数:
1.一个约束对象。
2.一个成功的回调,如果成功会回传一个MediaStream。
3.一个失败的回调,如果失败会回传一个error对象。
       每个MediaStream都有一个label,比如'Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ',getAudioTradks()和getAudioTracks()方法会回传一个MediaStreamTracks对象的数组。
在例子https://webrtc.github.io/samples/src/content/getusermedia/gum中,stream.getAudioTracks()回传了一个空数组(因为没有音频),假设摄像头正常工作并连接,stream.getVideoTracks()回传一个MediaStreamTracks对象的数组。数组中的每个MediaStreamTracks对象包含一种媒体(‘video’或‘audio’)和一个label(比如'FaceTime HD Camera (Built-in)'),而且还代表了一个或多个音视频的数据通道。在这个例子中,只有一个视频轨道,没有音频。当然,很容易就能扩展到其他情况。
       在Chrome或Opera中, URL.createObjectURL()方法将MediaStream转换成Blob URL,该Blob URL可以设置为video元素的输入(在Firefox和Opera中,视频源可以通过数据流本身设置)。版本M25开始,基于Chromium的浏览器(Chrome和Opera)允许来自getUserMedia的音频数据传递到aduio或video元素。
       getUserMedia还可用作Web Audio API的输入节点
function gotStream(stream) {
    window.AudioContext = window.AudioContext || window.webkitAudioContext;
    var audioContext = new AudioContext();

    // Create an AudioNode from the stream
    var mediaStreamSource = audioContext.createMediaStreamSource(stream);

    // Connect it to destination to hear yourself
    // or any other node for processing!
    mediaStreamSource.connect(audioContext.destination);
}
navigator.getUserMedia({audio:true}, gotStream);
       在manifest中添加audioCapture和videoCapture权限可以在加载的时候得到(仅一次)授权,毕竟加载之后用户不会再有对摄像头或麦克风的访问请求。
       最终的目的是使MediaStream适用于任何数据源,不仅限于摄像头和麦克风,还包括来自磁盘或者传感器等输入设备二进制数据。
       需要注意的是getUserMedia()必须在服务器上使用,而不是本地文件中,否则的话将会抛出权限的错误PERMISSION_DENIED。
       getUserMedia()通常和其他的JavaScript API及库一起使用:

Webcam Toy是一个photobooth应用,它使用WebGL来添加一些特效,让用户可以共享照片或是保存到本地。
FaceKat是一个人脸追踪的游戏,使用headtrackr.js。

ASCII Camera使用Canvas API来生成ASCII码的图片。

七.约束

       Constraints已经在Chrome、FireFox和Opera中实现了。通过约束可以设置getUserMedia()和RTCPeerConnection的addStream()获取视频的分辨率,约束的实现是为了通过applyConstraints()方法控制视频高度和宽度的比例、帧率、和正反摄像头模式等等……
       这里有一个例子:https://webrtc.github.io/samples/src/content/getusermedia/resolution/
       一个陷阱:getUserMedia约束设置在浏览器的一个标签中,会约束之后打开的所有标签。设置一个非法的值会提示以下错误:
navigator.getUserMedia error:
NavigatorUserMediaError {code: 1, PERMISSION_DENIED: 1}

八.屏幕和标签捕获

       Chrome应用可以通过chrome.tabCapture和chrome.desktopCapture这两个API实时分享浏览器标签或者整个桌面。桌面捕获的例子:WebRTC samples GitHub repository。更多关于屏幕录制、编码的信息和有参考:Screensharing with WebRTC
       在Chrome中,可以将屏幕捕获当做MediaStream的数据源,此时使用的是实验性的chromeMediaSource约束,一个例子:this demo。需要注意的是屏幕捕获功能需要HTTPS支持,并且只用于开发中,通过一个命令行标志来启用。

九.信令:会话控制,网络和媒体信息

       WebRTC使用RTCPeerConnection在浏览器(别名peer)之间互通数据流,但是需要一种机制去协调通信或者发送控制消息,这个过程被称为信令。WebRTC没有指定信令方法和协议,信令不是RTCPeerConnection API的一部分。
       因此,WebRTC应用的开发者可用选择其擅长的消息协议,比如SIP或XMPP,或者其他合适的双工通信协议。
apprtc.appspot.com 这个例子使用XHR和Channel API作为信令机制。 codelab 是我们通过 Socket.io 构建,运行在 Node server 上的应用。
       信令通常用于交互三类信息:
1.会话控制消息;初始化或者关闭通信,报告错误。
2.网络信息:对于外部而言,我的IP地址和端口是什么?
3.媒体信息:什么编码和分辨率浏览器可以处理,我的浏览器要和谁通信。
       在p2p的流传输之前,必须通过信令成功的交换信息。
       假如Alice想和Bob通信,这里有个简单的例子来自 WebRTC W3C Working Draft ,展示了实际的信令处理过程。例子中假设存在某种信令机制,该机制通过createSignalingChannel()方法创建。注意在Chrome和Opera中,RTCPeerConnection是带有前缀的。
var signalingChannel = createSignalingChannel();
var pc;
var configuration = ...;

// run start(true) to initiate a call
function start(isCaller) {
    pc = new RTCPeerConnection(configuration);

    // send any ice candidates to the other peer
    pc.onicecandidate = function (evt) {
        signalingChannel.send(JSON.stringify({ "candidate": evt.candidate }));
    };

    // once remote stream arrives, show it in the remote video element
    pc.onaddstream = function (evt) {
        remoteView.src = URL.createObjectURL(evt.stream);
    };

    // get the local stream, show it in the local video element and send it
    navigator.getUserMedia({ "audio": true, "video": true }, function (stream) {
        selfView.src = URL.createObjectURL(stream);
        pc.addStream(stream);

        if (isCaller)
            pc.createOffer(gotDescription);
        else
            pc.createAnswer(pc.remoteDescription, gotDescription);

        function gotDescription(desc) {
            pc.setLocalDescription(desc);
            signalingChannel.send(JSON.stringify({ "sdp": desc }));
        }
    });
}

signalingChannel.onmessage = function (evt) {
    if (!pc)
        start(false);

    var signal = JSON.parse(evt.data);
    if (signal.sdp)
        pc.setRemoteDescription(new RTCSessionDescription(signal.sdp));
    else
        pc.addIceCandidate(new RTCIceCandidate(signal.candidate));
};
       首先,Alice和Bob交换网络信息,‘finding candidates’表示通过 ICE framework 查找网络接口和端口。
1.Alice创建一个RTCPeerConnection对象,该对象内置onicecandidate处理器。
2.这个处理器在网络 candidate 生效时 开始运行。
3.Alice通过信令通道发送序列化的数据给Bob,信令通道可以是WebSocket或者其他机制。
4.当Bob收到Alice的candidate消息后,调用addIceCandidate将candidate添加到远端描述。
        WebRTC客户端(别名peer,这里指Alice和Bob)需要明确并交换本地和远程音视频媒体信息,比如分辨率和编码格式。交换媒体信息的信令,是通过 交换会话描述协议(SDP)来实现的。
1.Alice调用了RTCPeerConnection的createOffer()方法,它的回调参数传入的是RTCSessionDescription(Alice的本地会话描述)。
2.在回调中,Alice调用setLocalDescription()方法设置了本地会话描述,然后将该会话描述通过信令通道发送给Bob。注意,RTCPeerConnection并不会采集 candidate直到setLocalDescription()被调用。
3.Bob使用setRemoteDescription()方法将Alice发送给他的会话描述设置为远程会话描述。
4.Bob调用了RTCPeerConnection的createAnswer()方法,并传入它从Alice接收到的远程会话描述,此时一个与Alice兼容的本地会话产生了。 createAnswer()的回调参数传入的是RTCSessionDescription(Bob将它设置为本地会话描述并发送给Alice)。
5.当Alice收到Bob的会话描述,她使用setRemoteDescription()方法将其设置为远程会话描述。
6.Ping
       RTCSessionDescription对象遵从SDP(Session Description Protocol),一个SDP对象看起来如下所示:
v=0
o=- 3883943731 1 IN IP4 127.0.0.1
s=
t=0 0
a=group:BUNDLE audio video
m=audio 1 RTP/SAVPF 103 104 0 8 106 105 13 126

// ...

a=ssrc:2223794119 label:H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810
       交换网络和媒体信息可以同时进行,但这两个过程必须在音视频流开始传输之前完成。

      上述的offer/answer架构被称为JSEP(JavaScript Session Establishment Protocol),JSEP架构如下所示:

WebRTC学习之一:开篇_第1张图片

      一旦信令过程成功,就可以直接进行Caller和callee之间p2p的数据流传输了。

十.RTCPeerConnection

RTCPeerConnection是WebRTC的组件,用来稳定高效的处理端对端的数据流通信。

下图是WebRTC的架构图,标明了RTCPeerConnection扮演的角色。你可能注意到了,绿色部分是相当复杂的。

WebRTC学习之一:开篇_第2张图片

       从JavaScript的角度来看,理解这个图最重要的是理解RTCpeerConnection这一部分。WebRTC对编解码器和协议做了大量的工作,使实时通信成为可能,甚至在一些不可靠的网络中:
1.包补偿
2.回声消除
3.自适应带宽
4.视频抖动缓冲
5.自动增益控制
6.噪声抑制
7.图像清除
       章节九中的例子从信令的角度进行了讲解,下面我们将学习两个WebRTC应用;一个简单的演示了RTCPeerConnection,另一个是功能齐全的视频聊天客户端。

十一.无服务器的RTCPeerConnection

       下面的代码来自https://webrtc.github.io/samples/src/content/peerconnection/pc1,包含基于网页的本地和远程RTCPeerConnection。这个例子中caller和callee 在同一个网页中,能更加清晰的展示RTCPeerConnection API的工作流程,因为RTCPeerConnection对象之间可以直接交换数据和消息,不需要通过中继信道机制。
       一个陷阱:RTCPeerConnection()第二个约束类型的参数是可选的,它与getUserMedia()中使用的约束类型不同。
       本例中pc1表示本地端(caller),pc2表示远程端(callee)
caller
1.创建一个RTCPeerConnection,并通过getUserMedia()添加数据流。
// servers is an optional config file (see TURN and STUN discussion below)
pc1 = new webkitRTCPeerConnection(servers);
// ...
pc1.addStream(localStream); 
2.创建一个offer,并将它设置为pc1的本地会话描述,设置为pc2的远程会话描述。可以直接在代码中设置,不需要使用信令,因为caller和callee在同一个网页中。
pc1.createOffer(gotDescription1);
//...
function gotDescription1(desc){
  pc1.setLocalDescription(desc);
  trace("Offer from pc1 \n" + desc.sdp);
  pc2.setRemoteDescription(desc);
  pc2.createAnswer(gotDescription2);
}
callee
1.创建pc2,接收pc1的数据流,并显示到video元素中
pc2 = new webkitRTCPeerConnection(servers);
pc2.onaddstream = gotRemoteStream;
//...
function gotRemoteStream(e){
  vid2.src = URL.createObjectURL(e.stream);
}

十二.有服务器的RTCPeerConnection

       实际应用中,WebRTC需要服务器,无论多简单,下面四步是必须的:
1.用户通过交换名字之类的信息发现对方。
2.WebRTC客户端应用交换网络信息。
3.客户端交换媒体信息包括视频格式和分辨率。
4.WebRTC客户端穿透NAT网关和服务器。
       换句话说,WebRTC需要四种类型的服务端功能。
1.用户发现和通信
2.信令
3.NAT/防火墙穿透
4.中继服务器,防止端到端的通信失败
       以上这些不在本文讨论范围之内。可以说基于STUNTURN协议的ICE框架,使得RTCPeerConnection处理NAT穿透和其他网络难题成为可能。
       ICE框架用于端到端的连接,比如说两个视频聊天客户端。起初,ICE尝试通过UDP直接连接两端,这样可以保证低延迟。在这个过程中,STUN 服务器有一个简单的任务:使NAT后边的端能找到它的公网地址和端口(谷歌有多个STUN服务器,其中一个用在了apprtc.appspot.com例子)。
WebRTC学习之一:开篇_第3张图片

       如果UDP传输失败,ICE会尝试TCP:首先是HTTP,然后才会选择 HTTPS。如果直接连接失败,通常因为企业的NAT穿透和防火墙,此时ICE使用中继(Relay)服务器。换句话说,ICE首先使用STUN和UDP直接连接两端,失败之后返回中继服务器。‘finding cadidates’就是寻找网络接口和端口的过程。

WebRTC学习之一:开篇_第4张图片

       WebRTC工程师Justin Uberti在幻灯片2013 Google I/O WebRTC presentation中提供了许多关于ICE、STUN和TURN的信息。

十三.一个简单的视频聊天客户端

       如果你觉得这个例子比较难,你也行会喜欢上我们的WebRTC codelab。那里一步步的介绍了如何建立一个完整的视频聊天应用,包括 一个运行于Node server上基于Socket.io的信令服务器。
       apprtc.appspot.com是一个测试WebRTC的好地方,里面有视频聊天的例子,它实现了信令和基于STUN服务器的NAT/防火墙穿透。 这个例子使用adapter.js处理不同的RTCPeerConnection和getUserMedia()实现。

       下面我们详细的过一遍代码。

如何开始

这个例子从initialize()函数开始运行。
function initialize() {
    console.log("Initializing; room=99688636.");
    card = document.getElementById("card");
    localVideo = document.getElementById("localVideo");
    miniVideo = document.getElementById("miniVideo");
    remoteVideo = document.getElementById("remoteVideo");
    resetStatus();
    openChannel('AHRlWrqvgCpvbd9B-Gl5vZ2F1BlpwFv0xBUwRgLF/* ...*/');
    doGetUserMedia();
  }
       需要注意的是,变量room和openChannel()参数的值都是由Google App Engine应用自身提供的。 查看一下index.html template 就知道该赋什么值了。
       这段代码初始化HTML video元素的相关变量,video元素播放来自本地摄像头(localVieo)和远程摄像头(remoteVideo)的视频流。 resetStatus()设置了一条状态消息。
       openChannel()函数建立了WebRTC客户端间的消息通道。
function openChannel(channelToken) {
  console.log("Opening channel.");
  var channel = new goog.appengine.Channel(channelToken);
  var handler = {
    'onopen': onChannelOpened,
    'onmessage': onChannelMessage,
    'onerror': onChannelError,
    'onclose': onChannelClosed
  };
  socket = channel.open(handler);
}

关于信令,本例使用的是Google App Engine Channel API,这使得JavaScritp客户端无需轮询就能实现消息传输。

WebRTC学习之一:开篇_第5张图片

       使用Channel API建立通道的流程大致如下:
1.客户端A生成一个唯一ID。
2.客户端A向Google App Engine应用请求一个通道标识(即openChannel()的参数),并将它的ID传给Google App Engine应用。
3.Google App Engine应用会调用Channel API为客户端ID分配一个通道和一个通道标识。
4.Google App Engine应用将通道标识发给客户端A。

5.客户端A打开socket并监听服务器上建立的通道。

WebRTC学习之一:开篇_第6张图片

       发送消息的流程大致如下:
1.客户端B给Google App Engine应用发送了一个POST请求,要求升级程序。
2.Google App Engine应用给通道发送一个请求消息。
3.消息经通道传递给客户端A

4.客户端A的onmessage回调函数被调用。

WebRTC学习之一:开篇_第7张图片

       重申一次,信令传输机制是由开发者选择的。WebRTC并没有指定信令机制。本例的Channel API能被其他的方式取代,比如WebSocket。
       initialize()调用完openChannel()之后,紧接着调用getUserMedia(),这个函数可以检测出浏览器是否支持getUserMedia API。如果一切顺利, onUserMediaSuccess会被调用。
function onUserMediaSuccess(stream) {
  console.log("User has granted access to local media.");
  // Call the polyfill wrapper to attach the media stream to this element.
  attachMediaStream(localVideo, stream);
  localVideo.style.opacity = 1;
  localStream = stream;
  // Caller creates PeerConnection.
  if (initiator) maybeStart();
}
       这样一来,本地摄像头就能显示在localVideo元素中了。
       此时,initiator被设置成1(直到caller的会话终止),maybeStart()被调用。
function maybeStart() {
  if (!started && localStream && channelReady) {
    // ...
    createPeerConnection();
    // ...
    pc.addStream(localStream);
    started = true;
    // Caller initiates offer to peer.
    if (initiator)
      doCall();
  }
}
       该函数使用了一种巧妙的结构,可以工作于多个异步回调:maybeStart()可能被任何函数调用,但是只有当localStream被定义、channelReady为true且通信还未开始的情况下,maybeStart()才会运行。 因此,当连接还未建立,本地流已经可用,且信令通道已经准备好时,连接才会创建并加载本地视频流。接着started被设置为true。所以连接不会被创建多次 。
RTCPeerConnection: 发起通话
       在maybeStart()中被调用的createPeerConnection(),才是关键所在。
function createPeerConnection() {
  var pc_config = {"iceServers": [{"url": "stun:stun.l.google.com:19302"}]};
  try {
    // Create an RTCPeerConnection via the polyfill (adapter.js).
    pc = new RTCPeerConnection(pc_config);
    pc.onicecandidate = onIceCandidate;
    console.log("Created RTCPeerConnnection with config:\n" + "  \"" +
      JSON.stringify(pc_config) + "\".");
  } catch (e) {
    console.log("Failed to create PeerConnection, exception: " + e.message);
    alert("Cannot create RTCPeerConnection object; WebRTC is not supported by this browser.");
      return;
  }

  pc.onconnecting = onSessionConnecting;
  pc.onopen = onSessionOpened;
  pc.onaddstream = onRemoteStreamAdded;
  pc.onremovestream = onRemoteStreamRemoved;
}
       这段代码的目的是使用STUN服务器建立一个连接,并将onIceCandidate()作为回调函数。 然后给RTCPeerConnection每个事件指定处理器(函数):当会话连接或打开,当远程流被加载或移除。 在本例中,这些处理器只是记录了状态消息——除了onRemoteStreamAdded(),它给remoteVideo元素设置了数据源。
function onRemoteStreamAdded(event) {
  // ...
  miniVideo.src = localVideo.src;
  attachMediaStream(remoteVideo, event.stream);
  remoteStream = event.stream;
  waitForRemoteVideo();
}
       一旦createPeerConnection()在maybeStart()中被调用,就会发起通话,创建Offer并发送消息给对端。
function doCall() {
  console.log("Sending offer to peer.");
  pc.createOffer(setLocalAndSendMessage, null, mediaConstraints);
}
       这里的offer创建过程类似于上面无信令的例子。但是,除此之外,一条消息被发送到了对端,详见setLocalAndSendMessage():
function setLocalAndSendMessage(sessionDescription) {
  // Set Opus as the preferred codec in SDP if Opus is present.
  sessionDescription.sdp = preferOpus(sessionDescription.sdp);
  pc.setLocalDescription(sessionDescription);
  sendMessage(sessionDescription);
}
用Channel API传输信令
        当RTCPeerConnection在createPeerConnection()中成功创建的时候,onIceCandidate()回调函数会触发,并发送关于candidate的信息。
function onIceCandidate(event) {
    if (event.candidate) {
      sendMessage({type: 'candidate',
        label: event.candidate.sdpMLineIndex,
        id: event.candidate.sdpMid,
        candidate: event.candidate.candidate});
    } else {
      console.log("End of candidates.");
    }
  }

        从客户端到服务器的消息外传,是通过sendMessage()方法内的XHR请求实现的。

function sendMessage(message) {
  var msgString = JSON.stringify(message);
  console.log('C->S: ' + msgString);
  path = '/message?r=99688636' + '&u=92246248';
  var xhr = new XMLHttpRequest();
  xhr.open('POST', path, true);
  xhr.send(msgString);
}

        XHR多用于从客户端发送信令消息到服务端,但是某些机制需要用来实现服务端到客户端的消息传输:本例用的是Google App Engine Channel API。 来自此API的消息会传递到processSignalingMessage():
function processSignalingMessage(message) {
  var msg = JSON.parse(message);

  if (msg.type === 'offer') {
    // Callee creates PeerConnection
    if (!initiator && !started)
      maybeStart();

    pc.setRemoteDescription(new RTCSessionDescription(msg));
    doAnswer();
  } else if (msg.type === 'answer' && started) {
    pc.setRemoteDescription(new RTCSessionDescription(msg));
  } else if (msg.type === 'candidate' && started) {
    var candidate = new RTCIceCandidate({sdpMLineIndex:msg.label,
                                         candidate:msg.candidate});
    pc.addIceCandidate(candidate);
  } else if (msg.type === 'bye' && started) {
    onRemoteHangup();
  }
}
       如果消息是来自对端的answer(offer的回应),RTCPeerConnection设置远程会话描述,通信开始。 如果消息是offer(来自callee),RTCPeerConnection设置远程会话描述,发送answer给callee,然后调用RTCPeerConnection的startIce()方法发起连接。
function doAnswer() {
  console.log("Sending answer to peer.");
  pc.createAnswer(setLocalAndSendMessage, null, mediaConstraints);
}
       于是乎,caller和callee都发现了对方并交换相关信息,会话被初始化,实时数据通信可以开始了。
网络技术

       WebRTC目前只实现了一对一的通信,但是可用于更复杂的网络环境:比如,多个peer各自直接通信,即p2p;或者通过MCU(Multipoint Control Unit)服务器来实现流的转发、合成或音视频的录制。

WebRTC学习之一:开篇_第8张图片

       许多WebRTC应用只演示了浏览器间的通信,但是通过网关服务器可以实现WebRTC与telephones(别名PSTN)和VOIP系统直接的通信。 2012年5月,Doubango Telecom开源了sipml5 SIP client,该客户端基于WebRTC和WebSocket,能实现浏览器和IOS或Android应用之间的视频通话。

十四.RTCDataChannel

       除了音频和视频,WebRTC支持其他类型数据的实时通信。
       TCDataChannel API支持p2p低延迟和高吞吐量的二进制数据流交换,这里有个例子:http://webrtc.github.io/samples/src/content/datachannel/datatransfer
       很多领域都潜在地使用到了这个API,比如:
1.游戏
2.远程桌面应用
3.实时文字聊天
4.文件传输
5.分散网络
       充分利用了RTCPeerConnection的多个特性,能实现强大而灵活的p2p通信。
1.利用RTCPeerConnection进行会话设置。
2.通过优先级设置多个同步的channel。
3.可靠和非可靠的语义传递。
4.内建立安全的DTLS和拥塞控制。
5.能用于音视频或其他方面
TCDataChannel API语法与WebSocket类似,包括send()方法和message事件。
var pc = new webkitRTCPeerConnection(servers,
  {optional: [{RtpDataChannels: true}]});

pc.ondatachannel = function(event) {
  receiveChannel = event.channel;
  receiveChannel.onmessage = function(event){
    document.querySelector("div#receive").innerHTML = event.data;
  };
};

sendChannel = pc.createDataChannel("sendDataChannel", {reliable: false});

document.querySelector("button#send").onclick = function (){
  var data = document.querySelector("textarea#send").value;
  sendChannel.send(data);
};
       因为是浏览器间的直接通信,所以RTCDataChannel要比WebSocket快得多,即使通信用到了中继服务器。
       RTCDataChannel可用于Chrome、Opera和Firefox。 出色的Cube Slam游戏使用TCDataChannel API来交换游戏状态:是敌还是友! Sharefest演示了通过RTCDataChannel分享文件,peerCDN提供了WebRTC如何实现p2p内容分发的一种思路。

       更多关于RTCDataChannel的信息,可以参考IETF的draft protocol spec

十五.安全

       实时通信应用或插件会在许多方面忽视了安全性:

1.浏览器之间、浏览器与服务器之间的音视频或其他数据没有加密。
2.应用在用户没有察觉的情况下录制和分发音视频。
3.恶意软件或病毒可能入侵了正常的插件或应用。
       WebRTC的许多特性可以避免这些问题:
1.WebRTC采用类似DTLS和SRTP的安全协议。
2.所有的WebRTC组件强制加密,包括信令机制。
3.WebRTC不是插件:它的组件运行于浏览器沙盒,不是独立的一个进程,这些组件不需要单独安装,且随着浏览器更新。
4.摄像头和麦克风的访问必须经过明确准许,当摄像头和麦克风运行时,界面上会清楚的显示出来。

       关于流媒体安全的讨论超出了本文的范畴。更多信息可参考IETF的WebRTC Security Architecture


原文链接:https://www.html5rocks.com/en/tutorials/webrtc/basics/






你可能感兴趣的:(WebRTC,WebRTC学习)