完整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-headerCRLF[ 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：

REGISTER：用户注册Method
INVITE，ACK，和CANCEL：用来呼叫和创建会话
BYE：结束会话
OPTIONS：查询服务器端支持能力
MESSAGE：即时聊天
REFER：呼叫转移
SUBSCRIBE和NOTIFY ：SIP会话相关的事件管理
PUBLISH：发布SIP指定事件状态
UPDATE ：更新会话参数
INFO：支持mid-session 信息转发
PRACK：类似请求确认

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

　　在日常的排查活动中，系统技术人员需要以上状态码来判断系统所处状态。当然，在六大状态分类中，还有其子分类，子分类中包含了更加详细的说明。用户可参考RFC 3261-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消息中，读者需要了解基本的消息格式，其中请求消息格式和响应消息告诉都有不同的语法结构。两者的消息内容有明显的区别：

请求消息格式包括三个主要部分：Request-Line，Header和Message-Body。
响应消息格式包括三个主要部分：Status-Line，Header和 Message-Body。

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

　请求消息格式规范

　　响应消息格式规范

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

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

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

　　SIP和其他相关协议的关系

　　通过以上图例读者可以看到，事实上，在一个普通的应用环境中，一个环境可能涉及了很多终端和服务器端以及各种应用程序的协商支持，通过确保双方功能协商和性能能力的协商，确保双方具有一系列共同确认的参数才能进行通信(例如，传输方式是否相同，端口是否一致，编码是否支持)。因此，双方都认可的，标准的，共同支持的协商机制是必不可少的。SDP就是SIP协议中进行协商的标准机制。

　　通过以上对SIP以及基本语法的介绍，我们大概了解了SIP的消息和一些必要的请求响应消息体构成。接下来，笔者从宏观的角度介绍一下SIP网络技术环境中一些核心的实体构件，包括支持SIP场景的客户端和服务器端的功能，以及SIP/SDP整体协商流程。

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

定位服务：决定通信使用的最终终端系统。
用户有效性：决定被呼叫方是否有意愿加入到通信环境中。
用户媒体支持能力：决定双方通信所需要的媒体和媒体参数
会话创建：创建会话，启动ring振铃等。
会话管理：转接，修改会话参数，发起其他服务，结束会话等。

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

　　在以上图例中，我们看到一些核心的模块包括了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定义：

　　Conference-unaware UA：最简单的UA，参与电话会议，忽略了所有SIP相关消息。此UA可通过拨号加入会议或者被邀请加入会议。它仅支持RFC 3261规范。

　　Conference-aware UA-此UA可以支持呼叫控制，另外可以支持SIP转发处理，也可以订阅消息等。

　　Focus-控制发起会议，负责会议呼叫控制，包含一个Conference-aware UA。

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

　　深入理解SIP服务器的注册和定位服务流程

　　3、关于WebRTC基本介绍

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

　　完整WebRTC技术及应用概要

　　4、总结

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

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

　　参考资料：

　　https://www.ccexpert.us/network-design/call-control-and-transport-protocols.html

　　https://ribboncommunications.com/company/get-help/glossary/call-control

　　https://tools.ietf.org/html/rfc5589

　　https://en.wikipedia.org/wiki/Skinny_Call_Control_Protocol

　　https://www.itu.int/rec/T-REC-Q.1912.5-200403-S/en

　　https://tools.ietf.org/html/rfc3261