前言

公司最近指派了ㄧ個 RTSP 伺服器的項目到我的頭上，由於期限給得很短，又要立軍令狀，還要跨平台！？所以這一陣子壓力很大，吃足了苦頭，幾乎每天都失眠。因此為了日後方便緬懷這段艱苦的歲月，特撰此文以紀念之。

夢裡尋它千百度

嚴格來說如果從頭來寫 RTSP 伺服器並不是一、兩支小貓可以辦的到的。因為光單是這個項目，人家就可以單獨開公司賺錢了，比方說 Helix 就是一個例子。所以以我這個光桿司令的作法，就只能找開放源碼（Open Source）來改了，但網路上支援 RTSP 的源碼有很多，像LIVE555、RED5、HELIX、DARWIN、FFMPEG、VLC 甚至一些不明來源的源碼都可以用。只不過框架清楚適合改成公司所需要的樣子卻不多。比方說 VLC、FFMPEG 搞成單一媒體串流還行，但是短時間要改成守護進程（Daemon）的模式，讓眾多客戶端連線，那還不如殺了我先！另外，HELIX、DARWIN 是要錢的，RED5 好像有點肥！其它不明來源的源碼不是 VC 版本沒法跨平台，就是只支援一、兩種編解碼器（Codec），似乎就剩下 LIVE555 可以用了！

只是尋找適合的開放源碼需要時間，首先需要下載源碼作本機編譯（Native Compile）先，接著再作交叉編譯（Cross Compile），然後放到目標機器（Target Machine）上跑跑，看看是不是我們所需要的？接著再大致流覽一下源碼，看看容易不容易閱讀，最後才能決定採用哪一種方案！？再運氣好的情況下，一套流程跑下來，總得花個兩、三天的時間。運氣不好的，比方說找的源碼用到三方工具鍊（ToolChain）或者公用函式庫（Utility），那還得先編譯這些雜七雜八的東西，才可以開始編譯源碼。命苦一點的，有時還得修改那些 gcc 已經不支援的語法，或生成文件（Makefile）。命更衰一點的，使用的公用函式庫與目標機器上的版本不合？這時候還得想辦法作靜態編譯（Static Compile）或者在目標機器上另作符號連結（Symbolic Link 或稱軟連結 （Soft Link）），總之不搞掉半條命還真沒辦法進行測試。這時候所需要的時間就更多了。

兩個禮拜，老闆就給兩個禮拜進行評估，中間還不時穿插一些騷擾與嘲諷。所以只能趕鴨子上架選 LIVE555 了，原因是它的範例還挺完整的。只是，伺服器原本就用了很多的執行緒，又加上它用了大量的繼承、多型與函數指標，讓我在追蹤源碼的時候，經常莫名其妙斷了頭緒。比方說 MediaSource 是負責資料來源的存取類別，而 MediaSink 則是資料發送的類別。但是多層類別繼承下，很多時候你不知道父代類別的執行程序到底是屬於哪一個子代類別？這讓想要了解程式控制流程的人，一個頭兩個大。雖然官網文件中提供了實體關係模型（ER-MODEL, Entity-Relationship Model），但是對於剛入門，尚未了解控制流程的人來說，看了也是白搭。

所以要完成一個具有公司特色的 RTSP 伺服器，必須先了解 LIVE555 的架構，而欲了解 LIVE555 的架構，則必須先了解 RTSP 整個的控制流程，如此方能有效的解決問題。如果單純從官方文件看起，曠日廢時不說，也容易迷失方向。

何謂即時串流協定（RTSP, Real Time Streaming Protocol） ？

這是一個用來控制聲音或影像的多媒體串流協議，並允許同時多個串流需求控制，它的語法和運作跟 HTTP (Hypertext Transfer Protocol) 1.1 類似，使用純文本來發送信息，但是傳輸媒體資料時則另外使用實時傳輸協議 (RTP, Real-time Transport Protocol) 作為媒體資料的傳送，而使用實時傳輸控制協議 (RTCP, Real Time Control Protocol) 作為 RTP 媒體流提供信道外（out-of-band）控制。

