原文出处：完整SIP/SDP媒体协商概论-SIP/WebRTC概要

Session Description Protocol（简称是SDP）全称是会话描述协议，此协议用来创建一种协商机制，这种协商机制是由呼叫控制协议创建的介于两个呼叫用户之间的会话进行，协商机制支持的四大协商方式是：

为了说明SDP的具体内容讨论，我们首先需要明确呼叫控制协议的概念。目前，绝大部分的呼叫控制协议中，市场上主要使用SIP和WebRTC来实现呼叫控制。因为篇幅所限和当前实用性的考虑，我们仅介绍SIP协议和WebRTC协议。SIP协议已经部署了很多年，已经普遍使用在VoIP的绝大部分场景中。WebRTC是最近几年比较热门的实时通信协议，也逐渐进入了应用场景中。本章节，我们将先从呼叫控制协议介绍开始，介绍SIP协议基本内容和WebRTC协议的基础知识。

注意：如果一些读者已经具备了基本的SIP协议和WebRTC协议的基础，可以跳过本章节的基础介绍。如果读者想了解更多完整的SIP协议和WebRTC介绍文档，可以查阅本公众号历史文档来进一步学习。这里，仅为了为SDP协议的介绍做一个简单的SIP和WebRTC的回顾介绍。

1 呼叫控制协议

我们知道，一个简单的电话呼叫涉及了很多其他辅助功能，其目的是保证此呼叫功能正常，并且保证运营层面的业务监控也正常工作。呼叫控制协议是电话网络环境中一个必不可少的环节，其主要功能大致包括呼叫数据流量路由控制，增值服务计费支撑，终端之间的连接性，可靠性传输机制，信令控制和媒体通信等功能。在传统的或者现在的基础网络中，很多控制协议仍然是核心的协议，例如，Q.931和H323等具体协议。此概念将会涉及太多的底层细节的协议和历史介绍，例如，PRI和SS7等相关协议。它们通过电路时隙或者通道实现信令控制和语音传输。因为篇幅和文章主题的关系，我们不再讨论那些配置。有兴趣的读者可以查阅一些常用的文章来补充这方面的知识。通过以上简单介绍，我们知道，如果实现一个简单的，哪怕最简单的呼叫都需要呼叫控制协议参与，否则没有办法发起呼叫，也没有办法对呼叫拆线执行挂机。在目前大家非常熟悉的VoIP环境中，SIP是一种非常常见的呼叫控制协议，基本上是目前主流的呼叫控制协议。另外，WebRTC也是我们正在逐步使用的呼叫控制协议。我们在本文章后续部分就重点回顾这两种协议，为将来进一步深入讨论SDP做一个准备工作。

2 SIP协议概要

SIP全称是Session Initiation Protocol。它是我们重点介绍的一种呼叫信令控制协议，用来创建，修改和拆线基于网络通信的会话，会话由语音视频和多方视频数据等构成，通过RFC3261的规定的请求实现。SDP作为消息体的在SIP交互中负责双方媒体协商，支持能力的协商。另外，SIP使用RTP/RTCP的传输参数支持语，视频和数据的参数。因此，SDP和RTP/RTCP是创建SIP媒体会话的最基本的要求。

任何协议都有其规范的语法结构,SIP协议也是一样的。它的基本语法结构和HTTP的HTML语法类似。其信令消息包括两个部分：消息头和消息体。通过各种语法参数设置来支持SIP协议中的支持能力，协商和应用层级的通信。SIP头消息主要目的是对从呼叫方到被呼叫方的SIP消息进行路由管理，信令消息中包含一个Request-line，它由请求类型，目的地的SIP URL，或下一跳（next hop），还有SIP版本构成等。取决于消息体类型，SIP消息体是一个可选项。SIP消息中的消息头和消息体通过空白行来加以区分。消息体构建有太多话题可以讨论，如果读者有兴趣的话，可以参考RFC 3261-13.2.1章节。

如果SIP请求中创建的会话中包含了会话描述的具体消息内容，会话描述中包含了双方的媒体类型和编码等，那么，消息体中将会作为SDP包含这些会话描述的消息内容。
因为SDP消息包含了很多参数设置，涉及了太多SIP消息的头和消息体设置，因此，关于SIP消息的内容，我们这里需要再花费一点时间做进一步的介绍，以便帮助读者了解后续章节中的SDP内容讨论。RFC3261规定了SIP协议的消息格式，根据官方的描述说明，虽然其语法和HTTP/1.1类似（客户-服务器端协议架构），但是SIP协议是一种请求-响应机制的处理方式，通过双方请求消息和对方响应消息来实现信令的协商。因此，其消息构成包括起始行，一个或者多个头消息，空行（表示头消息结束），最后，还有一个可选消息体构成。

generic-message = start-line
*message-header
CRLF
[ message-body ]
start-line = Request-Line / Status-Line

具体关于SIP消息的语法结构，读者可以参考RFC3261-7章节。提醒读者，根据RFC3261的规定，无论是否有可选消息体存在，空行是必须保留的。在SIP消息底部的start-line部分，读者可以看到，它可以支持Request-Line或者Status-Line。如果是从客户端对服务器端发送请求的话，start-line就是Request-Line，它包含请求method名称，请求URL，协议版本和CRLF，它们通过一个单倍行距隔开（SP字符）。没有其他额外的空格或者其他字符。SIP消息中Request-Line具体用法格式为：

Request-Line = Method SP Request-URI SP SIP-Version CRLF

在以上语法中，SIP支持了以下Methods：

除了我们提到的请求和以上的Request-Line中的method以外，服务器端回复响应消息来表示对请求的处理状态。响应中的Status code是一个重要的标识。具体的状态码如下：

在日常的排查活动中，系统技术人员需要以上状态码来判断系统所处状态。当然，在六大状态分类中，还有其子分类，子分类中包含了更加详细的说明。用户可参考RFC3261-13.2.2（处理INVITE响应）和21章节来学习，这里不再讨论。
当然，除了请求methods和响应状态码以外，因为消息体可能需要通过SIP代理/转发服务器和注册服务器的处理节点，因此消息体具有很强的灵活性，它可以被读取，被修改，被移除或者重新处理，为了满足多种场景的响应，消息体也可能增加一些必要的拓展，包括SIP可选tags标签，修改的SIP标签，同时它也可能增加支持Content type的头域，以下这些头域都可能添加到消息体中：Allow, Allow-Events, Content-Disposition, Content-Encoding, Content-Language, Content-Length和Content-Type。以上这些头域值得介绍在RFC3261-20，此章节介绍了具体的定义。

另外，在SIP消息中，读者需要了解基本的消息格式，其中请求消息格式和响应消息告诉都有不同的语法结构。两者的消息内容有明显的区别：

请求消息格式和响应消息格式对比如下：

请求消息格式规范

响应消息格式规范

关于消息体更多的规定，读者可以参考RFC3261-7章节。

