一篇文章读懂SDP、RTMP、HLS、SIP、MMS

SDP

会话描述协议（SDP）为会话通知、会话邀请和其它形式的多媒体会话初始化等目的提供了多媒体会话描述。参考RFC2327
       会话目录用于协助多媒体会议的通告，并为会话参与者传送相关设置信息。SDP 即用于将这种信息传输到接收端。SDP 完全是一种会话描述格式 ― 它不属于传输协议 ― 它只使用不同的适当的传输协议，包括会话通知协议（SAP）、会话初始协议（SIP）、实时流协议（RTSP）、MIME 扩展协议的电子邮件以及超文本传输协议（HTTP）。

        SDP 的设计宗旨是通用性，它可以应用于大范围的网络环境和应用程序，而不仅仅局限于组播会话目录，但 SDP 不支持会话内容或媒体编码的协商。
        在因特网组播骨干网（Mbone）中，会话目录工具被用于通告多媒体会议，并为参与者传送会议地址和参与者所需的会议特定工具信息，这由 SDP 完成。SDP 连接好会话后，传送足够的信息给会话参与者。SDP 信息发送利用了会话通知协议（SAP），它周期性地组播通知数据包到已知组播地址和端口处。这些信息是 UDP 数据包，其中包含 SAP 协议头和文本有效载荷（text payload）。这里文本有效载荷指的是 SDP 会话描述。此外信息也可以通过电子邮件或 WWW （World Wide Web） 进行发送

SDP 文本信息包括：

1. 会话名称和意图；
2. 会话持续时间；
3. 构成会话的媒体；
4. 有关接收媒体的信息（地址等）。
5. 协议结构

SDP 信息是文本信息，采用 UTF-8 编 码中的 ISO 10646 字符集。SDP 会话描述如下：（标注 * 符号的表示可选字段）：

v = （协议版本） 
o = （所有者/创建者和会话标识符） 
s = （会话名称）
i = * （会话信息）
u = * （URI 描述） 
e = * （Email 地址） 
p = * （电话号码） 
c = * （连接信息 ― 如果包含在所有媒体中，则不需要该字段） 
b = * （带宽信息）

一个或更多时间描述（如下所示）：

z = * （时间区域调整）
k = * （加密密钥）
a = * （0 个或多个会话属性行）

0个或多个媒体描述（如下所示）：

时间描述：
t = （会话活动时间）
r = * （0或多次重复次数）

媒体描述：

m = （媒体名称和传输地址）
i = * （媒体标题）
c = * （连接信息 — 如果包含在会话层则该字段可选）
b = * （带宽信息）k = * （加密密钥）
a = * （0 个或多个会话属性行）

RTMP

RTMP协议是Real Time Message Protocol(实时信息传输协议)的缩写，它是由Adobe公司提出的一种应用层的协议，用来解决多媒体数据传输流的多路复用（Multiplexing）和分包（packetizing）的问题。随着VR技术的发展，视频直播等领域逐渐活跃起来，RTMP作为业内广泛使用的协议也重新被相关开发者重视起来。

它有三种变种：

• 工作在TCP之上的明文协议，使用端口1935；

• RTMPT封装在HTTP请求之中，可穿越防火墙；

• RTMPS类似RTMPT，但使用的是HTTPS连接；

RTMP协议(Real Time Messaging Protocol)是被Flash用于对象,视频,音频的传输.这个协议建立在TCP协议或者轮询HTTP协议之上。

RTMP协议就像一个用来装数据包的容器,这些数据既可以是AMF格式的数据,也可以是FLV中的视/音频数据.一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的。

RTMP协议是应用层协议，是要靠底层可靠的传输层协议（通常是TCP）来保证信息传输的可靠性的。在基于传输层协议的链接建立完成后，RTMP协议也要客户端和服务器通过“握手”来建立基于传输层链接之上的RTMP Connection链接，在Connection链接上会传输一些控制信息，如SetChunkSize,SetACKWindowSize。其中CreateStream命令会创建一个Stream链接，用于传输具体的音视频数据和控制这些信息传输的命令信息。RTMP协议传输时会对数据做自己的格式化，这种格式的消息我们称之为RTMP Message，而实际传输的时候为了更好地实现多路复用、分包和信息的公平性，发送端会把Message划分为带有Message ID的Chunk，每个Chunk可能是一个单独的Message，也可能是Message的一部分，在接受端会根据chunk中包含的data的长度，message id和message的长度把chunk还原成完整的Message，从而实现信息的收发。

