一、重点参考
1.1 知乎
经常看到WebRTC的点对点的视频， 能不能做一个平台，让别人通过WebRTC播放视频直播，让粉丝都可以看见？ 有什么方案讲讲？
按投票排序按时间排序
米小嘉
可以的. webrtc就是浏览器直接有实时视频功能, 不需要额外的插件, 但有可能是浏览器的默认插件
刘津玮
我所在的项目用这个技术两年多了，先说结论：完全可以！
但是，凡事总有但是，也没那么简单。你以为调用几个Chrome的API就能直播了？too simple
楼上 米小嘉 的回答不对，WebRTC用的不是插件，是Chrome自带的功能，是原生js的API，也没有什么浏览器自带的插件。
楼上 煎饼果子社长 的方法也不对，WebRTC的API不仅仅是给你获取本地信源的，所谓RTC是real time communication的缩写，自然这套API是带传输功能的。所以获取图像信源之后不应该用websocket发送图像数据，而是直接用WebRTC的通信相关API发送图像和声音（这套API是同时支持图像和声音的）数据。
所以，正确的方法是什么呢？
1、你得有一个实现了WebRTC相关协议的客户端。比如Chrome浏览器。
2、架设一个类似MCU系统的服务器。（不知道MCU是什么？看这：MCU（视频会议系统中心控制设备））
第一步，用你的客户端，比如Chrome浏览器，通过WebRTC相关的媒体API获取图像及声音信源，再用WebRTC中的通信API将图像和声音数据发送到MCU服务器。
第二步，MCU服务器根据你的需求对图像和声音数据进行必要的处理，比如压缩、混音等。
第三步，需要看直播的用户，通过他们的Chrome浏览器，链接上你的MCU服务器，并收取服务器转发来的图像和声音流。
先说步骤一，如果你只是做着玩玩，完全可以直接用Chrome浏览器做你的直播客户端。把摄像头麦克风连上电脑之后，Chrome可以用相关的js的API获取到摄像头和麦克风的数据。缺点就是如果长时间直播，Chrome的稳定性堪忧，我不是吓唬你。我们项目的经验是，chrome这样运行24小时以上内存占用很厉害，而且容易崩溃。
第二步，你可能要问，WebRTC可以直接在浏览器之间P2P地传输流，为什么还要有中转的MCU服务器？因为Chrome的功能很弱，视频的分辨率控制、多路语音的混音都做不了，所以需要MCU参与。最重要的是，Chrome同时给6个客户端发视频流就很消耗资源了，所以你如果有超过10个用户收看的话，Chrome很容易崩溃。
第三步就比较简单了，没什么好说的。
最后最后，还是老话题，兼容性。你可以查一下现在支持的浏览器有款，IE据说支持，但是我们研究了一下好像他用的协议和Chrome不一样，不能互通。firefox和opera情况也不是很理想。
说的有道理，受益非浅
mcu类似media Server的角色吧？有点类似red5？
对，类似red5，但是MCU这货是我们自己写的，所以没那么强大的功能，基本上是要什么功能的时候就自己写一个加上去
知乎用户
说的很详细，个人确实感觉中间需要个服务器～
服务器端有免费或收费的软件吗？
http://lynckia.com 你可以参考一下这个
受教了
受教还不去点赞加感谢？！( ╯#-_-)╯┴—┴
(⊙o⊙)…。。已点
2015-04-13
rrKnow
当然可以。
周昌
我弄一个手机视频直播应用，刚刚上线，基于WebRTC技术，Mesh tree的网络架构，浏览器之间走P2P Relay, 正在产品迭代中。产品见: http://yacamera.com
1对N的直播, 一般都是服务器转发的吧.
请问两台电脑，只有一台电脑有摄像头，能不能实现视频传输。WebRTC
鲁强
补充一点，直播应该是流媒体处理及利用上早就有的概念。WebRTC只是提供了一种可以替换现有的直播系统中的流媒体传输及处理的框架。
同时，其它答案也提到了，做直播或者视频内的服务，很多都会牵涉到对流媒体的Mix处理及转发。在这里我需要提醒大家，Video相关的mix在webrtc的底层框架中是没有的，这里有很大的坑，不是那么简单就能填起来的，请大家在做产品预言的时候深入考虑下哦：），Audio相关的Mix倒是在webrtc的底层音频相关的框架中已经有了，很容易就可以被大家拿来使用（虽然chrome啥的，都是只用来做p2p）。
用WebRTC来实现一个支持直播的服务是完全可行的，但是，要做到直播的交互性，以及大规模的并发（比如一个主播，数以千计的观众）这是做直播最需要考虑的问题。WebRTC在这里点上只是提供了一个流媒体的传输途径包括音频、视频编解码的接入等，这些都是可以借鉴或者使用它来作为实现直播的一个部分。但是，只用webrtc，你也只能做一个简单的玩具，做产品的话，请更多考虑产品的应用场景，用户量，带宽需求，服务器搭设及运维。
完全可以，直播我理解是点对多的方式，需要服务器中转分发。
获取信源就用webrtc获取你的桌面或者某应用的图像，可以选择，webrtc的API中可以设置。然后用WebSocket发送到你的服务器(不是唯一的办法，只是这种方法试过可行)，然后转发。
客户端也是一样的原理，websocket接收，直接用html5自带的就能播放信源。
唯一不足，声源需要用类似方法单独处理，因为桌面只有图像，不过原理相似。
1.2基于WebRTC的多人视频会议
25 July 2014
最近两周在调研和搭建基于WebRTC的多人视频会议系统。目前已经搭建成功，可以在http://jitsi.shengbin.me/试用。
这个系统无需注册和登录，只要多人访问同一个URL（含有系统为每个房间分配的特定ID），就可以进行视频会议。如果上面那个链接失效，可以尝试国外一个同样的系统：https://meet.jit.si/。使用视频会议系统需要客户端电脑提供摄像头功能；至于带宽，当然是越大越好了。
下面总结一下该系统的组成。
客户端是一个Web App的形式，包括HTML、CSS、JavaScript代码组成的网页。HTML和CSS来构造聊天室的界面，JavaScript来实现功能。由于功能比较复杂，JS代码也较多。
通过WebRTC，客户端从用户摄像头获取图像并传给服务器，来实现视频会议。由于WebRTC只在Chrome、Opera、Firefox上支持，而Firefox有相关的bug尚未解决，所以客户端只能运行于Chrome或者Opera浏览器。
服务器端包含多个部分。下面分别介绍。
Nginx是一个Web服务器，与著名的Apache同类。它的用途是提供网页访问。
Prosody是一个XMPP服务器。XMPP全称是Extensible Messaging and Presence Protocol，即可扩展通信和表示协议。它是一种即时通信协议，主要是实现文字聊天。
XMPP的前身是Jabber，一个开源的即时通信协议。Jabber被IETF标准化为XMPP。Google Talk用的就是它。
Jitsi-Videobridge用于处理视频传输，也就是视频流在各参与者之间的转发。如果没有这个组件，各参与者能文字聊天，但无法互相看见。
转发意味着服务器要从N个参与者那里接受视频流，然后给每个参与者发送其他N-1个参与者的视频数据，这对服务器带宽要求很高。但由于未对视频做任何处理，CPU负载并不高。
这是一个STUN/TURN服务器。STUN是一种NAT穿透技术，用于帮助处在内网的主机确定自己的公网IP和端口，从而与别的主机建立直接连接（WebRTC中PeerConnection）。TURN是STUN的增强版，可以在无法穿透NAT进行直连的情况下提供数据的转发。
上述整个系统都是开源的，更多信息可参见相关的GitHub代码库和Jitsi主页。
二、基本知识
2.1 信令服务：
想知道信令服务的作用前您先想想通讯双方彼此都不知道对方在哪里，怎么与对方建立连接，怎么给对方发起视频请求？
想到这里我们是不是会想到双方都应该先跟一个服务器建立连接，所以这就是信令服务的作用，具体如下图：
2.2 打洞服务：
打洞的原理理解了其实很简单，主要思路就是通过STUN服务器获取自己的ip,port及NAT信息，
然后通过信令服务器交换这些信息,最后两客户端根据各自得到的ip,port,NAT信息进行相应的穿透，
现在开源STUN代码很多，网上也有很多介绍这方面的问题，有兴趣的可以找相关资料看看.
补充:不过对NAT进步一研究你会发现内网下多重NAT穿透是个比较麻烦的事情，网上有一些专门研究多层NAT穿透的论文,
正因为STUN方式不能完全解决P2P问题,所以后面出现了ICE,而libjingle就是ICE思想的具体实现。
2.3 媒体转发服务：
P2P失败时，客户端先将RTP包发给媒体服务，然后再通过服务器转发给对方，
实际上很多视频会议都是这么实现的,在多人视频通讯的情况下如果都通过P2P来实现则会给客户端带来很大的压力,
特别是手机端负载有限的情况下,这宗点点的转发方式的弊端尤为明显,但如果通过RelayServer,客户端压力可大大减轻。
补充：如果要考虑多人视频，直播，如三方会议同时广播给几千人观看，这就涉及到服务端的编解码，混音，屏幕叠加等等功能，这是一个比较负责的课题，也是语音通信厂商的核心技术，
后面会整理一篇文章专门介绍这方面的内容（在哪里？）。
2.4 基于浏览器的视频通话开发
如果只想做基于浏览器的视频通话功能，不需要去下载编译WEBRTC代码,
因为实现这些功能所需要的JS接口浏览器已经帮你实现了,你只需要简单调用即可,
前面讲的这些内容，如音视频的采集,编码,传输,回声消除,丢包重传，都封装在browser里面了,见下图。
反之，如果你不想做基于浏览器的视频通话，则需要把这些功能集成到你的产品里面，就必须理解这些东西。
下面我们看下基于浏览器的视频通信主要涉及到哪些步骤：
1. 信令交互
开始视频通话前发起端和接收端需要一些交互,
如通知对方开始视频,接收视频,视频参数协商(SDP信息),NAT地址交换,这个过程我们称之为信令交互。
WEBRTC没有定义标准信令格式,既可以使用SIP也可以使用XMPP,还可以使用自定义的信令格式,最简单的方式就是使用websocket或XMLHttpRequest,自定义格式完成信令交互过程.
2. 获取本地视频流
navigator.getUserMedia(constraints, successCallback, errorCallback);
3.SDP协商
createOffer,createAnswer.
4.ICE协商:
5,使用RTCPeerConnection对象在浏览器之间交换媒体流数据.
上面基本上就是浏览器上视频通话涉及的主要对象.
对应到手机端就是webrtc编译成功后的appRTCDemo.apk.
2.5 WebRTC多方通话
2.5.1 扩展:WebRTC多方通话.
或许你可以先看看Justin Uberti提出的IETF标准: REST API for access to TURN Services.
1对1通话之外的用户使用情形很容易想象,
例如:大学之间的视频会议,或者是公共事件处理,一个人说几百个人听.
在网状结构的网络中webrtc客户端能够使用多个RTCPeerConnections与其他各个客户端之间建立连接,talky.io,用的就是这种方法,客户端不多的时候这种方式效果非常好,
只不过这样会占用很大部分的带宽和CPU,特别是对手机端而言.
Full mesh topology: everyone connected to everyone
另外,在星状网络中，webrtc客户端能够选择一个客户端直接发送流数据给其他客户端。
它还可以在服务器上运行一个WebRTC端点并搭建你自己的分发机制(a sample client application is provided by webrtc.org).
从Chrome 31和Opera18开始,来自RTCPeerConnection的Mediastream流数据能够作为其他端点的输入源,Demo链接(simpl.info/multi),这种能够支持更灵活的架构,
因为他使客户端能够选择和哪个远程端点建立呼叫链接.
2.5.2 多点控制单元
对于大批量客户端视频通话，一个更好处理方案是使用Multipoint Control Unit,
他是一个服务器,主要是用来在各客户端之间发布流媒体数据,
MCU能处理视频会议中不同的分辨率,帧率,编码.能够处理转码,做选择性的流媒体转发,混音,音视频数据的录制。
对多人视频来说这里有很多问题要处理,如多人视频怎么显示?混音怎么处理?
像 vLine这样的云平台也正在试着优化网络路由.
如果可能您也可以通过买一个MCU硬件包来创建您自己的路由服务.
The back of a Cisco MCU
开源的MCU软件也有. For example, Licode(previously know as Lynckia) produces an open source MCU for WebRTC; OpenTok has Mantis.
2.5.3 扩展:VOIP,电话和消息
webrtc的标准化属性使得通过浏览器与其他通讯平台的进行通讯是可能的,如电话,视频会议.
SIP就是VOIP和视频会议的信令协议,如果sip客户端要与webrtc客户端之间建立通讯,首选必须有一个服务端来转换信令,
当然如果您的webrtc客户端用的也是sip协议就不用转接了,通讯建立后,就是流媒体的转接,因为两边音视频编码不一样,
所以需要有一个服务端做码流转换,如webrtc用的是VP8视频编码,一般视频会议用的都是H264.
PSTN (Public Switched Telephone Network),他是普通模拟电话的电路交换网络,因此如果webrtc客户端想与电话互通,首先得经过PSTN网关.
同样,webrtc客户端要与遵循Jingle协议的IM客户端互通,其必须有服务器来转换信令,其中Jingle由Google开发的,在XMPP基础上扩展,以支持音视频,Google Talk中用到的就是Jingle. Jingle,不过想与QQ之间互通就有点难了,QQ用的自己定义的格式,不过他们也不想也外面的产品直接互通,至于原因你懂的.
已经有很多产品通过充分利用webrtc来与外部产品进行通讯,如:
sipML5
jsSIP
Phono
Zingaya
Twilio
Uberconference
sipML5的开发者已经创建了webrtc2sip网关,还有webrtc通过使用OpenBTS cell在电话和电脑之间通讯.
2.5.4 更多...
WebRTC codelab: 一步步的操作告诉你怎么创建一个文本和视频的聊天应用,他用的是运行在Node上的Socket.io信令服务.
2013 Google I/O WebRTC presentation with WebRTC tech lead, Justin Uberti.
Chris Wilson's SFHTML5 presentation: Introduction to WebRTC Apps.
The WebRTC Book 给出了详细介绍关于数据和信令通道, 也包括网络拓扑图的细节
WebRTC and Signaling: What Two Years Has Taught Us: TokBox blog post about why leaving signaling out of the spec was a good idea.
Ben Strong's presentation A Practical Guide to Building WebRTC Apps provides a lot of information about WebRTC topologies and infrastructure.
The WebRTC chapter in Ilya Grigorik's High Performance Browser Networkinggoes deep into WebRTC architecture, use cases and performance.
2.6 XMPP和SIP的对比
简介:
XMPP和SIP都是应用层协议,主要用于互联网上发送语音和即时通讯.
SIP在RFC 3621中定义,XMPP在RFC 3920中定义,
XMPP是从即时通讯中演变而来,SIP是从VOIP中演变而来,
XMPP为了会话协商添加了一个扩展叫做Jingle,
SIP 为了即时通讯业务添加了一个扩展叫做SIMPLE.
SIP (Session Initiation Protocol)
SIP是一个应用层协议,是用在类似VOIP这样的场合,
用来建立,修改,中止会话,同时在多人会议中他也能在已有会话中加入新的会话.
基本上SIP是VOIP中的信令协议,它处理呼叫建立,呼叫转移和产生CDR(Call Detail Record,供通话计费用).
XMPP (Extensible Messaging Presence Protocol)
XMPP是一个为即时通讯和请求响应业务服务的XML协议.
最早由Jabber开源社区在1999年开发,2002年XMPP工作组为了更适合即时通讯对Jabber进行了扩展.
SIP和XMPP的异同
其实我们不能简单地拿SIP和XMPP做比对,就像我们不能直接比较比较苹果和橘子,
前者主要是为了会话协商,
后者主要是为了结构化数据交换,
只不过随着各自对Simple和Jingle的引入,他们有了一些相似.
1. SIP提供连接的建立、修改和终止，
而XMPP在客户端内部提供流管道，交换结构化数据。
也就是说：SIP的重点是终端之间连接的建立和维护，连接以后的数据和信息传送他不关注；而XMPP重点是考虑终端内部的数据交换，连接建立是基本的功能，而不是重点。
所以，XMPP对应用的支持和扩展性的考虑很充分,比SIP天生要好.
2. SIP的信令和消息传送是基于文本的，不太好解析,或者说解析起来缺少规律性,在新增数据消息体的时候缺少继承性,需要开发新的代码来封装和解析,原有代码的继承性比较差。而XMPP采用XML，是一种结构化的消息结构，能够方便地表达层次化的内容，以及内容之间的内在逻辑。这种XML结构对应用的扩展和内容的解析带来极大的方便，大量软件代码可以复用。
3. SIP信令由header和body两部分组成，也就是说，SIP报文格式的header已经包含了部分内容,类似于HTTP,与具体的上层应用直接关联，而不是通用的报文格式；
而XMPP所有信息都是采用XML在流管道之间透明传送。
SIP的连接建立通道与数据传送通道是各自独立的，连接建立在SIP client与Server之间，而数据传送通道是在Client--Client之间直接进行的。
这个对视频、语音和文件传送业务很合适，但是不适合其他形式的应用。
XMPP的控制和数据通道是一体的，Clent只与Server建立连接，而Client与Client之间是没有之间连接的。Client之间传送的通道是：Client1---〉Server1---〉Server2---〉Client2。这种方式看起来扩展性差，server压力很大，但是能够实现很好的业务功能，比如留言、广播、群聊、状态更新、Blog、微博、数据共享等等。
这种C-S模型，很多业务的控制在Server上完成，新功能的增加在server上实现，在server上定义新的XML对象和逻辑，客户端只要负责XML数据流的解析和呈现就可以了,所以，终端实现简单
4. SIP可以使用UDP,TCP,TLS进行传送,而XMPP仅仅使用TCP和TLS进行发送.
5. SIP是双向对称，客户端和服务器都可以主动发起连接请求并响应，这种对称连接的方式在穿越NAT和Firewall的时候很麻烦，无法保证穿越NAT。
而XMPP是单向的连接，只有Client可以向Server发起连接请求，
Server不会向Client发起连接。这样便于NAT和Firewall的穿越。
三、kurento
折腾了一个多星期终于将kurento的环境搭建好（开发阶段的产品，有些BUG要自己解决），所以单独写篇文件来介绍。
下面开始介绍kurento，文章来自博客园RTC.Blacker，转载请说明出处。
3.1 、kurento是什么？
搞视频会议就会涉及一对多、多对多、广播、转码、混音、合屏、录制，这就需要用到流媒体服务器，而kurento就具有这些功能。
他主要用来作为webrtc的流媒体服务器，因为BUG多，目前不适于商用，不过前景可期，具体说明见下图：
说明：
1、看到这里您可不要讲他的功能和ICE服务器的功能给搞混了哦，后者主要用来做NAT穿透和转发的。
3.2 、kurento架构
说明：
1、客户端对音视频数据的采集和播放等是通过webrtc来处理的，传输模块就是kurento的。
2、流媒体服务是他的核心服务，可以进行编解码，混音，录制，计算机视觉，视觉增强等等。
3.3 、特色功能---计算机视觉
说明：
1、服务端可以对收到的视频流进行处理，如人脸识别，这些扩展下去应用前景就很广泛了，期待！
2、因为他对图像进行了处理，所以延迟会比较大，识别率还存在些问题，而且会造成图像闪动（可能也是跟延迟有关）。
3、其他功能如一对一，广播就不重复了，很多其他流媒体服务都具有这些功能。
最后：虽然kurento目前问题很多，但我看好他，后面会继续分享相关内容，也会和他们一起去完善这个东西。