WebRTC媒体协商01 流程介绍

已于 2024-09-23 20:40:02 修改
阅读量998 收藏 18
点赞数 21
分类专栏： WebRTC 文章标签： webrtc 媒体
于 2024-09-23 19:02:15 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Ziwubiancheng/article/details/142465999
版权

一、媒体协商的重要性：

为了更好地说明这一点，我将通过一个小故事来解释：

想象一下，在一个战争时代，一名地下党员小李深入某个棉被厂充当的卧底。上级下达了一项刺杀任务，这引发了几个关键问题：

  • 刺杀目标是谁？（接收者信息）
  • 哪条路最为迅速？（路线选择）
  • 应当使用何种型号的子弹？ 如果我使用的是三八大盖的枪，而你送来的却是汉阳造的子弹，那么就无法使用了。（传输内容信息）
  • 在传送过程中如何确保敌人无法发现子弹？ 例如，可以将子弹藏在一个带锁的箱子内。（传输加密）

通过这个三流的故事，我们可以得出结论：要想与某人进行通信，我们需要了解以下几个关键点：

  • 接收者的位置在哪里？（IP 地址 + 端口号）
  • 哪条路径最为优化？（ICE + Candidate 选路）
  • 应当发送何种类型的“子弹”？（即呼叫者和被呼叫者的一些能力，例如对音视频编解码器的支持情况）
  • 如何确保在传输过程中“子弹”不会被发现？（即对传输内容进行加密）

通过这种“生动”的对比，媒体协商的重要性得以清晰展现。就是开始通话之前我们先互相了解下对方的条件（如：音视频编解码器、使用的传输协议、IP 端口和传输速率等等），这个条件是通过“信令服务器”以SDP的方式交换的。

二、WebRTC中媒体协商的流程：

下图中Amy是呼叫端，Bob是被呼叫端，中间Signaling Channel是一个他俩都能访问到的“信令服务器”，我们通过这个图说清楚媒体协商的过程。

在这里插入图片描述

  1. CreateOffer：Amy创建一个本地Offer，并通过信令服务器发送给Bob；
  2. SetLocalDescription：Amy同时将创建的本地Offer保存到自己的local_description中；
  3. setRemoteDescription：对Bob来说，收到的Amy Offer信息就是远端的信息，因此保存到自己的remote_description中；
  4. CreateAnswer：Bob创建一个Answer信息；
  5. SetLocalDescription：将Answer信息存储到本地的local_description当中，并开始协商；
  6. Bob将Answer发送给Amy；
  7. SetRemoteDescription：Amy收到Bob发送过来的Answer，存储到自己的remote_description当中，并开始协商；

备注：

  • 上面说的offer和answer都属于SDP信息，也就是一个json字符串，里面描述了自己的能力（编解码能力、协议、码率等）；

  • 上面说的“协商”就指的是根据offer和answer，提取两者都支持的最优能力；

  • 媒体协商的最终结果就是，双方都创建了一个RTCPeerConnection（可以简单理解成一个超级socekt），后面就可以直接发送音视频数据了；

  • 还有一个非常重要的动作，就是收集candidate；（当然是并行同时发送Offer给对端，也就是说Offer里面并没有包含candidate，因为还正在收集）

  • Amy收到对端Answer才开始协商，Bob在发送Answer之前就开始协商了；

三、媒体协商前端代码：

上面知道了流程，如果我们在浏览器想使用webrtc的WebAPI，应该使用什么样的流程呢？

  1. 呼叫方创建并发送offer：

    var pcLocal = new RTCPeerConnection(opts1); 

pcLocal.createOffer((offer)=>{    
  pcLocal.setLocalDescription(offer);  
  singalChannel.send(offer)
}, handleError);

  2. 被呼叫方收到offer：

    var pcRemote = new RTCPeerConnection(opts2);

