1 SIP視頻流獲取
這裏的SIP視頻流的獲取是指解碼器通過SIP協議向用戶代理服務器（UAS）獲取視頻流的過程（這裏的sip用的是28181協議）。UAC必須包含生成請求，發送請求和處理響應的功能，解碼器制定的有效SIP請求，至少包括以下頭字段：To、From、Cseq、Call-ID、Max-Forwards 和 Via，我們的主要任務是實現解碼器的這些功能。
過程首先解碼器上線向服務器註冊，並且向cu客戶端進行通知，然後通過客戶端操作解碼器的運行（解碼停止解碼等），實際上所有信令都是通過服務器進行交互的，即解碼器解碼命令由cu發向服務器然後服務器通知解碼器解碼，然後解碼器向服務器邀請視頻，然後解碼，最後結束。
1.1 SIP概要
SIP(Session Initiation Protocol)是一個應用層的信令控制協議。用於創建、修改和釋放一個或多個參與者的會話。這些會話可以是Internet多媒體會議、IP電話或多媒體分發。會話的參與者可以通過組播（multicast）、網狀單播（unicast）或兩者的混合體進行通信。SIP在建立和維持終止多媒體會話協議上，支持5個方面：
1. 用戶定位： 檢查終端用戶的位置，用於通訊。
2. 用戶有效性：檢查用戶參與會話的意願程度。
3. 用戶能力：檢查媒體和媒體的參數。
4. 建立會話：”ringing”,建立會話參數在呼叫方和被叫方。
5. 會話管理：包括髮送和終止會話，修改會話參數，激活服務等等。
1.2 生成請求
UAC制定的有效SIP請求，必須，至少包括以下頭字段：To、From、Cseq、Call-ID、Max-Forwards 和 Via。在所有的 SIP 請求中，這些頭字段都是必需的。這六個頭字段是SIP消息基本的構件塊，它們共同提供大部分關鍵性消息路由服務，包括消息的尋址、響應的路由、限制消息的傳播、消息的排序和事務的唯一標識符。UAC 制定的有效SIP請求除了包含這些頭字段外，還有必需的請求行。這個請求行包含了方法、Request-URI 和 SIP 版本。 具體參考RFC3261文檔。
Request-URI：
消息初始 Request-URI 應該設置成To字段的URI值。但應注意，REGISTER方法例外。保密性原因或者便於將這些字段設置成相同的值（特別是在傳輸過程中，原始 UA 期望改變 Request-URI），可能不符合需要。
To：
頭字段首先指明瞭想要的請求的“邏輯”接收者或者用戶的記錄地址或者作爲請求目標的資源。這不一定是請求的最終接收者。To字段可能包含 SIP 或者SIPS URI，在適當的時候，它也可以使用其它URI模式。所有 SIP 執行必須支持 SIPS URI 模式。任何支持 TLS 的執行必須支持 SIPS URI 模式。To 頭字段考慮到了顯示名稱。 UAC可以知道怎樣以多種方法爲特定的請求填充 To 頭字段。通常，用戶建議To頭字段通過用戶界面填充——可能是手動輸入 URI 或者從地址本中選擇。To 頭字段的更多信息見第 20.39 節。下面是 To 頭字段的實例： To: Carol sip:[email protected]
From：
From頭字段表示請求發起者的邏輯身份，有可能是用戶的記錄地址。和 To 字段一樣，它包含了 URI 和顯示名稱，顯示名稱是可選的。SIP 元素用它來確定應用於請求的處理規則（如，自動呼叫拒絕）。同樣地，因爲沒有邏輯名字，不包含 IP 地址或者 UA 運行主機的正式域名的 From URI 很重要。 下面是 From 頭字段的實例：
From: “Bob” sips:[email protected] ;tag=a48s
From: sip:[email protected];tag=887s
From: Anonymous sip:[email protected];tag=hyh8
Call-ID：
Call-ID頭字段作爲集合一系列消息的唯一標識符。在對話中，每個 UA 發送的所有請求和響應中，Call-ID必須是一樣的。UA的每個註冊中，它應該是一樣的。 在UAC創建的對話外的新請求中，如果不是特定方法行爲覆蓋的，UAC 選擇的Call-ID頭字段必須是在時間和空間上全球唯一的標識符。所有的 SIP UA必須有一種方法來保證其他UA不會產生它們產生的Call-ID 頭字段。注意，當在特定的失效響應後，重發請求以修正請求時（如，認證挑戰），重的請求將不作爲新的請求，因此不需要新的 Call-ID 頭字段。下面是 Call-ID 頭字段的實例：
Call-ID: [email protected]
CSeq：
CSeq頭字段是用作識別和指示事務的。它由序列號和方法組成。此方法必須和請求相匹配。對於對話外的非 REGISTER 請求，此序列號是任意的。此序列號的值必須是值小於2^31的3位的無符號整數。只要遵循上述原則，客戶端就可以隨意地使用一種機制來選擇 CSeq 頭字段值。
實例：
CSeq: 4711 INVITE
Max-Forwards：Max-Forwards頭字段是用作限制請求傳輸到其目的地跳躍的點數。它是一個整數，在每個跳躍點上減一。如果請求在到達其目的地之前。Max- Forwards值到 0，將返回 483(太多跳躍點)錯誤響應，拒絕其請求。 UAC 必須在每個請求中插入 Max-Forwards 頭字段，並賦初始值爲 70。此數字足夠長，可保證在沒有環路時，請求不會在 SIP 網絡中丟失；當存在環路時，此數字不會消耗代理太多的資源。
Via：Via頭字段表示事務中使用的傳輸，並標識了響應發送的位置。僅在選擇了要到達的下一個跳躍點後(這可能包括[4]中過程的使用)，纔在傳輸中加上 Via 頭字段的值。 當 UAC 創建請求時，它必須在請求中插入 Via。在頭字段中的協議名和協議版本必須分別是 SIP 和2.0。Via 頭字段值必須包含分支參數（branch parameter）。此參數用來識別請求創建的事務。此參數同時用於客戶端和服務器。 對於 UA 發送的所有請求，其分支參數的值必須在時間和空間上是唯一的。此規則的異常是CANCEL和非 2xx 響應的 ACK。 分支 ID 必須是以“z9hG4bk”字符開頭。這七個字符用作magic cookie（7認爲是足以確保舊 RFC 2543 執行不會選擇這個值），以便於接收請求的服務器可以確定以本規範描述的格式（即，全球唯一）構造分支 ID。
Contact：Contact頭字段提供了SIP或者SIPS URI，可用於爲隨後請求聯繫 UA 的具體實例。必須正確地表示 Contact 頭字段，幷包含任何請求中的 SIP 或者 SIPS URI，這將導致建立對話。在本規範中定義的方法，僅僅包含INVITE請求。對於這些請求，Contact 的範圍是全局的。即 Contact 頭字段值包括 UA 要接收請求的 URI，即使是在任何對話外的隨後請求中使用，此URI都必須是有效的。 如果 Request-URI 或 top Route頭字段值包含 SIPS URI，Contact 頭字段也必須包含SIPS URI。
Supported and Require：如果 UAC 支持 SIP 擴展，服務器可將此擴展用於響應，UAC應該在請求中引用 Supported 頭字段，列出這些擴展的可選標籤。
Additional Message Components：在創建了新請求，併合理地構造上面所介紹的頭字段後，可以添加任何其他的可選頭字段，作爲具體方法的頭字段。 SIP 請求可能包含 MIME 編碼的消息體。不管請求包含的消息體是什麼類型，必須闡明特定的頭字段來說明主題內容的特徵。
1.3 註冊、註銷
1.3.1 註冊流程
如果用戶要發起和另一個用戶的會話，SIP必須發現可到達目的用戶的當前主機。註冊必須發送 REGISTER 請求給特定類型的 UAS——即是註冊服務器。註冊採用RFC3261規定的基於數字摘要的挑戰應答式安全技術進行註冊，具體流程如下：
基本註冊流程
根據上圖，註冊流程如下：
1. SIP代理向SIP服務器發起REGISTER請求，請求字段中不包含Authorization字段。
2. SIP服務器向SIP代理髮送響應401，並在響應的消息頭WWW_Authenticate字段給出適合SIP代理的認證體制和參數。
3. SIP代理重新想SIP服務器發送REGISTER請求，在請求的Authorization字段給出認證信息。
4. SIP服務器對請求進行驗證，如果SIP代理身份合法，就向SIP代理返回200 OK，否則發送拒絕應答。
1.3.2 註銷
註銷流程和註冊相似，只是在REGISTER請求中將Expires頭域值設爲0，Contact頭域如果設置成爲“*”，Call-Id頭域值設爲和註冊時候的值一樣，並且在Authorization字段給出和註冊時候一樣的認證信息，發送請求，服務器返回200 OK後即完成註銷。
1.3.3 REGISTER請求構造
REGISTER請求添加、刪除和查詢綁定，不建立對話。REGISTER 請求可以在記錄地址和一個或多個聯繫地址之間添加新綁定。合適地通過認證的第三方可以完成代表特定記錄地址的註冊。在 REGISTER 請求和響應中的Record-Route頭字段沒有意義，如果存在，必須忽略。下列頭字段除了Contact 外，必須包含在 REGISTER請求中：
Request-URI：Request-URI指定了註冊服務器指明的定位服務域。（如sip:chicago.com）。不能出現SIPS URI的userinfo和@組件。
To：To頭字段包括記錄地址，可以創建、查詢和修改其註冊。To頭字段和 Request-URI字段主要的不同是，前者包含用戶名。此記錄地址必須是SIP或者SIPS URI。
From：From 頭字段包含負責註冊的人的記錄地址。除非是第三方註冊，此值和To頭字段的值是一樣的。
Call-ID：UAC 所有的註冊應該使用與發送到註冊服務器的註冊相同的Call-ID頭字段值。 如果相同的客戶端使用不同的Call-ID值，那麼註冊服務器不能檢測延時的REGISTER請求是否沒有排序到達。
CSeq：CSeq 值保證 REGISTER 請求適當的排序。對於每個使用相同的Call-ID的REGISTER 請求，UA 必須逐一增加Cseq值。
Contact：REGISTER 請求可能包括有一個或多個地址綁定值的Contact頭字段。
Expires：Expires 參數表示了UA綁定的有效時間，以秒爲單位。如果不提供此參數，那麼將使用expires頭字段的值代替。不規範的值應該視爲等於3600。
1.4 邀請視頻
註冊成功後，解碼器（decode）可以向服務器（S）邀請視頻，這時候客戶端需要構造發送INVITE消息。客戶端成功邀請視頻，基本流程：
需要經過下面四步：
1. decode服務器（S）發起INVITE請求。
2. S向decode發送響應100 Trying。
3. S向decode發送帶有SDP的響應200 OK，SDP內容是視頻傳輸相關參數。
4. decode向S發送帶有SDP的ACK消息，SDP內容根據S向decode的200 OK響應的SDP填寫。
INVITE和ACK構參考4.3小節。需要注意的是從INVITE到 ACK整個過程屬於一個會話，所以Call-ID值應該一樣。服務器返回200 OK的時候，會給to域打上標籤，回覆ACK的時候，To，From和Call-ID應該和回覆消息一樣。另外，向指定設備邀請視頻的時候應該提供設備ID和通道號，比如，設備ID爲131054000100015051，而通道號爲01。
客戶端回覆ACK消息的時候，SDP內容依據服務器回覆的200 OK填寫，客戶端需要提供本機IP和用於接收流的端口號。ACK消息被服務器接收後，服務器開始向該ip主機的該端口發送流。否則服務器繼續發送200 OK。
1.5 結束會話
結束會話需要構造BYE消息，BYE消息的構造參考4.3小節，需要注意的是BYE消息的From、To和Call-ID要與需要結束的會話一樣。BYE請求一旦發送給服務器，UAC 必須認爲會話結束了（並因此停止發送和偵聽媒體）。如果BYE響應是 481（呼叫/事務不存在）或者 408（請求超時），或者請求根本沒有接收到BYE 的響應（即是 INVITE 客戶端事務返回超時），那麼，UAC必須認爲會話和對話結束了。