接下来，我们讨论一下关于SIP在网络拓扑中和其他相关协议的关联性。

SIP是一种应用层的协议规范，和其他的前面所提到的协议同属应用层的协议。它的目的是用来实现网络媒体的创建服务，电话呼叫，电话会议，视频会议，媒体共享等应用。在这些应用服务中，终端需要支持不同的数据形式，语音编码，数据文件，视频编码等。在这些数据交换的过程中，用户之间的通信可能通过UDP传输/TCP传输方式来传输RTP，也需要RTCP来对媒体流传输控制进行处理。因此，SIP协议协议配合其他的协议完成整个通信服务的处理，其相关协议如下示例图所示：

SIP和其他相关协议的关系

通过以上图例读者可以看到，事实上，在一个普通的应用环境中，一个环境可能涉及了很多终端和服务器端以及各种应用程序的协商支持，通过确保双方功能协商和性能能力的协商，确保双方具有一系列共同确认的参数才能进行通信（例如，传输方式是否相同，端口是否一致，编码是否支持）。因此，双方都认可的，标准的，共同支持的协商机制是必不可少的。SDP就是SIP协议中进行协商的标准机制。
通过以上对SIP以及基本语法的介绍，我们大概了解了SIP的消息和一些必要的请求响应消息体构成。接下来，笔者从宏观的角度介绍一下SIP网络技术环境中一些核心的实体构件，包括支持SIP场景的客户端和服务器端的功能，以及SIP/SDP整体协商流程。

如果我们从最基本的SIP网络构成中讨论的话，基本的SIP网络构成包括以下几个核心的模块：各种UA，注册服务器，转发服务器，定位服务器和代理服务器，还有应用服务器等。如果实现完整的SIP媒体通信的话，SIP需要支持至少五种功能：

通过以上五种功能的支持，SIP网络中的核心构件才能成功工作。这些核心模块负责以上五种能力的支持。当然，随着当前SIP网络的应用场景不断变化和用户业务需求的变化，SIP网络中有可能各种服务器的部署不是固定的，因此此图例不一定完全表示所有的应用场景。关于SIP服务器端的讨论，用户可以参考笔者历史文章做进一步的学习。

各种SIP UA和服务器端构成

在以上图例中，我们看到一些核心的模块包括了SIP UA(User Agent)，UA又可分为UAS和UAC，另外，UA是以客户端-服务器端模式的模式工作的用户，这表示一个UA实体，为了满足SIP的逻辑实体的要求，它既可能是UAC，又可能是UAS，也是我们通常所的背靠背代理方式。如下示例说明了一个应用场景中两个SIP终端通过两个代理的呼叫流程：

两个UA通过不同代理进行呼叫整体协商流程

两个UA首先注册到各自的服务器端，然后通过服务器呼叫另外一个终端。读者需要注意，这里假设，Alice在F5 INVITE（标识部分）可能已经携带了本端SDP的媒体支持能力，而且，Bob收到服务器端通过F8 INVITE发送到请求，也回复了可接受的媒体支持能力。双方都协商一致，然后开始语音媒体流发送（F19）。

UA又根据具体呼叫控制角色不同，可能划分为不同的UA使用角色，电话会议就是一个例子。RFC4579中定义了电话会议中的在SIP 构件中UA定义：

我们前面已经讨论，SIP服务器类型支持了多种处理方式，并且都具有不同的处理流程。有时，这些服务器的功能定位可能互相交叉，因此一些读者可能比较迷惑。如果读者单 纯从定义上了理解的话，可能有引起很多误解，读者可以查阅笔者的历史文档来理解这些概念：

3 关于WebRTC基本介绍

前面，我们简单概述了SIP协议作为呼叫控制协议的基本内容，利用消息体中的SDP参数进行呼叫媒体协商。WebRTC也是一种呼叫控制协议，只是WebRTC利用的是浏览器的方式。这里，笔者不打算花费时间再介绍一次WebRTC，笔者以前发布过一篇关于WebRTC的概要，读者通过此文章基本上可以理解WebRTC的基本要点：

完整WebRTC技术及应用概要

4 总结

一个最基本的呼叫场景都至少需要两个部分来完成。首先是呼叫控制协议的创建，然后才能实现SDP 媒体协商的流程。因此，在本章节中，我们介绍了呼叫控制协议的基本概念，接下来，笔者介绍了呼叫控制协议中的SIP协议和WebRTC协议。在SIP协议的概要介绍中，我们介绍了SIP消息的基本结构和核心模块。通过这些基本的介绍，为我们后续关于SDP的深入讨论打下一个基础。在后续章节中，我们将逐步介绍SDP和其相关规范。

再次说明，在本章节中，笔者针对SIP和WebRTC的介绍仅是为了在后续章节中为SDP讨论做一个铺垫作用，可能有一些内容不是读者所希望了解的，望见谅。

参考资料：

原文出处：完整SIP/SDP媒体协商概论-SDP基础-核心定义全解

在第一个章节中，笔者简单介绍了和SDP密切相关的两个控制协议：SIP/WebRTC，其目的是为了帮助读者在进行SDP学习之前，对SDP背景知识有一个简单的讨论，便于读者能够比较顺利地进行后期的学习。从第二章节开始，我们将逐步进入到真正的SDP的内容介绍。

在第二章节中，我们将会重点介绍RFC4655的参数属性，常用参数的定义说明，SDP的使用方式，SDP的要求和建议，SDP规范说明，SDP具体参数属性，语法结构和安全考虑等环节。
因为篇幅太长，为了方便读者阅读，笔者把整个内容分为两个部分来发布。此章节重点介绍第一部分的内容。此部分重点介绍关于SDP中的定义说明，笔者尽可能涵盖绝大部分的规范定义，所以称之为SDP定义全解。

1 SDP基本介绍

任何技术都是时代的产物，和当时的时代有非常紧密的相关性。我们讨论问题需要结合当时的大背景环境来讨论，否则，我们将失去基本的判断标准。在关于SDP的内容介绍中，我们也需要遵从这样的思考方式来讨论。 SDP协议经过了几个规范版本的演进，一些比较旧的规范已被弃用。RFC2327（1998年发布）和RFC3266（2002年发布）已经不再使用，根据以上两个规范演进出来的新规范RFC4566（2006年发布），它是我们现在使用的规范标准。

当用户发起一个媒体呼叫时，无论是电话会议，视频会议或其他的会话。为了完成这些业务功能，必须要求双方或对方参与者实现一些基本的要求。这个要求是需要系统传输媒体的细节，传输地址和其他会话描述所支持的元数据（Metadata）。SDP提供了这样一个标准的表达方式，能够支持这些媒体参数和元数据构成。其目的是提供一种常用规范，可以广泛使用在互联网环境和应用场景中。