RFC (Request For Comment) 組織定義了 RTP 協定，其原始編號為 RFC 1889，現在則由 RFC 3550 取代之。RTP 基本上使用用戶數據報協議（UDP, User Datagram Protocol）來傳送音頻與視頻，當然也可以指定使用傳輸控制協定（TCP, Transmission Control Protocol），只不過 RTP 使用的連線埠號 (Port) 必須為偶數號碼，而 RTCP 的連線埠號必須為該偶數號碼的下一個數字。需要注意的是 UDP 本身並不提供服務品質或傳輸可靠性的保證，所以 RTP 只能利用時間戳記 (Timestamp)、序號 (Sequence Number)，用來達成同步等能力，以及決定封包是否遺失等資訊。

值得注意的是 HTTP 協議是沒有狀態的，在發送一個命令後，連接會斷開，而且命令之間沒有依賴性。而 RTSP 的命令需要知道現在正處於一個什麼狀態，也就是說 RTSP 的命令總是按照順序來發送，某個命令總在另外一個命令之前要發送。RTSP 不管處於什麼狀態都不會去斷掉連接。同時 RTSP 在成功建立連線之後會根據階段作業描述協定 (SDP, Session Description Protocol  (RFC 4566))產生數對連線 (RTP vs RTCP)，例如影像、聲音、字幕等。

HTTP 協議預設使用 80 埠號，而 RTSP 預設使用 554 埠號。如果一些服務器因為某些安全的原因而封掉了這個埠號，那代理和防火牆可能不讓 RTSP 消息通過，需要管理員去放開 554 埠號，而使得 RTSP 協議能通過。不過 LIVE555 預設並偵測使用 80, 8000, 8080 三個埠號。

RTSP 交握程序

在 LIVE555 中關於 RTSP 交握程序，是交由 RTSPServer 這個類別來處理。根據 Socket 每次的連線產生 RTSPClientConnection 類別的實例（Instance），然後 RTSPClientConnection 根據解析（Parse）監聽內容呼叫對應 RTSP 命令的處理函數。例如客戶端首次連線必先傳送 OPTIONS 這個命令，如下所示這是在詢問伺服器端能夠支援哪些 RTSP 命令。

OPTIONS rtsp://10.128.20.180:8080/uvf_channel=1 RTSP/1.0
CSeq: 2
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)

上面 OPTIONS 是 RTSP 命令，後面緊接著 URL 字串。CSeq 則代表命令序號。

RTSP/1.0 200 OK
CSeq: 2
Date: Thu, Jan 23 2014 01:51:54 GMT
Public: OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER

上面是伺服器回應，它告訴客戶端，支援的命令有 OPTIONS, DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, GET_PARAMETER, SET_PARAMETER 等八種。RTPS/1.0 代表使用 RTSP 的版本號，接著是狀態碼 (200 表示正常)，然後是狀態的描述。

DESCRIBE rtsp://10.128.20.180:8080/uvf_channel=1 RTSP/1.0
CSeq: 3
User-Agent: LibVLC/2.0.8 (LIVE555 Streaming Media v2011.12.23)
Accept: application/sdp

客戶端發送媒體描述的請求命令。此時 LIVE555 會嘗試存取媒體，以便在當中取得 SDP 訊息。然後再發送給客戶端。

RTSP/1.0 200 OK
CSeq: 3
Date: Thu, Jan 23 2014 02:53:52 GMT
Content-Base: rtsp://10.128.20.180/uvf_channel=1/
Content-Type: application/sdp
Content-Length: 741

v=0
o=- 1390445632160519 1 IN IP4 10.128.20.180
s=UVF Stream, streamed by the LIVE555 Media Server
i=uvf_channel=1     // 客戶端傳來的 URL 的後輟字串，據此伺服器決定傳送內容。
t=0 0
a=tool:LIVE555 Streaming Media v2013.11.29
a=type:broadcast  // 這邊決定 unicast 或 broadcast
a=control:*
a=range:npt=0-
a=x-qt-text-nam:UVF Stream, streamed by the LIVE555 Media Server
a=x-qt-text-inf:uvf_channel=1 // 此處指定串流的具體來源，可以不是同一台機器
m=video 0 RTP/AVP 96  // 視訊串流，使用 RTP 傳輸，96K 位元率 (Bitrate)
c=IN IP4 0.0.0.0
b=AS:50 
a=rtpmap:96 H264/90000 // 視訊格式 H.264 
a=fmtp:96 packetization-mode=1;profile-level-id=42001E;sprop-parameter-sets=Z0IAHukBQF/y3EgANu6ADN/mANiBCUA=,aM4xUg==
a=control:track1
m=audio 0 RTP/AVP 97  // 音訊串流，使用 RTP 傳輸，97K 位元率 (Bitrate)
c=IN IP4 0.0.0.0
b=AS:96
a=rtpmap:97 MPEG4-GENERIC/16000/2  // MPEG4 編碼格式，16K 採樣頻率，2通道
a=fmtp:97 streamtype=5;profile-level-id=1;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1410  
a=control:track2