HLS

HTTP Live Streaming（HLS）是苹果公司(Apple Inc.)实现的基于HTTP的流媒体传输协议，可实现流媒体的直播和点播，主要应用在iOS系统，为iOS设备（如iPhone、iPad）提供音视频直播和点播方案。HLS点播，基本上就是常见的分段HTTP点播，不同在于，它的分段非常小。
  相对于常见的流媒体直播协议，例如RTMP协议、RTSP协议、MMS协议等，HLS直播最大的不同在于，直播客户端获取到的，并不是一个完整的数据流。HLS协议在服务器端将直播数据流存储为连续的、很短时长的媒体文件（MPEG-TS格式），而客户端则不断的下载并播放这些小文件，因为服务器端总是会将最新的直播数据生成新的小文件，这样客户端只要不停的按顺序播放从服务器获取到的文件，就实现了直播。由此可见，基本上可以认为，HLS是以点播的技术方式来实现直播。由于数据通过HTTP协议传输，所以完全不用考虑防火墙或者代理的问题，而且分段文件的时长很短，客户端可以很快的选择和切换码率，以适应不同带宽条件下的播放。不过HLS的这种技术特点，决定了它的延迟一般总是会高于普通的流媒体直播协议。　
  根据以上的了解要实现HTTP Live Streaming直播，需要研究并实现以下技术关键点：

• 采集视频源和音频源的数据

• 对原始数据进行H264编码和AAC编码

• 视频和音频数据封装为MPEG-TS包

• HLS分段生成策略及m3u8索引文件

• HTTP传输协议

SIP

SIP是一个应用层的控制协议，可以用来建立、修改、和终止多媒体会话（或者会议）例如Internet电话。SIP也可以邀请参与者参加已经存在的会话，比如多方会议。媒体可以在一个已经存在的会话中方便的增加（或者删除）。SIP显示的支持名字映射和重定向服务，这个用于支持个人移动业务－用户可以使用一个唯一的外部标志而不用关系他们的实际网络地点。SIP在建立和维持终止多媒体会话协议上，支持5个方面：

用户定位：检查终端用户的位置，用于通讯。

用户有效性：检查用户参与会话的意愿程度。

用户能力：检查媒体和媒体的参数。

建立会话：”ringing”,建立会话参数在呼叫方和被叫方。

会话管理：包括发送和终止会话，修改会话参数，激活服务等等。

SIP不是一个垂直集成的通讯系统。SIP可能叫做是一个部件更合适，它可以用作其他IETF协议的一个部分，用来构造完整的多媒体架构。比如，这些架构将会包含实时数据传输协议（RTP）（RFC1889）用来传输实时的数据并且提供QoS反馈，实时流协议（RSTP）(RFC2326)用于控制流媒体的的传输，媒体网关控制协议（MEGACO）(RFC3015)用来控制到公共电话交换网（PSTN）的网关，还有会话描述协议（SDP）（RFC2327）用于描述多媒体会话。因此，SIP应该和其他的协议一起工作，才能提供完整的对终端用户的服务。虽然基本的SIP协议的功能组件并不依赖于这些协议。

SIP本身并不提供服务。但是，SIP提供了一个基础，可以用来实现不同的服务。比如，SIP可以定位用户和传输一个封装好的对象到对方的当前位置。并且如果我们利用这点来通过SDP传输会话的描述，对方的用户代理立刻可以得到这个会话的参数。如果我们用这个像传输会话描述（SESSIONDESCRIPTIONSD）一样呼叫方的照片，一个”呼叫ID”服务很容易就建立了。这个简单的例子说明了，SIP作为一个基础，可以在其上提供很多不同的服务。

SIP并不提供会议控制服务（比如议席控制或者投票系统），并且并没有建议会议应该则那样管理。可以通过在SIP上建立其他的会议控制协议来发起一个会议。由于SIP可以管理参与会议的各方的会话，所以会议可以跨异构的网络，SIP并不能，也不打算提供任何形式的网络资源预留管理。

安全对于提供的服务来说特别重要。要达到理想的安全程度，SIP提供了一套安全服务，包括防止拒绝服务，认证服务（用户到用户，代理到用户），完整性保证，加密和隐私服务。