基于以上定义，我们需要进一步说明，SDP仅是提供了这样一个数据表达的标准，支持会话描述的格式，它不涉及或者不关心数据是如何传输的，它借用或配合其他的传输协议来完成(这里，仅讨论针对SDP来说的传输协议)。关于传输方式的讨论，读者可以参考OSI模型学习。当前的环境中，SDP一般需要配合以下其他几个常用的传输协议来获得媒体数据：

下面，我们将具体介绍在RFC 4566中规定的定义，也包括了早期规范（RFC2327和RFC3266）的定义。

2 SDP常用参数定义全解

经过多年的发展，在SDP的概念中，除了最初的RFC2327和3266 规范以外，RFC4566增加了很多的功能概念和定义，同时还有一些最新的定义也可能在最近添加到SDP的规范中。以下介绍中将涵盖当前使用的大部分在SDP中核心概念和专有名词（65个定义）。其中一些专有名词很少使用，如果用户不了解的话，可以查阅相关规范做进一步学习，笔者这里尽可能归纳出当前完整的定义。另外提醒，其中一些定义和一般意义的SIP中的称谓有所不同，这些专有名词可能仅在SDP讨论中使用，所以读者一定要注意，避免产生歧义。

"m=" 行：SDP 消息体包含一个或多个媒体描述，每个媒体描述通过SDP在的一行"m="定义。

5-tuple：简称为五元组，它有五种参数构成，包括源地址，源端口，目的地地址，目的地端口和传输层协议参数。

Actual configuration：一个actual configuration指定了当前offer/answer模式下的SDP会话参数和媒体流模块的组合形式。在offer/answer模式下，如果使用了此种方式的话，将不再进行进一步的媒体协商。它是SDP能力协商模式的中四种模式的其中一种。读者可参考RFC5939和RFC6871获得具体细节。后续部分我们还有讨论另外两种配置形式。

Agent：这里的agent是一种在offer/answer模式中的协议部署方式，它包括offerer和answerer两种agents。读者可参考RFC 3264获得详情。

Aggressive nomination：Aggressive nomination：针对媒体流量，提取有效候选参数配对的一个过程，此过程在每个STUN请求中包含一个flag, 被选配对的参数将作为最高级配对测试。在部署过程中，Aggressive nomination相对比regular nomination处理更快一些，但是它和regular nomination相比，它缺乏灵活性。读者可参考RFC 5245获得相关规范。

Answer：一个SDP应答消息，它是由响应中的answerer发送的消息。

Answerer：它是一个agent，从另外一个agent接收会话描述，此agent说明了媒体通信期望的属性，并且对另外一个agent回应自己的会话描述。

Answerer BUNDLE address：使用在一个给定的BUNDLE组中，它是一个合并的IP地址和端口组合，answerer 用它来接收所有在每个“m=”行中指定的BUNDLE 同类组中媒体。

Answerer BUNDLE-tag：存在于一个answer 应答消息中，它是在一个给定的SDP“group:BUNDLE” 属性身份确认标签列表中的identification标签。

Base：它是服务端反射候选对象基础服务端，是可以实现自我学习的服务器本地候选人（host candidate）。host candidate也可以这样说，它自己本身也有一个base，这个base等同于自己，因为Server Reflexive Candidate（服务端反射候选对象）本身通过IP地址和端口的绑定，使用STUN或者TURN服务器自己学习。

Base attributes：出现在媒体块base configuration的约定SDP属性参数。

Base configuration：媒体配置环境，它通过所有能力协商属性独有的媒体部分来表示。在offer SDP中，此配置相当于前面介绍的actual configuration。

BUNDLE group：一个"m=" 行系列，它由一个SDP offer/answer 交互模式创建，此交互模式使用同样的BUNDLE address 接收媒体。

Bundled "m=" 行：一个 "m=" 行，在offer或者answer中，它的identification-tag 被置入到SDP的“group:BUNDLE” 属性identification-tag列表中。

Bundle-only "m="行: bundled "m=" 行关联SDP中的“bundle-only” 属性设置。

Bundled media：所有在设定的BUNDLE group媒体。

Initial offer: 当SIP用来传输SDP时，在SDP会话中第一个offer消息，此offer消息指示它准备创建一个设定的BUNDLE group。

Candidate：一个传输地址，它是一个潜在的准备接收媒体的联系地址，它本身具有自己的属性：类型（server reflexive, relayed, or host）， priority，foundation和base。

Candidate pair：候选配对包含本地候选和远端配对。

Check list：一个有序的候选配对列表，agent 将使用此列表生成check。

Check：check是从本地候选对象发送到候选配对的远端候选对象的过程。

Component：一个 component是一段媒体流，它要求一个单个传输地址。一个媒体流可能要求多个 components。它们中的每个component 都需要作为整体针对媒体流来工作。对于基于RTP的媒体流来说，每个媒体流包含两个component, 一个针对RTP流，另外一个针对RTCP流。

Controlled agent：一个ICE agent，等待controlling agent选择，controlling agent将从候选对象配对中选择出最后的选项。

Controlling agent：一个ICE agent，它负责从候选对象配对中选择出最终选项，然后通过STUN创建发起信令，如果需要的话，更新offer。注意，在任何会话中，一个agent总是控制方，另外一个是被控制方agent。

Conventional attribute：任何SDP属性除了通过一系列能力协商官方的属性以外的属性。

Conventional SDP: 一个SDP记录，此记录缺乏能力协商属性。

Core service platform ("core SPF")：它是一个宏定义的功能模块，提供一系列的功能接口，包括会话路由，高级服务接口和访问控制。它是是SDP的服务架构中的其中之一，负责SIP和SIP之间的接口连接。具体关于规范细节，读者可以查看SDP可选连接属性的规范来进一步了解服务架构（RFC6974）。

Data path border element (DBE)：DBE 表示一个功能要素，它配置在IP通信管理domain之间的边界处（ITAD）。它负责解析从 用户代理接收到媒体数据流，然后转发到其他的DBE （媒体服务器，IVR服务器等）。例如，DBE作为一个媒体网关用来解析RTP流。

Signaling Border Element (SBE)：以上图例也包括了SBE，它表示一个功能要素，它配置在IP通信管理domain之间的边界处（ITAD）。它负责解析从 用户代理接解析信令，然后转发到core SPF。一个SBE可控制一个或者多个DBE，SBE和DBE可部署在同一设备中或者各自独立分离工作。SBC就是一种典型的产品示例。用户可以查看笔者历史文章了解SBC功能和使用。SBE和DBE各自分离部署的更多讨论，读者可以查阅ALTC规范，RFC6947。

Decoding dependency：媒体层级之间都有一定的关系。此规范定义了解码依赖关系：layered coding 和 multiple description coding (MDC)。

Default destination/candidate：媒体流模块的默认目的地地址是传输地址，不是ICE aware的agent使用这个传输地址。对RTP模块来说，这个默认地址是标识在SDP的“c=”行，端口标识在SDP的“m=”行。对于RTCP来说，当默认目的地出现在rtcp属性中，当默认目的地没有出现时，此IP地址出现在 “c=” 行，端口加1，端口出现在“m=“行。一个模块的默认候选对象是它的传输地址匹配此模块的默认目的地地址。

