【zz】webrtc信令

-知乎
可以，但不建议。从直播架构上，目前成熟的方案有很多，webrtc本来是适用p2p的业务，即两端对等，直播业务的特点是一对多。其余答主都是从客户端实现容易程度回答，对于流媒体业务，业务开发都不是最难的，最困难莫过于保证大规模下用户的高质量QOE，webrtc的拥塞控制和传输层机制，pacing，pading 和 budget有很延迟发送，和加冗余包探测带宽的做法，这些default设置明显不适合大规模直播业务。直播业务，目前大家都在关注如何低时延，关注主播端upload的稳定性，从转码到CDN传输，客户端ABR的设计等另外大家提到的跨平台开发，建议学习swig，通过底层将API统一封装成跨平台。

作者：昨日围城
链接：https://www.zhihu.com/question/25497090/answer/679533068
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

• 转载

注1：主叫发出Offer后就有可能向服务器发onIceCandidate，但服务器要等收到被叫发出startProcessed后，才会把这些onIceCandidate转为iceCandidate发向被叫。
注2：类似注1。被叫发出Answer后就有可能向服务器发onIceCandidate，但服务器要等收到主叫发出answerProcessed后，才会把这些onIceCandidate转为iceCandidate发向主叫。
注3：在服务器发出的消息中，除了这条startCommunication，其它可都认为是中转。服务器在收到被叫发出的incomingCallResponse之后会向被叫发此条消息。
注4：“stop”由率先想关闭聊天的发出，对方会收到“stopCommunication”。
注5：主叫执行CreateOffer、被叫执行CreateAnswer，都需要一定时间，执行结束后会调用observer的OnSuccess，在OnSuccess首先会执行SetLocalDescription。

注6：这两条requestCall不属于“标准”信令服务器，只是为启动呼叫。被叫一旦发出requestCall后就进入“等待对方接收”状态。

作者：花椒技术
链接：https://www.zhihu.com/question/25497090/answer/719167680

基本概念

• SDP： 即会话描述协议，主要保存当前会话的媒体和传输信息，其中媒体信息包括媒体类型、传输协议、媒体格式等，传输信息包括媒体的远程地址信息、带宽等；它由多行kv格式的文本信息组成，具体可参考这里。（https://tools.ietf.org/pdf/draft-nandakumar-rtcweb-sdp-08.pdf）

• Offer： 通信的发起方对自己的sdp描述Answer： 通信的接收方对自己的sdp描述信令： 协调发起方、接收方通信的数据信息，其中包括sdp描述信息、会话控制信息（节点加入、退出及各类的业务控制信息等）、网络信息、错误信息等。

• webrtc通信基于webrtc的点对点音视频通信示意图如下图所示：
  

• 其具体的流程如下：客户端A初始化本地音视频设备，创建一个用于offer的SDP对象，其中SDP对象中保存当前音视频的相关信息；客户端A通过信令服务器将SDP信息发送给客户端B；客户端B在接收到客户端A发送的SDP信息并保存后，初始化本地音视频设备并创建用于answer的SDP对象；客户端B通过信令服务器将SDP信息发送给客户端A；客户端A、B通过交换SDP等信息，建立P2P通道进行音视频传输

• Webrtc ICE（交互式连接建立）在现实世界中，客户端A、B大部分位于NAT之后，只具有一个内网访问的私有ip，不足以提供足够的信息来建立一条端对端的连接。为了克服由NAT产生的网络问题，一般情况下，webrtc采用ICE框架，通过ICE来找到一条对等连接的最佳道路。

• 举个栗子，小A和小B是好朋友，某天他们都换了手机号，而且都绑定了一个手机短号（短号不在一个集团网中），然而都忘记新的号码是多少。为了两个人通话联系，小A尝试用短号拨号不通后，小A拨打114询问自己的电话号码，114看到来电显示后将手机号告诉小A；小B以同样的方式获得了自己的手机号；这样两人就可以相互通话了。类似于上边的例子，客户端A和客户端B处在不同的内网环境中，首先ICE尝试采用从操作系统和网卡获得的主机地址建立连接，如果连接建立失败，ICE会发送binding request给STUN服务器，服务器探测到客户端A的公网地址后将信息加在binding request中，并返回给客户端A，这样客户端A获取到了自己的公网地址。以同样的方式客户端B获取到自己的公网地址。这样，客户端A、B就可以将SDP中的地址信息替换为公网地址进行通信了。