如上，伺服器端回傳 SDP 格式的媒體描述文。此時 LIVE555 會斷開與媒體之間的存取。

參考連結

RTP
RTP 閱讀心得整理 
RTSP流媒體數據傳輸的兩種方式（TCP和UDP） 
RTSP 協議詳解 
何謂 SDP ( Session Description Protocol )

附錄

標准 RTSP 消息的錯誤代碼

SDP 協議介紹

SDP, Session Description Protocol，會話 描述協議，完全是一種會話描述格式 ─ 它不屬於傳輸協議 ─ 它只使用不同的適當的傳輸協議，包括 SIP（Session Initiation Protocol，會話初始協議）、SAP（Session Annou ncement Protocol，會話通告協議）實時流協議（RTSP）、MIME 擴展協議的電子郵件以及超文本傳輸協議 （HTTP）。SDP 協議是也是基於文本的協議， 這樣就能保證協議的可擴展性比較強，這樣就使其具有廣泛的應用范圍。SDP 不支持會話內容或媒體編碼的協商，所以在流媒體中只用來描述媒體信息。媒體協商這一塊要用 RTSP 來實現。SDP 是會話描述協議的縮寫，是描述流媒體初始化參數的格式，由 IETF 作為RFC 4566 頒布。流媒體是指在傳輸過程中看到或聽到的內容，SDP 包通常包括以下信息：

SDP協議格式

SDP 描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個字母，<值>是結構化的文本串，其格式依<類型>而定。 ＜type＞=

SDP協議例子：

下面是一個 helix 流媒體服務器的RTSP協議中的SDP協議：

v=0 //SDP version // o field定義的源的一些信息。其格式為：o= o=- 1271659412 1271659412 IN IP4 10.56.136.37 s= i= //session的信息

c=IN IP4 0.0.0.0 //connect 的信息，分別描述了：網絡協議，地址的類型，連接地址。 c=IN IP4 0.0.0.0 t=0 0 //時間信息，分別表示開始的時間和結束的時間，一般在流媒體的直播的時移中見的比較多。

a=SdpplinVersion:1610641560 //描述性的信息 a=StreamCount:integer;2 //用來描述媒體流的信息，表示有兩個媒體流。integer表示信息的格式為整數。 a=control:* a=DefaultLicenseValue:integer;0 //License信息

a=FileType:string;"MPEG4" ////用來描述媒體流的信息說明當前協商的文件是mpeg4格式的文件

a=LicenseKey:string;"license.Summary.Datatypes.RealMPEG4.Enabled"

a=range:npt=0-72.080000 //用來表示媒體流的長度 m=audio 0 RTP/AVP 96 //做為媒體描述信息的重要組成部分描述了媒體信息的詳細內容：表示session的audio是通過RTP來格式傳送的，其payload值為96傳送的端口還沒有定。

b=as:24 //audio 的bitrate b=RR:1800 b=RS:600 a=control:streamid=1 //通過媒體流1來發送音頻

a=range:npt=0-72.080000 //說明媒體流的長度。

a=length:npt=72.080000 a=rtpmap:96 MPEG4-GENERIC/32000/2 //rtpmap的信息，表示音頻為AAC的其sample為32000 a=fmtp:96 profile-level-id=15;mode=AAC-hbr;sizelength=13;indexlength=3;indexdeltalength=3;config=1210 //config為AAC的詳細格式信息

a=mimetype:string;"audio/MPEG4-GENERIC" a=Helix-Adaptation-Support:1

a=AvgBitRate:integer;48000 a=HasOutOfOrderTS:integer;1