signalChannel.on('message', (message)=>{  
  if(message.type === 'offer'){    
    pcRemote.setRemoteDescription(        
        new RTCSessionDescription(message)
    )  
  }
})

  3. 被呼叫方创建并发送answer：

    pcRemote.createAnswer((answer)=>{  
  pcRemote.setLocalDescription(answer);  
  singalChannel.send(answer);
}, handleError );

  4. 呼叫方收到answer：

    signalChannel.on('message',(message)=>{  
  if(message.type==='answer'){    
    pcLocal.setRemoteDescription(        
        new RTCSessionDescription(message)
    )  
  }
})

四、媒体协商状态机：

为了提高媒体协商过程的可靠性、可维护性和灵活性，引入状态机管理协商状态；

1、状态转移图如下：

在这里插入图片描述

  • 记住，每次设置完成之后，只有我们的状态机回到“Stable”状态，这样下次才可以工作；

  • 状态机对呼叫方和被呼叫方都有一个；

  • 状态解释：

    • stable：当创建完RTCPeerConnection实例之后，便处于stable状态；
    • have-local-offer：当调用setLocalDescription之后，便成了have-local-offer状态；
    • have-remote-offer：被呼叫段收到呼叫端发送的offer之后；
    • have-local-pranswer：就是被呼叫端提前应答；一般是媒体数据没有准备好的时候，提前应答节约时间；那这个临时的answer有一个特点，就是它没有媒体数据也就是说没有音频流和视频流，并且将这个发送的方向设置成send only；这样，可以先进行ICE收集candidate，和进行DTLS握手；
    • have-remote-pranswer：呼叫端收到被呼叫端发送来的pranswer之后，设置为这个状态（记住此时非stable，不能操作RTCPeerConnection）；

  • 状态机运行：

    • 理想情况下：呼叫方（1->2->3），被呼叫方（6->7->9)

      • 开始创建这个RTCPeerConnection的时候，处于stable状态，但是这个时候还不能进行编解码，因为没有进行媒体协商；

      • 呼叫方创建offer，并调用setLocalDescription将offer传进去，状态变化：stable -> have-local-offer;

      • 当被呼叫端收到offer之后，调用setRemoteDescription将offer设置进去，状态变化：stable->have-remote-offer;

      • 被呼叫方创建answer之后，调用setLocalDescription将answer设置进去，状态变化：have-remote-offer -> stable;

      • 呼叫方收到answer之后，调用setRemoteDescription将answer设置进去，状态变化：have-local-offer -> stable；

      • 这时候双方都回到stable状态了，因此就可以继续使用RTCpeerConnection来进行编解码、传输等操作了；

    • 特殊情况：呼叫方（1->2->4->5）被呼叫方(1->6->7->8)

      • 开始创建这个RTCPeerConnection的时候，处于stable状态，但是这个时候还不能进行编解码，因为没有进行媒体协商；
      • 呼叫方创建offer，并调用setLocalDescription将offer传进去，状态变化：stable -> have-local-offer;
      • 被呼叫方收到offer之后，进行setRemoteDescription，将offer设置到本地，状态变化：stable -> have-remote-offer;
      • 被呼叫方可能因为暂未收集好媒体数据，先生成一个pranswer，状态变化：have-remote-offer -> have-local-pranswer；
      • 呼叫方收到对端的pranswer之后，调用setRemoteDescription设置到自己本地，状态变化： have-local-offer -> have-remote-pranswer;
      • 这个时候双方可以提前走后续的ICE收集candidate、dtls等流程；
      • 被呼叫方收集好媒体数据之后，生成一个answer，调用setLocalDescription设置进本地，状态变化：have-local-pranswer -> stable;
      • 呼叫方收到对端的answer之后，调用setRemoteDescription将answer设置进本地，状态变化：have-remote-pranswer -> stable:
      • 这时候双方都回到stable状态了，因此就可以继续使用RTCpeerConnection来进行编解码、传输等操作了；

2、时序图：

在这里插入图片描述

1）上面主要分为三部分：协商部分、candidate收集部分、数据流部分

