作者： Iñaki Baz Castillo（原文链接）
翻译：刘通
原标题：SDP: Your Fears Are Unleashed
我们在webrtcHacks中已经更新了很多关于会话描述协议的文章（例如《如何通过修改SDP来限制WebRTC带宽》）。为什么？因为它往往是WebRTC中最容易困惑但又很关键的一方面。也是最有争议的。之前WebRTC对SDP讨论导致了与之并行的ORTC标准开发，而这个标准现在已经大致上回归到了核心规范中。但是，现实情况是非基于SDP的WebRTC仍然是开发的小部分，很多人怀疑即使已经得到了官方接受，这种情况也很难会改变。
为了更新SDP的示例，之前的客座作家Iñaki Baz Castillo重新加入了我们。虽然有多年参与到WebRTC标准化和部署工作的经验，但是SDP还是在他从零起步开始搭建mediasoup的SFU时给他带来了新的痛苦。Iñaki提供了SDP到底是干什么的背景知识，ORTC的不同之处，以及SDP在一些越来越多的常见用例中出现的实际问题，你们很多人会发现这个很有用。
写这篇文章的灵感来源于我发给MMUSIC WG的一篇电子邮件，在其中我抱怨了SDP的使用问题，我将它比喻成“用于交换多媒体信息的最小不可去除单位”。
我想是时候把SDP从我们的生活中剔除出去了，特别是在WebRTC中，这样开发者就可以更好的进行媒体信令。
在我开始详细介绍SDP带来的新问题之前，让我们先来回顾一下SDP在WebRTC中的任务以及ORTC—使用WebRTC中使用SDP的主要替代方案。
WebRTC 1.0中SDP的简要介绍
尽管WebRTC 1.0公开了一个API来处理和传送本地音频，视频和/或数据给远端WebRTC对等端，但是信息交换单元还是SDP。这基本上意味着不管本地执行的什么操作，SDP都必须发送给另一方（或者让对方生成一个可以代表我们本地操作的SDP）并且通过setRemoteDescription()“提供”给RTCPeerConnection。webrtcHacks在这里有一个一行一行解释SDP的教程，除了标准以外是一个很好的参考。
SDP是干什么用的
WebRTC的SDP传递有关所有通讯层的信息，包括：
# 用来在多媒体会话中建立两个对等端之间网络通道的ICE参数以及可选ICE候选
# DTLS参数，用于执行DTLS握手以及交换用于音频和视频的SRTP密钥，以及/或者在DataChannel消息将要交换处建立加密的传输
# 决定哪个对等端进行发送和接收的RTP参数
参数及m=行
SDP提供包括必须被远端对等端接收或者拒绝的m=段。每个m=段包括以下这些信息：
# 发送的媒体种类：audio, video或者application。
# 这种媒体部分的目的是发送媒体，接收媒体还是二者都有。
# RTP参数。
# ICE和DTLS传输参数。
SDP还包括允许使用BUNDLE的全局参数。BUNDLE的目的是将不同的m=段归于“传送”组，因此不是每个媒体部分都建立一个单独的ICE路径和DTLS连接，而是他们都使用一个ICE路径和DTLS连接。
尽管SDP中单独一个媒体段的意义和作用可能会容易混淆。WebRTC 1.0采用了一种方法将每个m=段携带关于发送的单独MediaStreamTrack信息，接收的MediaStreamTrack或者二者都有。
假设两个对等端之间的双向音频和/或视频，媒体段的RTP参数决定了发送和接收的编解码器。这样的协商使SDP请求方使用编解码器A发送媒体，同时SDP应答方使用编解码器B发送媒体。这是SIP/VoIP实现中典型问题和不兼容问题的原因，同样也使用与目前WebRTC端点。
WebRTC 1.0 SDP的总结
WebRTC 1.0 API提供一些实体：
# RTCPeerConnection：基本可以代表一切（发送以及接收轨道或者数据，本地以及远端SDP表示等等）
# RTCTransceiver：引用了SDP中一个m=段
# RTCRTPSender：收发器的发送部分。
# RTCRTPReceiver：收发器的接收部分。
出于这篇文章想表达的目的，让我们专注于下面这些SDP的总结：
# 一个m=段包含用于建立传输的ICE和DTLS传输参数
# 在浏览器端的时候，m=audio或者m=video部分传输用于发送和/或接收MediaStreamTrack的RTP参数
# WebRTC 1.0 API提供的类/实体与SDP的分析和语意密切相关。