File receiver：文件接收方，它愿意从发送方接收一个文件。

File selector：SDP offer的一个文件属性元组，它包含在SDP中以便在SDP answerer中选择一个文件。当发送方生成文件后，发送方必须明确无误地知道接收方的身份信息。RFC5547使用了File selector标识来处理这个问题。File selector主要目的是为对端提供足够的文件信息，确保本地和远端文件相关者能够使用的是同一文件。此定义涉及了很多的语法细节和具体的文件属性，因为篇幅关系，这里笔者不能展开讨论。关于File selector的规范说明，用户可以查看RFC5547-5章节。

File sender：文件发送方，它愿意从发送方对接收方发送一个文件。

Foundation：一个基础任意字符串，计算此值得规范是这样的。某种条件下，对于两个候选对象来说，基础字符串是是相同的。这两个候选对象必须具有同样的类型，base IP address和传输协议(UDP，TCP，等），和STUN或TURN服务器。如果它们中的其中任意一个不同，那么这个foundation将会不同。两个候选对象配对如果具有同样的foundation配对的话，这样的候选配对可能具有同样的网络特性。Foundations使用在Frozen algorithm中。Frozen algorithm的处理方式如下：

用户可以查看ICE创建的九个步骤来进一步学习：

http://www.jdrosen.net/uploads/1/5/0/0/15008848/ice-ietf-tutorial2.pptx

Full：一种ICE部署方式，它执行一系列本规范（RFC5245）定义的功能设置。解码SDP和候选对象处理都需要涉及到full implementation和lite implementation。关于两种部署方式的使用，读者需要查看RFC 5245-4.1，4.2和4.3章节。在此规范的以上章节中讨论了部分应用方式。

Lite：一种ICE部署方式，它忽略了某些功能支持能力，仅尽可能多为peer 部署提供支持。Lite implementations 不会维持任何状态机，并且也不产生connectivity checks。

Host candidate：本地主机候选对象是通过从主机的一个IP地址来绑定一个具体的端口实现的候选对象。此主机候选对象包括了物理网口的IP地址和逻辑地址，例如通过VPN获得的地址和RSIP地址（RFC 3102）。

Identification-tag：一个唯一标识值，它用来确认一个"m="行。此SDP “mid” 属性关联一个"m=" 行，传输一个唯一的identification-tag。在每个"m="后出现，通过SDP “group” 属性传输identification-tags列表，每个 "m="行关联一个特别的分类组。group（RFC5888-5）的语法为：

group-attribute     = "a=group:" semantics
 *(SP identification-tag)

完整LS的语法如下（LS表示Lip Synchronization (LS），参考RFC5888-7）：

mid-attribute      = "a=mid:" identification-tag
identification-tag = token
示例：
v=0
o=Laura 289083124 289083124 IN IP4 one.example.com
c=IN IP4 192.0.2.1
t=0 0
a=group:LS 1 2
m=audio 30000 RTP/AVP 0
a=mid:1
m=video 30002 RTP/AVP 31
a=mid:2

这里，读者需要注意，token是通过RFC4566-9规范定义的。在此规范中，因为媒体类型不同，token划分为不同的含义，其中，1表示语音，2表示视频，t ext或者其他的应用，例如语言支持等。

Latent configuration：latent configuration是一种潜在隐藏配置，它用来表示哪一种能力租户可以在将来的会话以及关联媒体的协商中使用。Latent configurations 既不准备现在使用，也不准备在当前offer/answer交互模式中的实际协商能力或潜在协商能力中使用。Latent configurations 仅通知实体可能支持的配置。这些潜在配置可以为后续的offer/answer交互模式提供一个指导建议，但是，潜在配置不能作为当前offer/answer 交互的一个部分。笔者可能觉得此概念非常迷惑，笔者通过一个简单示例来说明潜在配置的作用。例如，如果一方对另外一方创建了一个会话，并且发起一个语音呼叫时，同时，发起方可以对对方声明另外一个潜在支持能力，在同一会话中，通知对方，发起方也可以支持视频能力。对方获悉发起方还有一种潜在的能力（支持视频能力），这个潜在配置就是一种latent configuration。它必须包含一个"mt="行。具体用法和规范参考RFC6871-3.3.5。本章节后续部分，笔者还将讨论另外一种潜在配置形式。

Layered coding dependency：它也称之为layered encoding schemes。它会把媒体解码成不同的层级。当所有媒体分区的依赖分区都在有效状态时，每个媒体分区才有用。因此，媒体分区之间的依赖关系创建了一个定向图示。注意，一般情况下，在一个层级编码中，使用更多的媒体分区，可能会取得更好效果。简单来说，接收方媒体的质量取决于收到的层级的数量。SDP提供了一种方式来同组不同多播地址传输的层级，通过"c="行来定义：

c=IN IP4 233.252.0.1/127/3

以上语法定义了三个层级，等同于以下语法（3个"c="层级，不同的测试多播地址）：

c=IN IP4 233.252.0.1/127
c=IN IP4 233.252.0.2/127
c=IN IP4 233.252.0.3/127

更多关于layered encoding schemes内容，读者可查阅RFC4566-5.7和RFC5888-8.5.2。

Local candidate：本地候选对象是一个agent，此agent已经获得，并且已经被包含在它发送的offer或answer消息中。

Media Bitstream：一种有效的，可解码的媒体，此媒体流包含所有的由解码器生成的媒体分区。媒体比特流通常遵从一个媒体解码标准。

Media capability：一系列能力合并组合，媒体能力关联这些媒体能力是通过声明一种媒体格式和其相关参数关联的方式来实现。

Media format capability：一种媒体格式，通常情况下所指一种媒体的子类型，例如 (PCM)的 μ-law 算法algorithm (PCMU)，H263-1998或者T38传真算法等。

Media format parameter capability：在能力格式中设定的媒体参数，例如SDP约定中的"a=fmtp" 行。媒体能力参数和媒体格式能力关联。

Media partition：媒体比特流的子项，它的目的是实现传输相互关联。媒体分去掉整数号码构成了一个媒体比特流。在层级编码中，一个媒体分区表示一个或多个分层，它们各自表示一个或多个描述，通过绑定它们来组成一个单元（参考Layered coding dependency的"c="行介绍）。

Media stream：一个媒体流是一个单个媒体实例（例如，一个语音流，或者视频流，白板功能或者共享应用组）。在SDP中，媒体流是通过"m="行和关联属性。

MDC dependency：MDC全称是Multiple Description Coding，其基本工作原理是把单个媒体流分片处理为n个子媒体流（n ≥ 2），携带其媒体描述。每个数据包携带其描述同时提供不同节点路由到目的地端。如果需要对此媒体流进行解码的话，可以使用任何一个描述来处理，但是，媒体质量的提升取决于同时收到的媒体描述数量。因此，在互联网环境中，多描述编码的依赖关系可以有效解决视频通信中数据丢包和网络拥塞的问题，因为使用MDC处理方式无需重传数据。N-out-of-M媒体分区是一种比较复杂的MDC类型，其中N和M的值取决于媒体比特流的属性。使用MDC时，所有针对Operation Point（操作点）的媒体流必须通过identification-tag和fmt-dependency确认。另外一种解码依赖处理方式是Layered decoding dependency，和MDC相比各有其优缺点。如果读者有兴趣的话，可以查阅RFC5583-7章节和参考资料的链接来学习。MDC的语法格式为：

depend-attribute =
           "a=depend:" dependent-fmt SP dependency-tag
              *(";" SP dependent-fmt SP dependency-tag) CRLF

   dependency-tag   =
           dependency-type *1( SP identification-tag ":"
           fmt-dependency *("," fmt-dependency ))

   dependency-type  = "lay"
                    / "mdc"
                    / token

   dependent-fmt = fmt

   fmt-dependency = fmt

MDC信令示例：

v=0
o=mdcsrv 289083124 289083124 IN IP4 host.example.com
s=MULTI DESCRIPTION VIDEO SIGNALING Seminar
t=0 0
c=IN IP4 192.0.2.1/127
a=group:DDP M1 M2 M3 // DDP：Decoding Dependency
m=video 40000 RTP/AVP 104 // 依赖 M1
a=mid:M1
a=depend:104 mdc M2:105 M3:106 // 104 依赖 M2-105和M3-106
m=video 40002 RTP/AVP 105
a=mid:M2
a=depend:105 mdc M1:104 M3:106
m=video 40004 RTP/AVP 106
a=mid:M3
a=depend:106 mdc M1:104 M2:105

以上示例中，会话描述中支持了三种媒体描述。所有视频媒体使用MDC处理方式。每个媒体描述包含一个媒体格式。DDP 解码依赖组包含了三个M组。媒体格式描述104依赖于媒体格式描述105和106。这里，媒体格式描述105和106用来优化媒体格式描述104的，但是它们可以不被解码（前面提到，多个描述可以帮助优化媒体质量）。

Nominated：如果一对有效的候选配对已经指定了flag标识设置，这表示ICE可能会选择此后续配对发送和接收媒体。

Offer：一个SDP消息，由offerer发送。

Offerer：一个agent，此agent生成一个会话描述来创建或者修改会话。

Offerer BUNDLE address：在一个给定的 BUNDLE group，offerer使用一个IP地址和端口组合接收所有的媒体，此媒体是通过在BUNDLE组中设定的每个"m="行标识。

Offerer BUNDLE-tag：在offer消息中，给定SDP “group:BUNDLE”属性identification-tag列表中的第一个identification-tag。

Operation point：在分层编码（layered coding）中的一个操作节点，包含所有媒体分区的媒体比特流的子集，此子集为了在某些操作节点重构媒体质量，错误自适应和其他属性的，它不包含任何其他媒体分区。在MDC编码中，这些MDC的子集需要遵从MDC的编码标准。

Ordinary check：一种常规检测，是一种connectivity check，它由agent生成作为定时器的结果，此定时器定期触发，命令agent发送一个检查。注意，常规检测仅支持full implementations。RFC 5245-5.8有关于对常规检测定时说明，读者可以去做进一步了解。

Peer：在会话过程中，从其他agent角度看到的其中一个agent，它们的peer也是其他agent。具体来说，如果从offerer的角度看，它的peer就是一个answerer。反之亦然，如果从answerer的角度看，它的peer就是offerer。

Peer reflexive candidate：一个候选对象，此候选对象是这样定义的-当候选对象通过NAT对其peer发送一个STUN绑定请求时，NAT已经把候选对象的IP地址和端口绑定分配给一个agent。在RFC 5245的第七章中有关于如何发现Peer reflexive candidate和对Peer reflexive candidate的自我学习处理。

Potential configuration：一个潜在的配置，它表示会话和关联的构件所支持的媒体能力组合。此配置不能现在使用。但是，此配置可为当前的offer/answer交互提供未来可用的能力，它为当前的offer/answer交互提供了一种可选方式，可以替代实际配置。注意，笔者在前面介绍了Latent configuration，这里又介绍了potential configuration。如果我们简单从字面意思好像没有什么区别，事实上，它们之间存在根本区别。Latent configuration是一种潜在“隐藏”的能力，支持未来协商能力，而Potential configuration是本身“已具备”的能力，可以替代当前实际配置。关于Latent configuration的定义，笔者在前面内容已经有所介绍，笔者一定要注意这两种配置的使用场景。更多关于两种配置的规定说明，读者可以参考RFC 5939-3.1和RFC6871-2。

Pull operation：它是一种文件传输操作，在提取操作中，SDP offerer充当文件接收方角色，并且 SDP answerer充当文件发送方的角色。

Push operation：它是一种文件传输操作，在推送操作中，SDP offerer 充当文件发送方角色，并且SDP answerer充当文件接收方的角色。以上两个操作方式的规定在RFC5547 官方中定义。

Regular nomination：一个对媒体流提取有效候选配对的过程，此过程是通过一个STUN请求对配对进行验证，选择出有效候选配对，然后通过发送第二个STUN请求，在第二个STUN请求中携带一个标识来表示其提名。它和ICE使用的另外一种nomination-Aggressive Nomination的标识方式有所不同。后者处理速度比较快，但是缺乏灵活性，前者则具有更强的灵活性。这里，L表示本地，R表示远端，在第二个STUN请求中携带flag标识，表示其被提名。

Regular nomination 处理流程（RFC 5245-2.6）

Relayed candidate：它是一个候选对象，具体获得的方式是，通过从本地主候选对象对TURN 服务器发送一个TURN Allocate 请求而获得的对象。转发候选对象部署在TURN服务器，此TURN服务器然后转发数据返回到agent。

Remote candidate：一种候选对象，是agent从其peer发送的offer或者answer消息中收到的候选对象。

Selected pair, selected candidate：selected pair是由ICE选择的候选对象配对，它用来发送和接收媒体，候选对象中的每个candidate称之为。具体定义可参考RFC 5245。

Server reflexive candidate：它是一种候选对象，其IP地址和端口是一个绑定关系，当候选对象通过此NAT发送数据包到一个服务器时，绑定通过NAT分配给agent。Server reflexive candidates通过STUN 服务器使用Binding请求或者通过TURN服务器具进行学习。一旦Server reflexive candidate被分配以后，它们必须一直保持活动状态，直到ICE处理完成。对于通过绑定请求学习的Server reflexive candidate，绑定需要维持的话，Server reflexive candidate必须一直发送对服务器端额外的绑定请求。刷新请求同样也刷新Server reflexive candidate。具体的定义在RFC 5766-2章节。candidate本身有自己的类型和base。RFC5245中对type定义了4种方式，Server reflexive candidate就是其中一种，其他三种分别是host candidates，peer reflexive candidates和relayed candidates。这些类型我们在此文章中也做了介绍。获得这些candidates的方式有所不同，用户在理解这些对象是需要注意，同时要结合前面的介绍针对每个类型有一定的了解，这样可以帮助读者消化ICE处理的整个流程。关于如何获得这几种类型的candidate，读者可以阅读RFC5245-4.1.1部分章节。

Session：一个多媒体会话是一系列多媒体发送方和接收方，还包括从发送方到接收方的数据媒体处理流程。多媒体会议就是一个多媒体会话的实例。

Session description：会话描述是一种定义完整的消息格式，在多媒体会话中，它是用来传输有效信息，以便发现和参与会话流程。

Shared address：一个IP地址和端口的组合，在offer或answer消息中，它通过多个"m=" 行发生关联关系。

Subsequent offer：一种offer消息，它包含一个BUNDLE group，此BUNDLE group已经在在前面offer/answer交互中创建，是前面交互的一个部分。

Transport address：IP地址和传输协议（UDP或者TCP）的组合地址。

Triggered check: Triggered check（已触发的check）是一种 connectivity check，它的目的是作为一个从peer收到的connectivity check凭证的结果。更多关于此定义的说明包括Triggered check queue，读者可查阅RFC 5245-7.2.1.4章节的内容。

Unique address：此地址是一个IP地址和端口的组合，它通过在offer或者answer消息中的仅一个"m="行关联。

Valid list：针对媒体流的一组有序候选对象配对，此列表已经由一个成功的STUN事务验证通过。

在本章节的接下来的内容中，笔者将继续讨论 SDP的使用方式，SDP要求和建议以及规范标准概览。为进一步了解SDP打好基础。

参考资料：

原文出处：完整SIP/SDP媒体协商概论-SDP基础-使用-要求

接完整SIP/SDP媒体协商概论-SDP基础-核心定义全解。上一个章节笔者介绍了关于SDP的一些核心概念（第一章节和第二章节），今天，我们继续在此之间讨论SDP的其余基础内容（从第三章节开始）。在以下讨论中，笔者会介绍关于SDP的使用，SDP的要求建议和SDP规范概要，介绍SDP的属性，安全讨论和语法格式。

3 SDP使用方式

一般情况下，应用场景都至少是在两方或者多方参与者之间进行。多方语音或者视频应用场景中，系统需要对话型的多媒体应用来传输会话描述。为了会话创建，会话描述允许参与者同意它们之间的一系列兼容性能力的协商。为了客户端和服务器端之间的媒体传输，多媒体流要求一系列的恰当的媒体协商来保证客户端和服务器端的传输。在所有的用户创建中，SDP用来传输通信参与方之间的会话信息来支持它们之间的媒体能力协商。因此，SDP主要可以使用在以下五个方面的应用中：

4 SDP要求和建议

前面笔者已经多次介绍SDP的作用和目的，这里我们再次简单强调一下。SDP的目的是在多媒体会话中传输多媒体流，支持会话描述的接收参与到会话中。在实际应用场景中，不同场景有对多媒体和会话有不同的要求。媒体流的呈现方式可以是多对多的形式，会话有时也根据业务要求，有时不会继续呈现活动状态。目前来看，网络中的基于多播会话的形式和其他会议形式有一点不同，任何接收会话数据方可以加入到会话中（除非会话流量加密）。在这种场景中，SDP有两个基本的目的，SDP是一种已存在会话的通信手段，它同时也是一种对参与方传输有效信息开启和参与会话的手段。在单播环境中，SDP的目的可能和后一种方式接近。因此，一般来说，SDP会话描述需要包括几个方面的内容：

以上信息是SDP会话描述的基本要求，SDP会话描述需要的具体类别消息内容包括：

接下来的章节，笔者将继续讨论SDP基础的第三部分，关于细节规范的总体介绍。

参考链接：https://www.rfc-editor.org/rfc/rfc2974

原文出处：完整SIP/SDP媒体协商概论-SDP基础-会话描述说明

在上一章节 SDP基础-使用和要求的章节中，笔者讨论了关于SDP的使用场景和一些SDP语法构建。这里，我们根据SDP的规范说明，重点介绍SDP具体的会话描述和媒体描述参数。

5 SDP规范标准

总体来说，SDP会话描述的语法由五个核心部分构成，它们分别是：会话元数据，流媒体，服务保障，网络和安全。

Session metadata(会话元数据)描述了会话本身所需要的数据标识，包括SDP协议版本，会话发起方描述，会话身份确认描述和会话活动时间。

Stream description包含了媒体功能的描述细节和参数。

QoS描述包含了所有媒体流性能参数，它可能通过其他信息的调用对多媒体流打包支持带宽和其他资源的优化。

Network description可能包括各种传输协议（TCP，UDP等）和网络协议以便支持多媒体会议参与方之间的媒体收发。

Security 描述包括了密钥，签权，认证，不可否认性，完整性内容。

一个SDP会话描述通过媒体类型标识为："application/sdp"。SDP会话描述完全是一种文本格式，其格式遵从UTF-8解码规范。其基本的语法规范是：

<type>=<value>

这里，type必须是一个大小写敏感的字符，value是一种具有一定结构的文本，value的格式完全取决于type的取值。通常情况下，value可以是多个值域或者一个自由文本格式。如果value包含多个值域的话，通过单空格隔离。注意，“=”两边决定不能使用空格。

SDP会话描述由会话级描述紧接着零或多个媒体级的描述构成。其中，会话级描述以"v="行开始，一直继续到第一个媒体级的"m="行之前结束。媒体级会话描述以"m="行开始，然后继续到下一个媒体级或整个会话描述结束。通常来说，除非媒体级的值覆盖默认设置，一般来说，对所有媒体来说，会话级的设置是默认的。会话描述行分为必要设置和可选设置两个部分，其会话描述文本格式必须按照固定顺序呈现，这样可以方便处理，避免语法错误。其中，可选会话描述设置带一个"*"字符作为标识。

v=(protocol version) // "v" 开始
o=(originator and session identifier)
s=(session name)
i=* (session information)， 可选
u=* (URI of description)
e=* (email address)
p=* (phone number)
c=* ( connection information -- not required if included in all media)
b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below)
z=* (time zone adjustments)
k=* (encryption key)
a=* (zero or more session attribute lines)
Zero or more media descriptions， 这里可能无媒体会话

媒体描述示例：

m=(media name and transport address) // "m" 开始
i=* (media title)
c=* (connection information -- optional if included at session level)
b=* (zero or more bandwidth information lines)
k=* (encryption key)
a=* (zero or more media attribute lines)

接下来，笔者重点介绍几个常用的会话描述设置，主要包括会话级参数，时间和媒体级参数设置。其他的会话描述在后续具体章节中再做阐述。

Protocol Version ("v=")，其语法格式为：

v=0

"v"定义了SDP版本。此规范定义的是0，没有子版本。

Origin ("o=")，其语法格式为：

o=<username> <sess-id> <sess-version> <nettype> <addrtype> 
<unicast-address>

"o=" 定义了会话发起方名称，sess-id 是一个数值字符串，通过用户名称，sess-id，nettype，addrtype，和unicast-address构成了一个全局唯一认证ID，是此会话描述的版本号，是一个文本字符串，表示网络类型，初始设置是”IN"表示Internet。是一个文本字符串地址，表示是IP4或IP6，也可能使用其他的值。，此地址是一个创建此会话的机器地址。

Session Name ("s=")， 其语法格式为：

s=<session name>

"s="定义了文本会话名称，这里必须是仅一个会话名称，此名称不能为空，其字符串应该包含ISO 10646字符。

Session Information ("i=")， 其语法格式为：

i=<session description>

"i=" 提供了关于此会话的文本信息，每个会话描述必须有一个"i="，一个媒体至少有一个"i="。如果出现了"a=charset"属性的话，它会设定"i="的字符设置。如果没有出现"a=charset"的话，"i="必须包含用UTF-8解码的ISO 1646字符。单个"i="也可以使用在每个媒体定义中。在媒体定义中，"i="的主要目的是为了标注媒体流。因此，这种标注方式对单会话环境中有同一媒体类型，它需要支持完全不同的媒体流时非常有用。例如，两个不同的白板功能，一个白板是支持自己的幻灯片播放，另外一个白板支持问题答疑和回复处理。

URI ("u=")，其语法格式为：

u=<uri>

URL是WWW用户使用的处理方式，URL应该指向一个针对此会话的其他另外资源地址。此描述是可选描述。但是，如果它出现的话，它必须出现在第一个媒体前面 。在每个会话描述中不允许第二个URL出现。

Email Address 和 Phone Number ("e=" 和 "p=")，其语法格式为：

e=<email-address>
p=<phone-number>

"e=" 和 "p="定义了负责会议的联系人信息。是否包含"e=" 和 "p="是可选的。这两个会话描述使用不是非常广泛。但是，如果出现了邮箱和电话号码的话，它们必须出现在第一个媒体域前面。一个会话可以支持一个或者多个邮箱或者电话号码。电话号码的格式必须按照ITU-T推荐格式来定义，号码前加一个”+“前缀，并且使用”-“分离电话号码，方便用户阅读。例如：**

p=+1 617 555-6011

**如果是电子邮件的话，两种格式都可以支持：

e=j.doe@example.com (Jane Doe)
或者
e=Jane Doe <j.doe@example.com>

Connection Data ("c="), 其语法格式为：

c=<nettype> <addrtype> <connection-address>

它包含一些连接数据。在会话描述中，媒体描述必须至少包含一个"c="行，或者在会话级包含一个单个"c="行。在某些应用场景中，预设的媒体设置可以覆盖默认的设置会话级的参数。因此，在每个媒体会话中，"c="可以包含一个单个的会话级的"c="和其他另外的子"c="行。这里的和值和前面介绍的一样，读者参考前面的介绍。是一个连接地址，在连接地址后可以增加另外的子项，这些子项取决于类型（是IP4还是IP6地址）。如果会话在多播方式做工作，连接地址必须是一个多播地址组，如果会话在单播方式工作，则广播地址是单播地址。如果会话使用的是一个多播IP4类型的话，多播连接地址必须支持存活时间（TTL），TTL取值范围在0-255之间（例如：c=IN IP4 224.2.36.42/127，TTL是127）。注意，IP6没有使用TTL，因此也没有TTL设置，TTL肯定不会出现在IP4中。IP6使用的是一种继承或层级方式来实现连接地址的处理（例如：c=IN IP6 FF15::101， 无TTL）。

Bandwidth ("b=")，其语法格式为：

b=<bwtype>:<bandwidth>  // kilobits per second

它是一个可选会话描述，表示对会话或者媒体建议使用的带宽。带宽类型子项是以字母方式表示（我们这里讨论的是支持两种类型：CT和AS，还有可能出现TIAS），针对后面的带宽数值描述。CT和AS在创建使用上有明显的不同。CT（Conference Total）表示多会话广播中会话或者媒体使用的最大带宽建议值，CT值相当于所有会话带宽值。AS(Application-Specific)是指具体某个应用程序所占用的总带宽建议值，相当于最大应用程序带宽值，它仅值单媒体在单点所占用的带宽。如果读者对AS有兴趣的话，可以阅读RFC3550-6，RFC3556-2中的RS/PR收发带宽修改机制和RFC3890关于Bandwidth Modifier的规范说明。

Timing ("t=")，其语法格式为：

t=<start-time> <stop-time>

它设置了启动和停止会话的时间。如果在非正常周期时间段启动会话，此会话需要增加多"t="行。每个"t="支持另外一个时间段表示会话在此时间段是活动状态。如果会话使用在正常时间周期，"t="后面加了一个"r="行表示重复次数。这两个时间标识使用的是NTP的十进制的方式表示，以秒为单位。此时间规范在RFC1305中有非常明确的发明，此时间不是UNIX定义的时间，用户可以参考转换方式来进一步了解如何转换。 如果设置为0，则表示会话不受限，除非后，此会话才会被启动。如果设置为0，则表示此会话是一个永久会话。通常情况下，规范不建议在用户接口或者其他应用控制界面设置这两个时间取值，这样会导致会话时间错乱，会话控制失效。

Repeat Times ("r=")，其语法规则为：

r=<repeat interval> <active duration> <offsets from start-time>

它定义了对此会话的时间重复次数。"r="行的取值是根据前面的"t="决定的。

Time Zones ("z="), 其语法格式为：

z=<adjustment time> <offset> <adjustment time> <offset> ....

会话时差处理。为了对重复的会话（此会话贯穿一个白天晚上到标准时间的修改流程，或者相反处理）进行定时处理，有必要对标准时间设定一个偏移时间数值。这样就要求针对不同的时间对应不同的时间标准。每个国家可能都有自己的时差日期基准。因此，为了保证对同一会话在不同时期进行定时处理，必须对数据双方双方明确设定一个时间基准和偏移值。

Encryption Keys ("k=")，其语法结构如下：

k=<method>
k=<method>:<encryption key>

如果传输消息需要通过一个安全的传输方式进行的话，SDP可以用来传输密钥。"k=" 行提供了一个简单的密钥交换机制。为什么说是简单的交换机制？因为当初设计"k="行的主要目的是考虑和旧部署规范的兼容性支持，也不是规范所推荐的使用方式。"k="本身不具有拓展性，支持不了更多传输参数和密钥管理功能，一些比较新的密钥交换机制也逐步使用在了SDP会话描述中。"k="使用仍然在更新中，一些语法和内容相对比较旧（例如缺少安全协议中要求的两个密钥的支持：confidentiality 和integrity），因此，笔者不打算在这里再展开讨论。关于"k="具体的使用方式，用户可以通过RFC4567规范和RFC4568做更加详细的理解，这两个规范中增加了更多对SDP的拓展支持。这些交换机制和密钥管理也会使用在一些新的应用场景中。

Attributes ("a=")，其语法格式为：

a=<attribute>
a=<attribute>:<value>

Attributes 表示拓展的SDP的基本含义，我们这里翻译为特征属性。特征属性参数可以定义在会话级和媒体级。媒体描述中可以定义多个"a="行来定义具体的媒体特性。"a="可以出现在第一个媒体描述前，这是会话级的属性参数，这样的属性是针对整个会议会议定义的，不是针对单独媒体定义的属性。特征Attributes属性可以支持两种属性格式

"a=<flag>."  // 例如："a=recvonly." 
"a=<attribute>:<value>. // 例如 "a=orient: landscape."

特征属性的取值取决于使用的媒体工具。特征属性的值除了0x00 (Null)，0x0A (LF)，和 0x0D (CR)以外，可以是任何octet字符串。默认取值解析为ISO-10646字符形式，通过UTF-8解码取值。如果接收方不理解已接收的特征属性值，接收方必须忽略此特征属性值。

Media Descriptions ("m="): 其语法格式为：

m=<media> <port> <proto> <fmt> ...

一个会话描述中可以包含多个媒体描述。每个媒体描述以"m="开始，媒体描述结束以下一个媒体描述开始或者以会话描述结束来结尾。一个媒体描述包含几个媒体描述子项：

，它表示媒体类型，目前定义的媒体类型包括语音，视频，应用程序，和消息。未来可能还有其他类型，用户需要密切关注。

，它是一个传输端口，媒体发送到此端口。此端口依赖于"c="行定义的网络传输协议。其他被媒体应用程序使用的端口，例如RTCP端口需要根据其基准端口来设定相应的端口，或者分开特征属性设置。如果使用了非连续端口或者没有遵从偶数-RTP端口，奇数-RTCP端口的规则处理的话，必须增加一个"a=rtcp:"行。应用程序被发送到一个端口，此端口是一个奇数端口，并且出现"a=rtcp:"行时，此媒体一定不能从RTP端口减一，应用程序必须发送RTP数据到指定的端口，并且发送RTCP到"a=rtcp"属性设定的端口。对于某些应用程序，它们的媒体流通过层级解码发送到单播地址时，它们有必要设定多个传输端口。使用语法和多播地址的方式类似： m= / ...。这种场景中，使用的端口依赖于传输协议类型。一些读者可能明白，通常默情况下，RTP使用偶数端口传输数据，它的RTCP使用高一位数的奇数端口控制RTP会话。表示RTP会话数量。例如：

m=video 49170/2 RTP/AVP 31

这里，媒体会话将设定一个视频媒体类型，端口从49170开始计算，包括两对RTP媒体会话，其中第一对媒体会话是49170端 口（RTP）和 49171 端口（RTCP）。第二对是从49172（RTP）和49173端口（RTCP）端口。RTP/AVP是传输协议，31是媒体格式（fmt，H261）。以上介绍的是默认环境中使用的连续端口，如果端口使用的是非连续的端口，需要增加属 性"a=rtcp:" 分开独立的端口属性。

，它是传输协议。这里的传输协议依赖于"c="行定义的地址类型。目前支持的主要的几个类型包括：UDP，RTP/AVP，RTP/SAVP。这里专门针对媒体格式设定不同的传输协议是因为同一网络协议时，标准的媒体格式可以通过不同的传输协议来进行传输。这样的设定可以支持不同的网络传输和满足不同检测工具部署。

，它表示一种媒体格式描述。前面第四个子项或者其他后续子项都表示媒体格式。媒体格式描述的解析依赖于子项的值。如果 子项是"RTP/AVP"或者"RTP/SAVP，媒体格式描述会包含RTP payload 类型号码。当给定了一个payload类型列表时(静态方式，从96-127)，这表示所有的媒体格式可以适用于此会话中，但是，通常列表中的第一个格式应该作为此会话默认支持格式。如果payload类型列表是动态的payload类型列表的话，SDP使用"a=rtpmap:"属性来执行一个映射（从RTP payload 类型号码到媒体解码名称），通过媒体类型号码到媒体解码名称的对应关系来确认payload格式。"a=fmtp:" 行可以用来设定具体的媒体格式参数。在很多应用场景中，用户可以看到动态payload不匹配导致的问题，例如Asterisk或者FreeSWITCH的运行环境中，我们经常看到类似的错误：

Unsupported payload type received

关于动态payload的规范定义，用户可以查阅RFC3551-6。

6 SDP属性说明/IANA/ABNF

除了我们前面介绍的会话描述和媒体描述说明以外，SDP以支持了特征属性的拓展，通过拓展的属性可以支持更多的属性参数。SDP属性支持了会话级和媒体级属性两种。会话级属性顾名思义，它是针对会话层级的属性。媒体级属性针对媒体属性设置所设置的属性。大家经常遇到的也是一些在应用场景中常见的属性设置，我们这里也不可能做一个非常完整的归纳。因此，因为篇幅所限，笔者只能介绍一下其基本的语法构成:

a=tool:<name and version of tool>

具体在一般场景中看到的例如：

a=ptime:<packet time>

此特征属性表示一个数据包中的媒体打包时长的特征属性。如果使用RTP映射的话，使用的语法为：

a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding
parameters>]

另外，为了规范SDP会话描述中的语法格式，读者也需要了解几个相关的规范，这些规范定义了SDP的语法规则。IANA和ABNF是在SDP规范中需要了解的基本语法，其中，ABNF规定了一些基本的规则，包括空格，大小写，分割行和各种会话描述，媒体描述以及特征属性的完整说明。

7 总结

在本章节中，笔者重点介绍了关于SDP规范细节的会话描述部分以及相关的拓展属性介绍。笔者通过三个子章节的篇幅，基本介绍了SDP的使用方式和要求，增加针对SDP会话描述和媒体描述的规范细节做了充分说明和拓展介绍，并且对SDP的特征属性已经IANA和ABFN做了一些简单介绍。以上内容都相对比较抽象，读者需要在实际生产环境中不断练习，不断解决排查问题，才能对这些内容有进一步的了解。

到此为止，笔者已经完整介绍了SDP的基础和核心语法。这些基础的内容为我们后续章节的介绍打下了一个比较好的基础。在接下来的章节中，我们将首先完整介绍SDP的协商模式。

再次说明，因为很多约定用语需要翻译成中文的含义，本文中的翻译风格或者理解不同可能有一些出入，希望读者谅解。

参考链接