WebRTC之SDP协议

首先喝点鸡汤

什么是SDP

SDP(Session Description Protocol) 是一种会话描述协议,基于文本,其本身并不属于传输协议,需要依赖其它的传输协议(比如 SIP 和 HTTP)来交换必要的媒体信息,用于两个会话实体之间的媒体协商。

下面这个链接展示了一个完整的SDP例子:

[一个不错的 WebRTC 的 SDP 例子分析https://webrtchacks.com/sdp-anatomy/](https://webrtchacks.com/sdp-anatomy/)

为什么需要SDP

会话就会话呗,为什么需要描述呢?因为参与会话的各个成员的能力不对等、用户环境与配置不一致等。比如有人可能想到使用所有人都支持的媒体格式。我们暂且不讨论是否存在这样的一种格式,我们试想一下
如果参与本次会话的成员都支持更高质量的通话格式,那么使用通用的、普通质量的格式是不是影响了体验?既然无法使用固定的格式配置,那么会话信息的描述就很有必要了。

也就是说一次会话使用何种配置并不是由某一个成员说了算,必须所有人的意见达成一致,这样才能确保所有人都能参与会话,所以这里就涉及一个协商的问题,我们需要SDP协商出兼容最优的解决方案。

SDP格式

SDP使用的是<type>=<value>的格式。SDP是由若干行<type>=<value>的文本组成。

其中<type>必须是一个区分大小写的字符,<value>是结构化文本,其格式取决于<type>。通常,<value>是由单个空格字符或自由格式字符串分隔的多个字段,并且是区分大小写的
,除非特定字段另有定义。"=" 符号的两边不能有空格。

对于比较复杂的行还会在空格等级的基础上继续拓展使用分号 ; 作为各个参数之间的分隔符,例如:

a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f

下面举例简单说一下SDP的行内容解析,更多详细的SDP行内容表示的意思学者可以通过上面给的链接例子自行查阅资料学习,这样才能加深印象:

v= 所在行,代表版本,目前一般是`v=0`.

m= 所在行是media line(媒体行,又叫m line)。两个m line之间或者最后一个m line到结尾的行都是用来描述一种媒体数据的(叫media section),
包括数据格式、网络传输等信息。例如,m=audio 开头的描述的是音频信息,以m=video开头的描述的是视频数据的信息。

a=candidate所在的行描述了这个media section将要用到的ICE Candidate。

a=recvonly 所在的行描述了这个media section的方向,可选值有receonly(只接收)、sendonly(只发送)、sendrecv(同时接收和发送)。

a=rtpmap 所在的行描述了这个media section所支持的格式。

WebRTC中的SDP总体上可以分为以下几个部分:

  • session metadata:描述整个会话的基本信息,行开头为v=、o=、t=等;

  • network description:描述网络传输的信息,行开头为c=、a=candidate等;

  • stream description:描述媒体流信息,行开头为m=、a=rtpmap、afmtp、a=sendrecv等;

  • security description:描述数据加密,身份认证等相关信息,行开头为a=crypto、a=ice-frag、a=ice-pwd、a=fingerprint等。

  • DTSL角色描述:行开头为a=setup等。

  • ICE策略描述:行开头为a=ice-options:trickie、a=ice-lite、a=ice-option:renomination等。

  • Qos,grouping description:描述服务质量,传输层复用相关信息,行开头为a=rtcp-fb、a=group、a=rtcpmux等。

SDP的两种Plan

SDP的两种Plan是指在传输多路同类型媒体流时两种SDP的格式,多路同类型媒体流的例子有"录屏+相机"或者多个相机的情景。
这两种SDP格式分别是Plan B和Unified Plan,目前WebRTC标准采纳的是nified Plan,并且代码已经支持。

Plan B:同类型媒体只有一个m line,同类型的多个媒体流之间通过msid区分;

Unified Plan:每个媒体流都有一个m line,比如有两路视频,就会有两个video m line。

ORTC

ORTC说白了就是WebRTC中使用SDP的主要替代方案或者说是SDP的规范版。

既然已经有了SDP,而且目前已经在WebRTC中有了相关的支持,为什么还需要ORTC呢?
这就要从SDP的弊端说起了。

首先WebRTC刚开始搞的还不是很火,至于谷歌和firefox在搞,其他一些主流的浏览器厂商并不是很配合,所以自然而然地就缺少了一个相关的规范。
随着这几年WebRTC开始火起来,一些巨头们看到WebRTC这个趋势,就想加入进来了,但是又不想全由谷歌一家说了算,所以就开始挑战WebRTC,挑刺搞规范了。

其中SDP被挑的几个主要问题就是:

1,sdp格式晦涩难懂,这确实是事实,内容多还不说,每次使用还得像查字典一样去查。

2,太多高层次的API,以及没有严格的标准规范,火狐和chome一些写法还搞得不一样。

3,无法真正解决历史遗留系统的兼容性问题。

4,要求没有得到应答。

更多关于ORTC的相关知识:www.ortc.org

关注我,一起进步,人生不止coding!!!

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 218,546评论 6 507
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,224评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 164,911评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,737评论 1 294
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,753评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,598评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,338评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,249评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,696评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,888评论 3 336
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,013评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,731评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,348评论 3 330
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,929评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,048评论 1 270
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,203评论 3 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,960评论 2 355

推荐阅读更多精彩内容