2）呼叫段发送Offer的同时，也会去向sturn/turn服务器发送bind request；

3）等sturn/turn收集完所有通路之后，就会通过onIceCandidate回复过来；

4）然后再A这边通过信令服务器发送candidate给B；

5）B将A的通路进行排序，然后选择最优的，然后，同时将candidate发送给A；

6）A收到之后也检测下连通性；

7）然后就通过P2P去穿越发送媒体流给B；

8）B收到之后不会立即显示，会通过onAddStream添加到本地，然后向上抛给渲染模块显示

五、SDP：

上面说的协商过程中发送的offer和answer都是一种SDP格式的信息，SDP 全称 SessionDescription Protocal，直译就是通用会话描述协议。

1、SDP结构：

在这里插入图片描述

  • 会话层：基本是对全局会话的说明，信息量比较小，包括会话的名称、目的、存活时间等；
  • 媒体层：媒体层非常重要，包括媒体格式、传输协议、ip和端口（webrtc没有使用这个，使用的是ice）、媒体负载类型；
  • 格式：json格式，由多条"="组成；这儿暂时不分析，直接分析webrtc里面具体的sdp；

2、WebRTC中的SDP：

webrtc中的SDP和标准的SDP规范有所不同，主要是按照功能划分了如下五大部分：

在这里插入图片描述

3、关键字段说明：

  • ICE-FULL和ICE-LITE：

    • 为了验证服务器给我的candidate是否正确，需要发送stun request，对端回复stun response；

    • ice-full客户端和服务端都要发送stun request，为了提高效率ice-lite只需要客户端发送即可；

    • 一般服务器都默认是ice-lite；

  • PlanB和UnifiedPlan：

    • PlanB 和 UnifiedPlan 其实就是 WebRTC 在多路媒体源（multi media source）场景下的两种不同的 SDP 协商方式。如果引入 Stream 和 Track 的概念，那么一个 Stream 可能包含 AudioTrack 和 VideoTrack，当有多路 Stream 时，就会有更多的 Track，如果每一个 Track 唯一对应一个自己的 M 描述，那么这就是 UnifiedPlan，如果每一个 M line 描述了多个 Track(track id)，那么这就是 Plan B；

    • PlanB比较古老，除非考虑兼容性，否则直接用 UnifiedPlan；

4、实例分析：