a=MaxBitRate:integer;48000 a=Preroll:integer;1000

a=OpaqueData:buffer;"A4CAgCIAAAAEgICAFEAVABgAAAC7gAAAu4AFgICAAhKIBoCAgAEC"

a=StreamName:string;"Audio Track"

下面是video的信息基本和audio的信息相對稱，這裡就不再說了。

m=video 0 RTP/AVP 97 b=as:150 b=RR:11250 b=RS:3750

a=control:streamid=2 a=range:npt=0-72.080000 a=length:npt=72.080000

a=rtpmap:97 MP4V-ES/2500 a=fmtp:97 profile-level-id=1;

a=mimetype:string;"video/MP4V-ES" a=Helix-Adaptation-Support:1

a=AvgBitRate:integer;300000 a=HasOutOfOrderTS:integer;1

a=Height:integer;240 //影片的長度 a=MaxBitRate:integer;300000

a=MaxPacketSize:integer;1400 a=Preroll:integer;1000 a=Width:integer;320 //影片的寬度

a=OpaqueData:buffer;"AzcAAB8ELyARAbd0AAST4AAEk+AFIAAAAbDzAAABtQ7gQMDPAAABAAAAASAAhED6KFAg8KIfBgEC"

a=StreamName:string;"Video Track" ++++++++++++++++++++++++++++++++++++++++++++

注意：

1.) v, o, s, t, m 為必須的, 其他項為可選。

2.) 如果 SDP 語法分析器不能識別某一類型(Type),則整個描述丟失;

3.) 如果「a=」的某屬性值不理解,則予以丟失

4.) 整個協議區分大小寫「=」兩側不允許有空格

5.) 會話級的描述就是媒體級描述的缺省值

6.) 所有均格式為= 3.

SDP在IP電話中的使用 SDP用於構建INVITE和200 OK響應消息的消息體,供主\被叫用戶交換媒體信息.

1. 媒體流的配置

1) 主被叫的媒體描述必須完全對應:主被叫的第n個媒體流(「m=」)對應,都包含」a=rtpmap」.這樣的目的是易於適應靜態淨荷類型到動態淨荷類型的轉換.

2) 如被叫不想接收主叫提出的某個媒體流則在響應中設置該媒體流的端口號為0.並且,必須返回對應的媒體流行.

2. 單播SDP值的設定

1) 對於只發媒體流,端口號無意義,應設為0.

2) 每個媒體流的淨載荷類型例表應傳送兩個信息:能接受/發送的編譯碼,和用以標識這些編譯碼的RTP淨載荷類型號.

3) 如對於某一媒體流,主/被叫沒有公共的媒體格式,被叫仍然要求返回媒體流的」m=」行,端口好為0,同時,不列淨載荷類型.

4) 如果所有媒體流均無公共的媒體格式,則被叫回送400響應(壞請求),並加入304警告頭字段(無媒體類型)

3. 多播操作

1) 接受和發送的多播地址是相同的

2) 被叫不允許改變媒體流的只發,只收,或收/發特性

3) 如果被叫不支持多播,則回送400響應和330警告(多播不可用)

4. 延時媒體流 由於主叫可能實際上是一個和其他協議(如H.323)互同的協議的網關,與S其互同的協議要求呼叫建立後進行媒體協商.這樣,主叫可以先發不帶SDP的INVITE,呼叫建立後可以通過ACK或重新發一個INVITE請求修改被叫的會話描述(SDP).

5. 媒體流保持 如果要求對方進入 HOLD, 即暫時停止發送一個或多個媒體流,這可以用 Re-INVITE, 其會話描述和原來的請求或響應中的描述相同,只是,「c=」行中的保持媒體流的地址置為「0.0.0.0」,還有就是 Re_INVITE 中的 Cseq 得遞增.

6. 對應於SIP中有3個實體字段:

1) Content-Type: 指明消息體類型,有兩種:

i. Application/sdp:表示是SDP會話描述

ii. Text/html:表示是普通文本或HTML格式的描述

2) Content-Encoding:補充說明消息體類型,使用戶可以采用壓縮編碼編輯消息體

3) Content-Length:給出消息體的字節數

7. SDP各type的詳細解釋:

v: 協議版本，版本目前為0，沒有子版本。