SIP是一个分层协议，这就意味着其行为用相对独立的处理阶段集来描述，每个阶段间松耦合。为便于表述，协议的行为用层来描述，允许对功能的描述跨越元素。但是它没有规定实现。当我们说一个元素“包含”一层，我们的意思是说元素遵从该层定义的规则。并非协议指定的每个元素都包含每一层。而且，SIP所指的元素都是逻辑元素，而非物理元素。物理实现可作为不同逻辑元素，甚至是基于事务（transaction-by-transaction）的。

SIP的最低层是语法和编码。其编码指定使用巴科斯范式（BNF）

第二层是传输层。它定义在网络上客户端如何发送请求和接收响应，服务器如何接收请求和发送响应。所有SIP元素都包含传输层。

第三层是事务层。事务是SIP的基础组件。事务是客户端事务（使用传输层）向服务器事务发送的请求，以及服务器事务向客户端发回的该请求的响应。事务层处理应用层转播、响应与请求的匹配以及应用层超时。用户代理客户端（UAC）完成任何任务都使用一系列事务。用户代理包含一个事务层，如有状态代理。无状态代理不包含事务层。事务层有一个客户端组件（称为客户端事务）和服务器组件（称为服务器事务），它们都用有限状态机表示，用来处理特殊请求。

事务层之上的层称为事务用户（TU）。每个SIP实体，除无状态代理外，都是事务用户。当事务用户想发送请求时，它就创建一个客户端事务实例，并将请求与目的IP 地址、端口一起发送。创建客户端事务的TU 也可以取消事务。客户端取消事务的时候，就要求服务器停止进一步处理，并恢复到初始化事务前的状态，然后返回该事务的一个错误响应。可通过CANCEL请求完成取消事务，CANCEL请求包含自己的事务，同时也提及需要取消的事务。

SIP元素即用户代理客户端和服务器、无状态和有状态代理、注册服务器，包含区分这些元素的核心（Core）。除无状态代理外，核心是事务用户。UAC 和UAS核心的行为依赖于方法，所有方法有一些通用规则（见第8 章）。对UAC 而言，规则支配请求的结构；对UAS而言，规则管理请求的处理和响应的生成。由于注册在SIP中扮演很重要的角色，处理REGISTER 的UAS有一个特殊的名称“注册员”。第10 章描述了REGISTER 方法的UAC、UAS核心行为。

其它的请求都在对话中发送。对话是在两个用户代理间持续一定时间的对等SIP关系。对话促成两个代理间消息顺序和请求的正确路由。INVITE方法是本规范中定义的用于建立对话的唯一方法。当UAC 在对话的连接中发送一个请求时，它遵通用UAC规则以及对话中请求规则。

SIP中最重要的方法是INVITE方法，它用于在参与者间建立会话。会话是参与者和参与者间通信的媒体流的集合。

MMS

MMS (Microsoft Media Server Protocol)，中文“微软媒体服务器协议”，用来访问并流式接收 Windows Media 服务器中 .asf 文件的一种协议。MMS 协议用于访问 Windows Media 发布点上的单播内容。MMS 是连接 Windows Media 单播服务的默认方法。若观众在 Windows Media Player 中键入一个 URL 以连接内容，而不是通过超级链接访问内容，则他们必须使用MMS 协议引用该流。MMS的预设埠（端口）是1755。
  当使用 MMS 协议连接到发布点时，使用协议翻转以获得最佳连接。“协议翻转”始于试图通过 MMSU 连接客户端。 MMSU 是 MMS 协议结合 UDP 数据传送。如果 MMSU 连接不成功，则服务器试图使用 MMST。MMST 是 MMS 协议结合 TCP 数据传送。
  如果连接到编入索引的 .asf 文件，想要快进、后退、暂停、开始和停止流，则必须使用 MMS。不能用 UNC 路径快进或后退。若您从独立的 Windows Media Player 连接到发布点，则必须指定单播内容的 URL。若内容在主发布点点播发布，则 URL 由服务器名和 .asf 文件名组成。例如：mms://windows_media_server/sample.asf。其中 windows_media_server 是 Windows Media 服务器名，sample.asf 是您想要使之转化为流的 .asf 文件名。若您有实时内容要通过广播单播发布，则该 URL 由服务器名和发布点别名组成。例如：mms://windows_media_server/LiveEvents。这里 windows_media_server 是 Windows Media 服务器名，而 LiveEvents 是发布点名。