// 【1】会话层
// sdp版本号为0
v=0
// owner的名字不写，会话id是7595655801978680453，会话版本是2（后面如果有类似改变编码的操作，sess-version加1），地址类型为IP4，地址为127.0.0.1（这里可以忽略）
o=- 7595655801978680453 2 IN IP4 127.0.0.1
// session名字为空
s=-
// 会话的起始时间，都为0表示一直存活
t=0 0
a=ice-lite
// 音频、视频的传输的传输采取多路复用，在底层传输层使用同一个通道尽心传输
a=group:BUNDLE 0 1
// WMS是WebRTC Media Stram的缩写，这里给Media Stream定义了一个唯一的标识符。一个Media Stream可以有多个track（video track、audio track），这些track就是通过这个唯一标识符关联起来的，具体见下面的媒体行(m=)以及它对应的附加属性(a=ssrc:)
a=msid-semantic: WMS 5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV
// 【2】媒体层
// [2.1] 音频描述
// [2.1.1] m行
// 表示媒体是音频，可以向我的端口x发送数据（9其实表示这个端口无意义），采用UDP传输加密的RTP包，并使用基于RTCP的音视频feedback机制来提升传输质量，
// 后面的数字是payload type
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 126
// [2.1.2]a行，对前面m行补充说明
// 音频发送者的IP4地址，WebRTC采用ICE，这里的 0.0.0.0表示任意端口
c=IN IP4 0.0.0.0
// RTCP采用的端口、IP地址（webrtc同样没有使用）
a=rtcp:9 IN IP4 0.0.0.0
// ice-ufrag、ice-pwd 是ice协商时候使用，会话建立的时候我先把我的用户名密码发送给你，你建立会话之后再发送给我，
// 如果我校验不是我原来的用户名和密码，我就终止会话
a=ice-ufrag:58142170598604946
a=ice-pwd:71696ad0528c4adb02bb40e1
// 表示我使用的trickle协议，原来的是会话建立的时候，我先要将本地的所有candidate都收集完成，然后，再通过信令服务器交换给你，
// 现在是SetLocalDescription将我本地的发送给对端之后，我就同时开始收集本地candidate，我收集到一个发现比之前的好，
// 就替换掉之前的，循环往复；
a=ice-options:trickle
// 指纹，我先把我自己的指纹发送给你，待会儿通过dtls进行证书交换的时候，对方收到了证书之后，通过证书生成一个指纹，
// 和之前你发送的一样的话，表示这个会话是值得信任的，否则，不进行通话；
a=fingerprint:sha-256 7F:98:08:AC:17:6A:34:DB:CF:3B:EC:93:ED:57:3F:5A:9E:1F:4A:F3:DB:D5:BF:66:EE:17:58:E0:57:EC:1B:19
// 表示我们谁作为服务端，谁作为客户端，由你（answer）说了算
a=setup:actpass
// 当前媒体行的标识符（在a=group:BUNDLE 0 1 这行里面用到，这里0表示audio）
a=mid:0
// RTP允许扩展首部，这里表示采用了RFC6464定义的针对audio的扩展首部，用来调节音量，比如在大型会议中，有多个音频流，就可以用这个来调整音频混流的策略
// 这里没有vad=1，表示不启用这个音量控制
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
// 表示既可以发送音频，也可以接收音频
a=sendrecv
// 表示我支持rtp和rtcp端口复用
a=rtcp-mux
// 下面几行都是对audio媒体行的补充说明（针对111），包括rtpmap、rtcp-fb、fmtp
// 表示我对下面将对前面payload type为111的进行说明
a=rtpmap:111 opus/48000/2
// rtcp-fb：基于RTCP的反馈控制机制
a=rtcp-fb:111 transport-cc
a=rtcp-fb:111 nack
// 最小的音频打包时间
a=fmtp:111 minptime=20
// 跟前面的rtpmap类似
a=rtpmap:126 telephone-event/8000
// ssrc用来对媒体进行描述，格式为a=ssrc:<ssrc-id> <attribute>:<value>，具体可参考 RFC5576
// cname用来唯一标识媒体的数据源
a=ssrc:16864608 cname:YZcxBwerFFm6GH69
// msid后面带两个id，第一个是MediaStream的id，第二个是audio track的id（跟后面的mslabel、label对应）
a=ssrc:16864608 msid:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV 128f4fa0-81dd-4c3a-bbcd-22e71e29d178
a=ssrc:16864608 mslabel:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV
a=ssrc:16864608 label:128f4fa0-81dd-4c3a-bbcd-22e71e29d178
// 跟audio类似，不赘述
m=video 9 UDP/TLS/RTP/SAVPF 122 102 125 107 124 120 123 119
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:58142170598604946
a=ice-pwd:71696ad0528c4adb02bb40e1
a=fingerprint:sha-256 7F:98:08:AC:17:6A:34:DB:CF:3B:EC:93:ED:57:3F:5A:9E:1F:4A:F3:DB:D5:BF:66:EE:17:58:E0:57:EC:1B:19
a=setup:actpass
a=mid:1
a=extmap:2 urn:ietf:params:rtp-hdrext:toffset
a=extmap:3 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:4 urn:3gpp:video-orientation
a=extmap:5 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:6 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=sendrecv
a=rtcp-mux
// 正常的rtcp包括对端带宽估计、丢包信息等，这表示可以为了节省带宽，你只发送丢了哪些包即可；
a=rtcp-rsize
// 表示我对下面将对前面payload type为122的进行说明
a=rtpmap:122 H264/90000
// 表示在 SDP 中为 RTP 负载类型为122的媒体流启用了对 FIR 的 RTCP 反馈机制，用于接收端向发送端请求发送关键帧
a=rtcp-fb:122 ccm fir
// 表示在 SDP 中为 RTP 负载类型为122的媒体流启用了 NACK 的 RTCP 反馈机制，用于在传输过程中检测和处理丢包情况
a=rtcp-fb:122 nack
// 用于在传输过程中检测丢包情况，而 PLI 是 Picture Loss Indication 的缩写，用于指示接收端需要一个关键帧（I帧）
// 来正确解码和显示视频。当接收端检测到丢包或图像帧损坏时，它可以发送NACK反馈请求重新发送丢失的数据包，
// 并且发送 PLI 请求以请求发送端发送一个关键帧
a=rtcp-fb:122 nack pli
// 表示在 SDP 中为 RTP 负载类型122配置了Google提出的 REMB 反馈机制，
// 用于接收端向发送端报告估计的最大比特率，以优化传输和编码参数的调整
a=rtcp-fb:122 goog-remb
// 在 SDP 中为 RTP 负载类型为 96 的媒体流启用了 Transport-CC RTCP 反馈机制，用于实现传输方向上的拥塞控制
a=rtcp-fb:122 transport-cc
a=fmtp:122 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
// 表示在 SDP 中定义了 RTP 负载类型为102的媒体流，并指定了使用 RTX 作为重传机制
a=rtpmap:102 rtx/90000
// 表示在 SDP 中为 RTP 负载类型为102的媒体流定义了特定的参数设置，其中指定了负载类型102是负责重传负载类型122的数据包。
// 这种设置通常与 RTX（Retransmission Transmission）相关联，用于处理数据包的重传机制
a=fmtp:102 apt=122
a=rtpmap:125 H264/90000
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:124 H264/90000
a=rtcp-fb:124 ccm fir
a=rtcp-fb:124 nack
a=rtcp-fb:124 nack pli
a=rtcp-fb:124 goog-remb
a=rtcp-fb:124 transport-cc
a=fmtp:124 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=4d0032
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:123 H264/90000
a=rtcp-fb:123 ccm fir
a=rtcp-fb:123 nack
a=rtcp-fb:123 nack pli
a=rtcp-fb:123 goog-remb
a=rtcp-fb:123 transport-cc
a=fmtp:123 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=640032
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=ssrc-group:FID 33718809 50483271
a=ssrc:33718809 cname:ovaCctnHP9Asci9c
a=ssrc:33718809 msid:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV 1d7fc300-9889-4f94-9f35-c0bcc77a260d
a=ssrc:33718809 mslabel:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV
a=ssrc:33718809 label:1d7fc300-9889-4f94-9f35-c0bcc77a260d
a=ssrc:50483271 cname:ovaCctnHP9Asci9c
a=ssrc:50483271 msid:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV 1d7fc300-9889-4f94-9f35-c0bcc77a260d
a=ssrc:50483271 mslabel:5Y2wZK8nANNAoVw6dSAHVjNxrD1ObBM2kBPV
a=ssrc:50483271 label:1d7fc300-9889-4f94-9f35-c0bcc77a260d
红米饭配南瓜汤
关注
专栏目录
【WebRTC---源码篇】（九）媒体协商与网络传输(持续更新)
用可见的方式来记录和分享每一次收获
06-06 308
媒体协商
WebRTC源码-信令之六：SDP协议与协商流程
北雨南萍
09-08 826
SDP（Session Description Protocol）是一个用来描述多媒体会话的应用层控制协议，它是一个基于文本的协议，用于会话建立过程中的媒体类型和编码方案的协商等.它不属于传输协议,它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。SDP协议是也是基于文本的协议，这样就能保证协议的可扩展性比较强，这样就使其具有广泛的应用范围。
【万字长文】WebRTC浅析与实战
随风丶逆风的博客
09-02 1377
推荐阅读时长25分钟 前言 目前市场上音视频技术方案大致分为以下几类，WebRTC因其超低延时、集成音视频采集传输等优点，是在线教育、远程会议等领域首选技术。 方案 优势 劣势 应用场景 基于浏览器插件的flash播放RTMP 即将淘汰 即将淘汰 传统直播 跨平台的HLS/DASH 播放方案 - 跨端广泛支持：苹果浏览器原生支持 - hls.js - 延时高 - 碎片化 传统直播，如赛事直播、大型会议直播 基于HTML5 MSE 能力的flv播放技术 - 格式简单 - 无需.
webrtc 信令交换过程
清澈见底的专栏
06-29 2394
WebRTC是HTML5支持的重要特性之一，有了它，不再需要借助音视频相关的客户端，直接通过浏览器的Web页面就可以实现音视频对聊功能。而且WebRTC项目是开源的，我们可以借助WebRTC源码快速构建自己的音视频对聊功能。无论是使用前端JS的WebRTC API接口，还是在WebRTC源码上构建自己的对聊框架，都需要遵循以下执行流程： 上述序列中，WebRTC并不提供Stun服务器和Signal...
WebRTC（三）媒体协商技术
u010029439的博客
01-26 358
WebRTC通过ICE技术可以实现客户端P2P连接，但是在两端进行P2P连接前还需要先进行媒体协商。WebRTC媒体协商技术主要包括两部分：一部分是SDP（Session Description Protocol）协议，另一部分是JSEP（JavaScript Session Establishment Protocol）协议。 SDP协议 SDP协议，即会话描述协议，它提供一种描述实时音视频通信所需的各种参数的通用描述，是一个文本信息。简单来说，SDP就是客户端的各端的音视频实时通信的能力，能力指的是
【WebRTC】音视频通信
weixin_42910765的博客
05-29 1582
比如想用 socket 连接某台服务器，一定要知道这台服务器的一些基本信息，如服务器的 IP 地址、端口号以及使用的传输协议。只有知道了这些信息，才能与这台服务器建立连接。而 Candidate 正是 WebRTC 用来描述它可以连接的远端的基本信息，因此 Candidate 是至少包括 IP 地址、端口号、协议的一个信息集。
WebRTC媒体协商及实践
fuxuan_7的博客
10-10 860
WebRTC 处理流程图： WebRTC 终端，负责音视频采集、编码、NAT穿越、音视频数据传输。 Signal服务器，负责信令处理，如加入房间、离开房间、媒体协商消息的传递。 STUN/TURN 服务器，负责获取WebRTC终端在公网的IP地址，以及NAT穿越失败后的数据中转。 主要基础概念： 帧率：摄像头一秒钟采集图像的次数；一般情况下，一秒可采集30张-100张图片。帧率越高，视频越平滑，占用带宽越大。 编码帧：视频数据流通过编码器（H264/H265\VP8/VP9）压缩后的帧。 ​ I 帧：关键
webrtc-sdp编码信息协商
linalg的博客
02-28 1791
简要 webrtc中采用sdp协议进行会话协商，sdp协商是通信数据的开始，理解sdp协议及webrtc对sdp的处理非常重要，本文简单剖析了webrtc源码对于p2p双方编解码器不同时如何进行协商的过程，sdp协议是offer/answer模型，展示如下图。sdp协议对应的API：CreateOffer、CreateAnswer、SetLocalDescription、SetRemoteDescription。 一、 API CreateOffer Cr...
webrtc音频数据流流程图
03-16
在这个场景下，"webrtc音频数据流流程图"是一个关键的学习资源，用于理解音频数据在WebRTC中的处理过程。通过分析这个流程图，我们可以深入了解WebRTC音频引擎的工作原理。 1. **初始化与协商阶段**：在WebRTC应用...
Webrtc支持HEVC之Mediasoup SDP协商编码流程(三)
最新发布
qq_15821883的博客
05-31 688
Mediasoup SDP协商编码流程
WebRTC-STUN协议详解
码农修仙的博客
04-19 2322
1、STUN协议概述 STUN（Session Traversal Utilities for NAT）NAT会话穿透工具，STUN是一个Client/Server协议，支持请求/响应类型、指示类型两种类型。STUN作为ICE（Interactive Connectivity Establishment，交互式连接建立）解决方案的一种工具使用，STUN协议本身没有穿透等能力，只是为穿透提供反射地址，穿透不成功时，需要使用TURN协议。 1.1 请求/响应类型（request/response） 由客户端给服
WebRTC建立会话流程分析
chenxiemin的专栏
02-21 9484
WebRTC建立会话流程总结了解如何运行PeerConnection Demo后，熟悉运行流程可以做为深入学习WebRTC的切入点。本节重点解释客户端双方建立会话时交互的主要信令（控制会话的文本协议）和与信令相关的 WebRTC API。准备工作peerconnection_client 工程主要分为三个部分，main_wnd.h 是视图类，主要包括用户界面相关代码；conductor.h是控制器...
WebRTC DTLS 分析
aggresss
08-15 3102
DTLS(Datagram Transport Layer Security) 提供了 UDP 传输场景下的安全机制，能防止窃听、篡改、冒充等问题。
webrtc详细介绍
热门推荐
tifentan的专栏
09-12 2万+
自作笔记，来自https://hpbn.co/webrtc/，出自一本好书《High Performance Browser Networking》w3c webrtc文档web层主要接口： MediaStream: 采集音视频 RTCPeerConnection: 传输音视频 RTCDataChannel: 传输自定义数据前言一大段废话，强调了一下webrtc使用的udp，但不是普通的ud
WebRTC通话原理-网络协商-NAT-ICE-STUN-TURN
亢少军的博客
03-24 872
作者: 亢少军 彼此要了解对方的网络情况，这样才有可能找到一条相互通讯的链路。需要做以下两个处理。 获取外网IP地址映射。 通过信令服务器(signal server)交换“网络信息”。 理想的网络情况是每个浏览器的电脑都是公网IP，可以直接进行点对点连接。如图所示。 实际情况是我们的电脑和电脑之间都是在某个局域网中并且有防火墙，需要NAT(Network Address Translation，网络地址转换)，如图所示。 在解决WebRTC使用过程中的上述问题的时候，我们需要用到STUN和TURN
【webrtc】媒体协商的过程（24）
沛沛呀、
12-03 898
发送端Amy 创建offer 设置LocalDescription 接收answer 设置RemoteDescription 接收端Bob 接收offer 设置RemoteDescription 创建answer 设置LocalDescription onnegotiationneeded媒体协商时候出发 onicecandidate收到候选者 ...
WebRTC源码研究（29）媒体能力协商过程
kyl282889543的博客
06-17 1682
文章目录WebRTC源码研究（29）媒体能力协商过程 WebRTC源码研究（29）媒体能力协商过程
WebRTC学习进阶之路 --- 七、WebRTC核心之SDP详解、媒体协商
SmallBottle-CGWLMX的博客
11-24 5926
WebRTC学习进阶之路系列总目录：https://blog.csdn.net/xiaomucgwlmx/article/details/103204274 一、什么是SDP SDP(Session Description Protocol)描述会话协议，它只是一种信息格式的描述标准，本身不属于传输协议，但是可以被其他传输协议用来交换必要的信息，用于两个会话实体之间的媒体协商。...
WebRTC简易流程分析
pure_zhou的博客
03-12 5732
目录前言整体架构通话原理简单demo分析 前言 最近被安排去做有关webrtc相关的工作，需要在webrtc中改动一些东西实现一些功能（控制时延、屏幕共享等）。但之前完全没有接触相关的工作，所以需要一边学习一边做，之后会尽力把学习的过程记录下来，以便之后自己不要忘记了。 WebRTC是Web Real-Time Communication的缩写，可以把它看作一种协议或者API。WebRTC Native App使用最多的SDK就是Google WebRTC，它不是只能网页通话，ios和android也都是可
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值