从 0 打造音视频直播系统
李超
前新东方音视频直播技术专家,前沪江音视频架构师
32579 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 41 讲
WebRTC 1对1通话 (23讲)
从 0 打造音视频直播系统
15
15
1.0x
00:00/00:00
登录|注册

08 | 有话好商量,论媒体协商

思考时间
小结
媒体协商的代码实现
媒体协商的过程
RTCPeerConnection
WebRTC中媒体协商的作用
WebRTC处理过程中的位置
WebRTC中的媒体协商

该思维导图由 AI 生成,仅供参考

《07 | 你竟然不知道 SDP?它可是 WebRTC 的驱动核心!》一文中,我向你详细介绍了标准 SDP 规范,以及 WebRTC 与标准 SDP 规范的一些不同,而本文我们将重点学习一下 WebRTC 究竟是如何使用 SDP 规范进行媒体协商的。
我们平时所说的协商你应该清楚是什么意思,说白了就是讨价还价。以买白菜为例,商家说 5 元一颗,买家说身上只有 4.5 元卖不卖?商家同意卖,这样一次协商就完成了。
媒体协商也是这个意思,只不过它们讨价还价的不是一般商品,而是与媒体相关的能力。那媒体能力是什么呢?实际就是你的设备所支持的音视频编解码器、使用的传输协议、传输的速率是多少等信息。
所以简单地说,媒体协商就是看看你的设备都支持那些编解码器,我的设备是否也支持?如果我的设备也支持,那么咱们双方就算协商成功了。

在 WebRTC 处理过程中的位置

在正式进入主题之前,我们还是来看看本文在整个 WebRTC 处理过程中的位置,如下图所示:
WebRTC 处理过程图
通过这张图你可以了解到,本文所涉及的内容包括创建连接信令两部分。
创建连接,指的是创建 RTCPeerConnection,它负责端与端之间彼此建立 P2P 连接。在后面 RTCPeerConnection 一节中,我们还会对其做进一步的介绍。
信令,指的是客户端通过信令服务器交换 SDP 信息。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

WebRTC中的媒体协商是实现音视频通信的关键环节。通过SDP格式整理媒体信息,通信双方通过信令服务器交换SDP信息,找出共同支持的媒体能力,最终实现音视频通信。文章详细介绍了WebRTC中媒体协商的原理和实现过程,包括位置处理、RTCPeerConnection类的作用,媒体协商的过程以及代码实现。通过createOffer、createAnswer、setLocalDescription、setRemoteDescription等API,呼叫方创建Offer,被呼叫方收到Offer后创建Answer,并通过信令通道交换SDP信息,最终完成媒体协商。此外,文章还简要介绍了RTCPeerConnection对象的作用,以及在WebRTC中SDP消息的交换使用RTCPeerConnection对象完成的重要性。这篇文章对于想要深入了解WebRTC技术的读者具有很高的参考价值,能够帮助读者快速了解WebRTC中媒体协商的关键过程和技术特点。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 打造音视频直播系统》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(19)

  • 最新
  • 精选
  • qiezitx
    sdp信息的交换是通过信令服务器完成的,只不过sdp的填写是通过RTCPeerConnection完成的

    作者回复: 非常准确!

    2019-12-13
    19
  • 波波安
    我使用chrome播放h264视频流,流媒体使用kurento,内部做了转码为vp8,chrome默认使用vp8协商,什么方法可以使chrome使用h264,避免转码

    作者回复: 修改SDP,将m=video中的多个编码器换一下位置,把H264放在最前面就可以了。不过由于WebRTC的整体机制没有对 H264做特别好的适配,所以特别容易产生卡顿与花屏。

    2020-06-30
    5
  • 俊哥
    老师,我有一个疑问,A怎么知道呼叫的B而不是其他的C、D呢?从你的js代码里没有看出来对B的描述,比如B的ip地址是xxx.xxx.xxx.xxx。那么A调用sendMessage(sessionDescription)发到哪里去了呢?

    作者回复: 通过信令服务器转发。 A与B都要先与信令服务器建立连接,之后通过服务器转发。

    2019-10-18
    3
    3
  • Jian
    呼叫方和被呼叫方的角色是如何确认的呢?会否存在两端都向对方发送offer的情况?是由服务器确定的?

    作者回复: 谁先发起呼叫谁就发offer,另一方发answer;这完全有应用层控制;比如第一个人进入房间后,就在哪里等待,当发现第二个人上来的时候它就给对方发offer 就好了。如果两个人同时进入房间,就在服务器端建个队列,让他们顺序进入就好了,非常好处理对吧?另外两端都发offer 那协商必然失败。

    2019-08-01
    3
    3
  • icema
    目前遇到了采集steam没有声音的问题,对方听不到我的声音,并且是偶现,不是必现,前端有没有什么方式可以检测或者监控采集到的流是存在异常的或者没有声音的呢?

    作者回复: 你可能通过receiver里的统计信息来判断

    2020-04-21
    2
  • Benjamin
    两端的 SDP 的创建都是在 RTCPeerConnection 中完成,创建好了 SDP 信息。至于两端交换这个 SDP 的实现,是完全可以剥离解耦的。 常见就是用 single 服务器来交换,至于交换 SDP 的具体承载模式都是自己去实现的。 常见就是用 socket,为了好玩或者一些常见用 HTTP 也可以,甚至可以生成 txt 文件在用 ftp 交换都可以只要不嫌麻烦 😀 但是,SDP 第一次后的来回交换是不是还有,这块一直很疑惑。

    作者回复: 协商成功之后就不会再有了,除非你自己要重新再进行协商

    2020-02-11
    2
  • 请问老师哪些开源的sip框架支持webrtbc的吗

    作者回复: 你可以使用sip 协议做信令,但sip 协议用的人比较少,一般都在监控系统中使用,目前开源的基本没有人使用sip 与WebRTC 结合

    2019-08-02
    2
    2
  • Beast-Of-Prey
    发送信令用socket?

    作者回复: 由于信令数据量不大,所以你可选择的协议就比较多了,TCP、HTTP/HTTPS、WS/WSS,都可以,底层实现都是用的socket

    2019-08-01
    2
  • Her later
    此时,媒体协商过程完成。紧接着在 WebRTC 底层会收集 Candidate,并进行连通性检测,最终在通话双方之间建立起一条链路来。 如果 Candidate 是 WebRTC 底层收集的 ,那么为什么还需要经过信令服务器呢 ?

    作者回复: Webrtc 底层收集的candidate 是他自己的地址信息呀,需要通过信令服务器交换给对端双方才能通信

    2021-04-16
    2
    1
  • Jason
    思考题:从老师的讲解来看,SDP 消息的交换不是使用 RTCPeerConnection对象完成的,RTCPeerConnection对象负责创建offer、设置本地SDP描述信息、设置远端SDP描述信息、创建answer。交换SDP消息应该是socket对象完成的,但socket的类型啥呢,还不知道。

    作者回复: 有没有想过用http?它可是浏览器天然的哈

    2019-08-01
    1
收起评论
显示
设置
留言
19
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部