o: 會話源， <用戶名>用戶在發起主機上登錄名,如果主機不支持用戶標識的概念,則為「-」 <會話id>一般為數字串,其分配由創建工具決定,建議用網絡時間協議(NTP)時戳,以確保唯一性. <版本>該會話公告的版本,供公告代理服務器檢測同一會話的若干個公告哪個是最新公告.基本要求是會話數據修改後該版本值遞增,建議用NTP時戳 <網絡類型>為文本串」IN」 <地址類型>」IP4」(可為域名或點分十進制)/」IP6」(域名或壓縮文本地址形式) <地址>

s: 會話名，ISO 10646 字符表示的會話名

v: 會話信息，ISO 10646 字符表示的會話信息

u: URI 能提供會議進一步信息的URI地址 e: Email地址，給出會議負責人的聯系信息,他不一定是創建會議公告的人

p: 電話號碼，給出會議負責人的聯系信息,他不一定是創建會議公告的人(國際通用形式)

c: 媒體連接數據，會話級為媒體級的摸認值

b: 給出會話或媒體所用帶寬，單位為kbit/s.修飾語：CT(會議總帶寬，表示所有地點所有媒體的總帶寬)，AS(應用特定最大帶寬，表示一個地點單一媒體帶寬)

t: 時間描述

r: 見上

z: 見上

k: 加密密鑰 k=clear:<加密密鑰>密鑰沒有變換

k=base64:<編碼密鑰>已編碼，因為它含有SDP禁用的字符 k=uri:<獲得密鑰的uri>

k=prompt。SDP沒有提供密鑰但該會話或媒體流是要求加密的。

a: 屬性，一個 m= 行可有多個 a= 行，SDP建議擴展如下：(具體見[1].Page419) 會話級： a=cat:<類別>//給出點分層次式會話分類號,供接收方篩選會話 a=keywds:<關鍵詞>//供接收方篩選會話 a=tool:<工具名和版本號>//創建會話描述的工具名和版本號 a=recvonly/sendrecv/sendonly//收發模式 a=type:<會議類型>//有:廣播,聚會,主席主持,測試,H.323 a=charset:<字符集>//顯示會話名和信息數據的字符集 a=sdplang:<語言標記>//描述所有語言 a=lang:<語言標記>//會話描述的缺省語言或媒體描述的語言 a=framerate:<幀速率>//單位:幀/秒 a=quality:<質量>//視頻的建議質量(10/5/0) a=fmtp:<格式>< 格式特定參數>//定義指定格式的附加參數 媒體級（一般在m後）： a=ptime:<分組時間>//媒體分組的時長(單位:秒)

a=recvonly/sendrecv/sendonly//收發模式 a=orient:<白板方向>//指明白板在屏莫上的方向 a=sdplang:<語言標記>//描述所有語言 a=lang:<語言標記>//會話描述的缺省語言或媒體描述的語言

