mediasoup 源码分析（二十三）SDP 协议介绍

最新推荐文章于 2024-06-23 09:13:13 发布
最新推荐文章于 2024-06-23 09:13:13 发布
阅读量1k 收藏 1
点赞数 1
分类专栏： mediasoup源码分析 文章标签： sdp level-asymmetry
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lcalqf/article/details/112400451
版权
本文详细介绍了SDP（Session Description Protocol）协议，指出其作为会话描述协议，而非传输或应用层协议的角色。SDP用于交换WebRTC连接所需配置，包括offer、answer类型以及包含会话ID、版本、网络类型、端口、媒体类型等关键信息的协议结构。同时，文章探讨了SDP中的属性、媒体信息、连接数据、ICE参数、DTLS角色设定、流方向和RTP相关属性，为理解WebRTC通信提供了基础。
摘要由CSDN通过智能技术生成

目录

 

SDP 介绍

协议介绍

SDP 介绍

SDP(Session Description Protocol)是一种会话描述协议，不是传输协议。

什么意思呢？，就是说SDP不是传输层协议（如UDP、TCP），也不是应用层协议（如HTTP），它是一种自定义的私有协议格式，用来交换webrtc建联所需要的配置信息、媒体属性信息等。

SDP 分为offer、answer两种类型，且服务端和客户端既可以做offer也可以做answer。

 