• 

• 然而，有些情况并不是那么顺利，比如114显示小A、小B电话未知来电或者小A、小B通话线路故障等原因，导致小A、小B不能通话。这个时候114说，要不这样吧，我给你们各发一个临时号，如果你们要通信，我直接按照你们的临时号给中转一下通话信息。同理，webrtc中，如果STUN建连失败，可以采用TURN服务器的方式。TRUN可以担任中间人的角色，将客户端A、B的数据进行中继转发，实现不同内网的客户端通信。

• Stun/turn服务器可以采用coturn（https://github.com/coturn/coturn），服务器验证方式可以参考这里（https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/）。

• Webrtc与直播：以下根据自己的理解，简要的说明几种直播方案的优缺点。

• 1、rtmp方式众所周知，目前主流的直播方案一般采用rtmp方式，首先客户端采集音视频流，并通过rtmp协议推流到流媒体服务器，流媒体服务器做一些编码处理等将流分发给各个客户端，进而拉流播放。出于成本、安全等考虑，可能会将不同流按照一定的配比推送到不同的流媒体服务商，在特殊情况下可采用调度方式进行切流处理。

• 

• 优点：CDN 支持良好，主流的 CDN 厂商都支持技术比较成熟，集成方便，例如声网、即构等，集成对应平台的sdk即可进行推流。相较于端对端的webrtc方式，并发度高，适合多人直播场景；

• 缺点：协议基于tcp，相对于webrtc方式延时较大，对于某些低延时场景体验较差；不支持浏览器推流等；

• 2、基于端对端的webrtc基于端对端的webrtc方式，严格来说不属于常规的直播场景，其主要适用于人数较少的视频会议等场景，各个节点分别建立p2p连接进行音视频的传输，主要工作流程如上边webrtc所示。

• 优点：在web端，对于开发者和使用者来说，音视频通信的开发和使用简单化；对于开发者来说，门槛低，不必熟悉流媒体，仅调用js api即可实现；对于使用者来说，打开浏览器等浏览器即可。点对点通信，节省服务器带宽费用。相对于基于tcp的rtmp推拉流方式，支持udp的webrtc方式延时低。

• 缺点：客户端浏览器的性能有局限。如果是1v1方式的直播连麦，尚好；如果多人同时进行直播连麦，浏览器需要同时给多人进行视频传输，性能欠佳。音视频处理相对来说比较困难。webrtc开放的api接口较少，集成第三方音视频处理方案较难，比如秀场直播的美颜等。音视频的传输质量难以保障，尤其在跨地区、跨运营商的情况下，仅能做一下端对端质量控制算法，无法保障。兼容性问题。

• 在pc端，目前的主流浏览器都支持webrtc，但是在移动端，只有部分浏览器支持（目前国内的主流手机浏览器均不支持）。关于直播内容的后续工作不好展开，内容质量难以把控。比如rtmp推拉流方式生成的回放、内容审核等很难处理了。

3、基于媒体服务器的webtrc直播：

• 基于端对端的webrtc受限于客户端性能、连接人数等限制，很难适用于直播场景。为了解决这些问题，可以引入媒体服务器，客户端仅传输一路音视频流到媒体服务器，其余客户端通过与媒体服务器建立连接进行音视频显示。
• 目前开源的主流webrtc媒体服务器如下：
• Kurento（https://github.com/Kurento/kurento-media-server）
• licode（https://github.com/lynckia/licode）
• janus（https://github.com/meetecho/janus-gateway）
• 优点：相对于端对端的webrtc方式，避免了客户端性能低、音视频处理、内容审核等问题，支持更为复杂的应用场景；支持多人进行同时观看直播，并发度高；在web端集成相对简单容易，采用浏览器即可接入，且延时较低；
• 缺点：该种方式相对于端对端的webrtc方式，开发成本较高，需要实现自己的媒体服务器，而目前没有比较成熟的方案。相对于成熟的rtmp配套解决方案，周边设施相对较少。
• 综上所述，基于端对端的webrtc直播的方式不适合直播场景；基于媒体服务器的webtrc直播，目前还没有成熟的解决方案，需要自己实现媒体服务器，门槛较高，具体可根据开发成本与收益进行定夺。
  -我们是花椒技术，如果想了解更多内容请关注我们的公众号：花椒技术http://weixin.qq.com/r/bRM7I8bEx5u4rYJA90Z-123 (二维码自动识别)