m: 媒體描述，有5種類型：音頻/視頻/應用(如白板信息)/數據(不向用戶顯示的)/控制 <端口>媒體流發往傳輸層的端口。取決於c=行規定的網絡類型和接下來的傳送層協議：對UDP為1024-65535；對分層編碼應用（c=行沒有多播地址），要給出多播端口數，如：m=video 49170/2 RTP/AVP 31（表示：端口49170和49171為第一對RTP/RTCP端口，49172和49173為第二對的端口）。 <傳送層協議>與c=行的地址類型有關。對大多的媒體在RTP/UDP上傳送，定義2種：RTP/AVP：IETF RTP協議，音/視頻應用文檔。在UDP上傳誦。 Udp：UDP協議。 <格式列表>對音/視頻，就是音/視頻應用文檔中規定媒體淨荷類型。列表中都 有可能用，但第一個為缺省值，分為靜態綁定和動態綁定：靜態綁定即使媒體編碼方式有淨荷類型號完全確定，動態綁定則媒體編碼方式 如時鐘頻率，音頻信道數等）沒有完全確定，需要進一步的屬性說明。分別舉例如下： Alaw的PCM編碼單信道Audio，其淨荷類型號為8，把它發往UDP端口49232，則：m=audio 49232 RTP/AVP 8 16bit線性編碼，雙聲道立體聲，抽樣速率16kHz，其動態淨荷類型號98，則：m=audio 49232 RTP/AVP 98 a=rtpmap:98 L16/16000/2 說明：1）a=rtpmap:<淨荷類型號><編碼名>/<時鐘速率>[/<編碼參數>] 對音頻，編碼參數為音頻信道數；對視頻沒有定義 2）SDP允許rtpmap規定實驗性編碼格式，但編碼名必須以X-起，表示此格式還沒正式登記。 示例： v= 其中：nettype 是 IN, 代表 internet, addrtype 是 IP4 或 IP6。unicast-address 任務創建計算機的地址。 整個這個屬性，是唯一表示一個任務。 e=123@126.com 或 p=+1 616 555-6011 對於一個任務只能兩者之中的一個，表示會議控制者的聯系方式。郵件地址可以是[email]j.doe@example.com[/email] (Jane Doe)形式，括號裡面的是描述聯系人的名稱，或者Jane Doe <[email]j.doe@example.com[ email="">，前面的是聯系人的名稱。 c= 這個連接數據，可以是傳話級別的連接數據，或者是單獨一個媒體數據的連接數據。在是多播時，connection-address 就該是一個多播組地址，當是單播時，connection-address 就該是一個單播地址。對於 addrtype 是 IP4 的情況下，connection-address 不僅包含 IP 地址，並且還要包含 a time to live value(TTL 0-255)，如：c=IN IP4 224.2.36.42/128，IP6 沒有這個 TTL 值。還允許象這樣的 [/]/ 格式的 connection-address。如：c=IN IP4 224.2.1.1/127/3等同於包含c=IN IP4 224.2.1.1/127, c=IN IP4 224.2.1.2/127, c=IN IP4 224.2.1.3/127三行內容。 b=:

bwtype 可以是 CT 或 AS，CT 方式是設置整個會議的帶寬，AS 是設置單個會話的帶寬。缺省帶寬是千比特每秒。

t= 這個可以有行，指定多個不規則時間段，如果是規則的時間段，則 r= 屬性可以使用。start-time 和 stop-time 都遵從 NTP(Network Time Protocol) , 是以秒為單位，自從 1900 以來的時間。要轉換為 UNIX 時間，減去 2208988800。如果 stop-time 設置為 0, 則會話沒有時間限制。如果 start-time 也設置為0，則會話被認為是永久的。 r= 重復次數在時間表示裡面可以如下表示： d - days (86400 seconds) h - hours (3600 seconds) m - minutes (60 seconds) s - seconds (allowed for completeness) z= .... k= k=: a= a=: m= ... m= / ... 其中：可以是，"audio","video", "text", "application" and "message"。 是媒體傳送的端口號，它依賴於 c= 和 。 可以是，udp，RTP/AVP和RTP/SAVP。 例: m=video 1234 RTP/AVP 32 PT encoding media type clock rate name (Hz)24 unassigned V 25 CelB V 90,000 26 JPEG V 90,000 27 unassigned V 28 nv V 90,000 29 unassigned V 30 unassigned V 31 H261 V 90,000 32 MPV V 90,000 （這就是例子中的RTP/AVP類型） 33 MP2T AV 90,000 34 H263 V 90,000 35-71 unassigned ? 72-76 reserved N/A N/A 77-95 unassigned ? 96-127 dynamic ? 自訂 dyn H263-1998 V 90,000 a=cat: 分類，根據分類接收者隔離相應的會話 a=keywds: 關鍵字，根據關鍵字隔離相應的會話 a=tool: 創建任務描述的工具的名稱及版本號 a=ptime: 在一個包裡面的以毫秒為單位的媒體長度 a=maxptime: 以毫秒為單位，能夠壓縮進一個包的媒體量。 a=rtpmap: / [/] a=recvonly a=sendrecv a=sendonly a=inactive， a=orient: 其可能的值，"portrait", "landscape" and "seascape" 。 a=type: 建議值是，"broadcast", "meeting", "moderated", "test" and "H332"。 a=charset: a=sdplang: 指定會話或者是媒體級別使用的語言 a=framerate: 設置最大視頻幀速率 a=quality: 值是0-10 a=fmtp: 在 SIP 協議的包含的內容是 SDP 時，應該把 Content-Type 設置成 application/sdp。