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 是釋出點名。