v=0
o=- 1403428358347373126 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS w1eQCwlDl7cPaNxSwHQyw4hksCXvP27CjaEC
m=audio 9 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:XE7s
a=ice-pwd:2NKD2fj19nTjwNEmBj+qV9Pm
a=ice-options:trickle
a=fing
了解本专栏 订阅专栏 解锁全文 超级会员免费看
mediasoup源码分析（六）数据分发 Transport 到 Router 、Consumer
lcalqf的专栏
08-13 1329
一、Tansport 转发到Producer Transport收到数据packet后，会解析出packet中所带的ssrc字段，然后基于ssrc找到该数据的Producer。 Transport::ReceiveRtpPacket { // Get the associated Producer. RTC::Producer* producer = this->rtpListener.GetProducer(packet);//基于包中的ssrc选出Producer } Produer也
mediasoup 源码分析（二十五）dtls握手协议（二）
lcalqf的专栏
01-25 824
目录 DTLS 协议介绍 DTLS交互过程 抓包 基于mediasoup 分析dtls ssl 中的BIO 处理收到的DTLS数据，得到私钥 基于获得的私钥key创建srtp DTLS 协议介绍 DTLS(Datagram Transport Layer Security)数据包传输层安全协议。TLS不能保证UDP传输的安全性，DTLS在TLS基础上进行扩展，使之支持UDP。 补充第十九篇dtls 握手，十九篇见下面链接。 https://blog.csdn.net/lcalqf.
Mediasoup源码分析（1）——架构分析
点点滴滴
08-29 7773
1. 设计架构图 Worker 一个Worker代表着一个运行在单核CPU上并处理Router实例的mediasoup C++子进程； Router Router用于注入、选择和转发通过Transport实例创建的媒体流； Transport Transport将终端与MediaSoup Router连接起来，并通过在其上创建的Producer和Consumer实例实现双向媒体传输，...
MediaSoup的SDP协商
weixin_45267035的博客
10-19 1857
SFU媒体服务器与WebRTC客户端进行交互时，也可以把它看成是WebRTC的一个“客户端”，因此它也要遵循WebRTC的交互规则。服务端作为被动接收者，接收客户端发送的OfferSdp，当信令服务器接收到OfferSdp时，会将其转换成MediaSoup需要的Json格式，然后通过管道传给媒体服务器，媒体服务器处理相应的Json格式，然后返回给信令服务器相应的处理结果，信令服务器将处理结果封装成AnswerSdp返回给客户端，从而完成SDP的协商。 注意：这里的信令服务器相当于是原生MediaSoup的J
mediasoup-demo 多方通信SDP协商分析
The_Old_man_and_sea的博客
07-04 1315
mediasoup-demo SDP协商分析1.SDP协商方式2.推流端 SDP3.订阅端（接收端）SDP 1.SDP协商方式 2.推流端 SDP v=0 o=- 4949866233914119598 4 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 1 2 a=extmap-allow-mixed a=msid-semantic: WMS 6d0c4361-dfac-4322-963e-03799f367ac1 m=audio 55279 UDP/TLS/RTP
mediasoup源码分析-初始化、建立连接及媒体数据的处理流程
专注音视频基础、WebRTC、ffmpeg、流媒体服务器
03-31 5292
mediasoup中的Transport有多种类型，以下只分析WebRtcTransport，且只分析音频、视频的传输。 线程模型 mediasoup使用的是多进程模型，服务器上有多个少CPU核，就启动多少个Worker进程。每个Worker进程采用单线程，运行一个事件循环，所有数据的处理，都是通过事件触发的。 MediaSoup的应用层和媒体处理层分别运行在不同的进程内，它们之间通过管道进行通信。 注意：应用进程和Worker进程之间可以使用普通的管道，也可以使用socketpair，这个部分的代码应该在
WebRTC进阶流媒体服务器开发（四）Mediasoup源码分析之底层库
irainsa的博客
02-28 441
若被占用，就根据PortManager的策略往后跳。接收端能够知道有没有丢包，因为数据包有Sequence，比如发送了100个数据，前50个数据是连续的，但假设当50之后是55，Recv端就知道丢了 51、52、53、54 这4个包了。因为数据的接收有可能会丢包，丢包重传的也算作一路流，对应的音频的丢包也是需要重传）服务端推送给客户端的数据流是会重新排序的，排序的时候便会依靠这个SeqManager，它会记录某个SSRC所对应的Sequence，以此为起始位置，然后后面的每个包都向下递增一个数。
mediasoup 源码分析（十九）dtls 握手
lcalqf的专栏
10-27 2056
一、DTLS 作用 dtls是udp层的安全传输协议，用来交换srtp的解密的秘钥。需要注意一点，dtls只用在srtp秘钥交换过程，秘钥交换完成后面发srtp的过程就不用dtls了。 二、DTLS 关注点 1、角色 dtls角色是在sdp协商时确定的。sdp协议中有a=setup字段。有如下三个可选值： a=setup:actpass 既可以是客户端，也可以是服务器 a=setup:active 客户端 a=setup:passive 服务器 chrome 浏览器和mediasoup 在d.
mediasoup源码分析（十二）多端口问题 一个transport一个端口
lcalqf的专栏
08-20 2129
一、多端口问题 mediasoup 一个transport 会开启一个udp端口进行监听，这样服务端就需要同时对外暴露出多个端口，在实际线上应用时 非常不安全。 二、多端口问题的解决方案
mediasoup 源码分析（三） room 和 router 创建过程
lcalqf的专栏
08-07 1586
一、server启动WebSockerServer server.js会通过protoo 启动WebSocketServer // Run a protoo WebSocketServer. await runProtooWebSocketServer(); 当用户请求连接时会带着roomId，server接收到用户请求后会判断当前房间是否存在，如果不存在会就创建一个。 具体详情见server.js的runProtoWebSockerServer()函数 async function run.
mediasoup
03-30
Mediasoup视频会议 使用mediasoup进行多方视频/音频/屏幕会议的示例网站。 该项目旨在通过一个简单的示例更好地了解mediasoup的工作方式。 该项目在具有许多其他示例。 在检出 运行代码 运行npm install然后npm start运行该应用程序。 然后在https://localhost:3016或配置文件中您自己定义的端口/ URL中打开浏览器。 （可选）根据需要编辑src/config.js文件，并用您自己的证书替换ssl/key.pem ssl/cert.pem证书。 部署方式 在config.js ，用您的服务器的公共IP地址替换announcedIP ，并修改您要为其提供服务的端口。 添加网页端口的防火墙规则（默认为3016）和计算机的rtc连接（默认为udp 10000-10100）。 注意：最好在linux系统上运行项目，因为mediasou
C++基于MediaSoup的高并发SFU(负载均衡服务器+客户端)
06-01
1、负载均衡、多进程媒体服务器； 2、多会议室、多人参与； 3、用到的协议TCP/UDP/ICE/DTLS/RTP/RTCP等协议； 4、支持IPv4、IPv6； 5、高效率libuv异步网络库； 6、支持录制，或者加载媒体文件分享给伙伴（未完成）； 7、RTSP、RTMP（未完成）；
【MediaSoup---源码篇】（二）Router
用可见的方式来记录和分享每一次收获
09-22 310
Router
mediasoup 源码分析 （八）分析PlainTransport
最新发布
littleboy_IT
06-23 614
PlainTransport 可以接收裸RTP流，也可以接收AES加密的RTP流。源码中提供了一个通过ffmpeg发送裸RTP流到mediasoup的脚本，具体地址为：mediasoup-demo/broadcasters/ffmpeg.sh。脚本就是通过HTTP Post发送创建PlainTranport请求，然后通过ffmpeg向指定地址+端口，发送RTP流。真正绑定的地方在PortManager::BindUdp(ip)中，随机从指定Port范围中选出可用Port，然后绑定。
mediasoup 源码分析（七）consumer创建过程
lcalqf的专栏
08-14 1352
一、consumer 类型介绍 mediasoup总共有四种消费者Consumer类型，SimpleConsuer、PipeConsuer、SvcConsuer、SimucastConsumer， SimpleConsumer 普通RTP数据的消费者，比如有音频流和视频流每个都是SimpleConsumer，没有按类型区分，音视频流都是一样的，最简单的consumer PipeConsumer 不同Worker之间Router之间的数据流转，则其为接收或者消费从另外...
mediasoup源码分析之-网络基础库libuv
cynic_liu的博客
07-13 426
开源的网络事件库有很多种，大家最熟悉的莫过于集成在nginx里的event模块，很灵巧也很好的支撑了nginx的高性能服务。但是分析源码后，大家其实都比较类似，底层采用epoll机制探测事件，从而驱动上层业务运行。libuv也是一个开源的网络事件库，它的设计也比较巧妙，很轻量级。 mediasoup中，libuv使用由以下两个函数启动，ClassInit负责生成uv_loop_t对象，并初始化相关对象，类似nginx的ngx_worker_process_cycle，RunLoop调用uv_run，启动循
mediasoup 源码分析（二十二） XR包
lcalqf的专栏
12-14 806
目录 协议介绍 协议分析 1、BT=4 2、BT=5 协议介绍 XR 包是RTCP 扩展报告的一种，PT=207，主要用来提供更加详细的时间、丢包等统计信息。XR包总共有七个报告块，mediasoup主要第四和第五即BT=4 ,BT=5两个。 代码见：XR.cpp 、XrDelaySinceLastRr.cpp、XrReceiverReferenceTime.cpp 协议分析 协议文档：https://datatracker.ietf.org/doc/rfc3611/?include.
mediasoup 源码分析（十七）tccClient模块分析(2)及RTCP反馈报文介绍
lcalqf的专栏
10-02 865
2、RTCP反馈信息文档： rfc4585 https://tools.ietf.org/html/rfc4585#section-6.3 rfc4585的补充信息rfc5124 https://datatracker.ietf.org/doc/rfc5124/?include_text=1 主要有两大类反馈，一类是传输层的反馈RTPFB，PT=205；一类是负载层的反馈PSFB PT=206。 2.1 其中传输层的反馈 如：NACK 信息、TMMBR、TMMBN等 见rfc5104..
mediasoup 源码分析（十三） 丢包重传 webrtc nack 机制
lcalqf的专栏
08-21 1375
一、丢包介绍 由于webrtc所用的rtp协议底层是基于udp传输，所以并不能保证数据的可靠性。在发生丢包时，为了保证音视频的质量需要进行 重传，而 nack机制就是用来处理重传逻辑的，需要注意一点由于udp本身是无序的，所以在进行丢包重传时要做一定的特殊处理。 二、nack 报文介绍 文档 ：RFC4585 其中PT=205,FMT=1 ,Packet identifier即为丢失的RTP数据包的序列号，BitMap of lost packets指从,Packet ident...
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

致一

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值