流媒體在Android中有nuplayer來實現(xiàn)的，在開始講解android流媒體前，我們先來講講流媒體傳輸協(xié)議，了解了基本協(xié)議，我們在看代碼的過程中，就會有事半功倍的效果。我們將主要講解RTSP，HTTP,HTTPS, SDP四種協(xié)議。下面就詳情來看看！

一：RTSP協(xié)議簡介

實時流協(xié)議RTSP是一個應(yīng)用層協(xié)議，用于控制具有實時特性的數(shù)據(jù)（例如多媒體流）的傳送。

RTSP協(xié)議一般與RTP/RTCP和RSVP等底層協(xié)議一起協(xié)同工作，提供基于Internet的整套的流服務(wù)。它可以選擇發(fā)送通道（例如：UDP、組播UDP和TCP）和基于RTP的發(fā)送機制。它可以應(yīng)用于組播和點播。RTP, RTCP,RSVP 定義如下：

1. 實時傳輸協(xié)議RTP(Real-time Transport protocol)

2. 實時傳輸控制協(xié)議RTCP(Real-time Transport Control protocol)

3. 實時流協(xié)議RTSP(Real Time Streaming protocol)

4. 資源預(yù)留協(xié)議RSVP(Resource Reserve Protocol)

RTSP協(xié)議機理：

客戶機在向視頻服務(wù)器請求視頻服務(wù)之前，首先通過HTTP協(xié)議從Web服務(wù)器獲取所請求視頻服務(wù)的演示描述（Presentation description ）文件，在RTSP中，每個演示（Presentation）及其所對應(yīng)的媒體流都由一個RTSP URL標識。整個演示及媒體特性都在一個演示描述（Presentation description ）文件中定義，該文件可能包括媒體編碼方式、語言、RTSP URLs、目標地址、端口及其它參數(shù)。用戶在向服務(wù)器請求某個連續(xù)媒體流的服務(wù)之前，必須首先從服務(wù)器獲得該媒體流的演示描述（Presentation description ）文件以得到必需的參數(shù)，演示描述文件的獲取可采用HTTP、email或其他方法。利用該文件提供的信息定位視頻服務(wù)地址（包括視頻服務(wù)器地址和端口號）及視頻服務(wù)的編碼方式等信息。然后客戶機根據(jù)上述信息向視頻服務(wù)器請求視頻服務(wù)。視頻服務(wù)初始化完畢，視頻服務(wù)器為該客戶建立一個新的視頻服務(wù)流，客戶端與服務(wù)器運行實時流控制協(xié)議RTSP，以對該流進行各種VCR控制信號的交換，如播放（PLAY）、停止（PAUSE）、快進、快退等。當服務(wù)完畢，客戶端提出拆線（TEARDOWN）請求。服務(wù)器使用RTP/UDP協(xié)議將媒體數(shù)據(jù)傳輸給客戶端，一旦數(shù)據(jù)抵達客戶端，客戶端應(yīng)用程序即可播放輸出。在流式傳輸中，使用RTP/RTCP/UDP和RTSP/TCP兩種不同的通信協(xié)議在客戶端和服務(wù)器間建立聯(lián)系。如下圖：

RTSP中的所有的操作都是通過服務(wù)器和客戶方的消息應(yīng)答來完成的，其消息包括請求（Request）和響應(yīng)（Response）兩種，RTSP正是通過服務(wù)器和客戶端的消息應(yīng)答來完成媒體流的創(chuàng)建、初始化（SETUP）、VCR控制（PLAY、PAUSE）以及拆線（TEARDOWN）等操作的。如下圖：

RSTP 一些基本方法及用途：

OPTIONS 獲得有效方法

SETUP 建立傳輸

ANNOUNCE 改變媒體文件的類型

DESCRIBE 獲得媒體文件的類型

PLAY 播放

RECORD 刻錄

REDIRECT 轉(zhuǎn)換客戶端到新的服務(wù)器

PAUSE 暫停

SET PARAMETER 設(shè)置設(shè)備，編碼等參數(shù)

TEARDOWN 移除狀態(tài)

完整的播放過程：

GET 過程：

C->W: GET /twister.sdp HTTP/1.1

Host: www.example.com

Accept: application/sdp

W->C: HTTP/1.0 200 OK

Content-Type: application/sdp

v=0

o=- 2890844526 2890842807 IN IP4 192.16.24.202

s=RTSP Session

m=audio 0 RTP/AVP 0

a=control:rtsp://audio.com/twister/audio.en

m=video 0 RTP/AVP 31

a=control:rtsp://video.com/twister/video

SETUP過程：

C->A（audio）: SETUP rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 1

Transport: RTP/AVP/UDP;unicast

;client_port=3056-3057

A->C: RTSP/1.0 200 OK

CSeq: 1

Session: 12345678

Transport: RTP/AVP/UDP;unicast

;client_port=3056-3057;

;server_port=5000-5001

C->V（video）: SETUP rtsp://video.com/twister/video RTSP/1.0

CSeq: 1

Transport: RTP/AVP/UDP;unicast

;client_port=3058-3059

V->C: RTSP/1.0 200 OK

CSeq: 1

Session: 23456789

Transport: RTP/AVP/UDP;unicast

;client_port=3058-3059

;server_port=5002-5003

PLAY 過程：

C->V: PLAY rtsp://video.com/twister/video RTSP/1.0

CSeq: 2

Session: 23456789

Range: smpte=0:10:00-

V->C: RTSP/1.0 200 OK

CSeq: 2

Session: 23456789

Range: smpte=0:10:00-0:20:00

RTP-Info: url=rtsp://video.com/twister/video

;seq=12312232;rtptime=78712811

C->A: PLAY rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 2

Session: 12345678

Range: smpte=0:10:00-

A->C: RTSP/1.0 200 OK

CSeq: 2

Session: 12345678

Range: smpte=0:10:00-0:20:00

RTP-Info: url=rtsp://audio.com/twister/audio.en

;seq=876655;rtptime=1032181

close 過程：

C->A: TEARDOWN rtsp://audio.com/twister/audio.en RTSP/1.0

CSeq: 3

Session: 12345678

A->C: RTSP/1.0 200 OK

CSeq: 3

C->V: TEARDOWN rtsp://video.com/twister/video RTSP/1.0

CSeq: 3

Session: 23456789

V->C: RTSP/1.0 200 OK

CSeq: 3

關(guān)于RTSP的一些時間概念：

normal play time (NPT): seconds, microseconds

MPTE timestamps (seconds, frames)

absolute time (for live events)

二　HTTP協(xié)議簡介

HTTP是一個屬于應(yīng)用層的面向?qū)ο蟮膮f(xié)議，由于其簡捷、快速的方式，適用于分布式超媒體信息系統(tǒng)。它于1990年提出，經(jīng)過幾年的使用與發(fā)展，得到不斷地完善和擴展。目前在WWW中使用的是HTTP/1.0的第六版，HTTP/1.1的規(guī)范化工作正在進行之中，而且HTTP-NG(Next Generation of HTTP)的建議已經(jīng)提出。

1：HTTP協(xié)議的主要特點可概括如下：

1.支持客戶/服務(wù)器模式。

2.簡單快速：客戶向服務(wù)器請求服務(wù)時，只需傳送請求方法和路徑。請求方法常用的有GET、HEAD、POST。每種方法規(guī)定了客戶與服務(wù)器聯(lián)系的類型不同。

由于HTTP協(xié)議簡單，使得HTTP服務(wù)器的程序規(guī)模小，因而通信速度很快。

3.靈活：HTTP允許傳輸任意類型的數(shù)據(jù)對象。正在傳輸?shù)念愋陀蒀ontent-Type加以標記。

4.無連接：無連接的含義是限制每次連接只處理一個請求。服務(wù)器處理完客戶的請求，并收到客戶的應(yīng)答后，即斷開連接。采用這種方式可以節(jié)省傳輸時間。

5.無狀態(tài)：HTTP協(xié)議是無狀態(tài)協(xié)議。無狀態(tài)是指協(xié)議對于事務(wù)處理沒有記憶能力。缺少狀態(tài)意味著如果后續(xù)處理需要前面的信息，則它必須重傳，這樣可能導(dǎo)致每次連接傳送的數(shù)據(jù)量增大。另一方面，在服務(wù)器不需要先前信息時它的應(yīng)答就較快。

2：HTTP協(xié)議的幾個重要概念

1.連接(Connection)：一個傳輸層的實際環(huán)流，它是建立在兩個相互通訊的應(yīng)用程序之間。

2.消息(Message)：HTTP通訊的基本單位，包括一個結(jié)構(gòu)化的八元組序列并通過連接傳輸。

3.請求(Request)：一個從客戶端到服務(wù)器的請求信息包括應(yīng)用于資源的方法、資源的標識符和協(xié)議的版本號

4.響應(yīng)(Response)：一個從服務(wù)器返回的信息包括HTTP協(xié)議的版本號、請求的狀態(tài)(例如“成功”或“沒找到”)和文檔的MIME類型。

5.資源(Resource)：由URI標識的網(wǎng)絡(luò)數(shù)據(jù)對象或服務(wù)。

6.實體(Entity)：數(shù)據(jù)資源或來自服務(wù)資源的回映的一種特殊表示方法，它可能被包圍在一個請求或響應(yīng)信息中。一個實體包括實體頭信息和實體的本身內(nèi)容。

7.客戶機(Client)：一個為發(fā)送請求目的而建立連接的應(yīng)用程序。

8.用戶代理(User agent)：初始化一個請求的客戶機。它們是瀏覽器、編輯器或其它用戶工具。

9.服務(wù)器(Server)：一個接受連接并對請求返回信息的應(yīng)用程序。

10.源服務(wù)器(Origin server)：是一個給定資源可以在其上駐留或被創(chuàng)建的服務(wù)器。

11.代理(Proxy)：一個中間程序，它可以充當一個服務(wù)器，也可以充當一個客戶機，為其它客戶機建立請求。請求是通過可能的翻譯在內(nèi)部或經(jīng)過傳遞到其它的服務(wù)器中。一個代理在發(fā)送請求信息之前，必須解釋并且如果可能重寫它。

代理經(jīng)常作為通過防火墻的客戶機端的門戶，代理還可以作為一個幫助應(yīng)用來通過協(xié)議處理沒有被用戶代理完成的請求。

12.網(wǎng)關(guān)(Gateway)：一個作為其它服務(wù)器中間媒介的服務(wù)器。與代理不同的是，網(wǎng)關(guān)接受請求就好象對被請求的資源來說它就是源服務(wù)器；發(fā)出請求的客戶機并沒有意識到它在同網(wǎng)關(guān)打交道。

網(wǎng)關(guān)經(jīng)常作為通過防火墻的服務(wù)器端的門戶，網(wǎng)關(guān)還可以作為一個協(xié)議翻譯器以便存取那些存儲在非HTTP系統(tǒng)中的資源。

13.通道(Tunnel)：是作為兩個連接中繼的中介程序。一旦激活，通道便被認為不屬于HTTP通訊，盡管通道可能是被一個HTTP請求初始化的。當被中繼的連接兩端關(guān)閉時，通道便消失。當一個門戶(Portal)必須存在或中介(Intermediary)不能解釋中繼的通訊時通道被經(jīng)常使用。

14.緩存(Cache)：反應(yīng)信息的局域存儲。

3：建立連接的方式

HTTP支持2中建立連接的方式：非持久連接和持久連接(HTTP1.1默認的連接方式為持久連接)。

1)非持久連接

讓我們查看一下非持久連接情況下從服務(wù)器到客戶傳送一個Web頁面的步驟。假設(shè)該貝面由1個基本HTML文件和10個JPEG圖像構(gòu)成，而且所有這些對象都存放在同一臺服務(wù)器主機中。再假設(shè)該基本HTML文件的URL為：gpcuster.cnblogs.com/index.html。

下面是具體步騾:

1.HTTP客戶初始化一個與服務(wù)器主機gpcuster.cnblogs.com中的HTTP服務(wù)器的TCP連接。HTTP服務(wù)器使用默認端口號80監(jiān)聽來自HTTP客戶的連接建立請求。

2.HTTP客戶經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字發(fā)出—個HTTP請求消息。這個消息中包含路徑名/somepath/index.html。

3.HTTP服務(wù)器經(jīng)由與TCP連接相關(guān)聯(lián)的本地套接字接收這個請求消息，再從服務(wù)器主機的內(nèi)存或硬盤中取出對象/somepath/index.html，經(jīng)由同一個套接字發(fā)出包含該對象的響應(yīng)消息。

4.HTTP服務(wù)器告知TCP關(guān)閉這個TCP連接(不過TCP要到客戶收到剛才這個響應(yīng)消息之后才會真正終止這個連接)。

5.HTTP客戶經(jīng)由同一個套接字接收這個響應(yīng)消息。TCP連接隨后終止。該消息標明所封裝的對象是一個HTML文件。客戶從中取出這個文件，加以分析后發(fā)現(xiàn)其中有10個JPEG對象的引用。

6.給每一個引用到的JPEG對象重復(fù)步騾1-4。

上述步驟之所以稱為使用非持久連接，原因是每次服務(wù)器發(fā)出一個對象后，相應(yīng)的TCP連接就被關(guān)閉，也就是說每個連接都沒有持續(xù)到可用于傳送其他對象。每個TCP連接只用于傳輸一個請求消息和一個響應(yīng)消息。就上述例子而言，用戶每請求一次那個web頁面，就產(chǎn)生11個TCP連接。

2)持久連接

非持久連接有些缺點。首先，客戶得為每個待請求的對象建立并維護一個新的連接。對于每個這樣的連接，TCP得在客戶端和服務(wù)器端分配TCP緩沖區(qū)，并維持TCP變量。對于有可能同時為來自數(shù)百個不同客戶的請求提供服務(wù)的web服務(wù)器來說，這會嚴重增加其負擔。其次，如前所述，每個對象都有2個RTT的響應(yīng)延長——一個RTT用于建立TCP連接，另—個RTT用于請求和接收對象。最后，每個對象都遭受TCP緩啟動，因為每個TCP連接都起始于緩啟動階段。不過并行TCP連接的使用能夠部分減輕RTT延遲和緩啟動延遲的影響。

在持久連接情況下，服務(wù)器在發(fā)出響應(yīng)后讓TCP連接繼續(xù)打開著。同一對客戶/服務(wù)器之間的后續(xù)請求和響應(yīng)可以通過這個連接發(fā)送。整個Web頁面(上例中為包含一個基本HTMLL文件和10個圖像的頁面)自不用說可以通過單個持久TCP連接發(fā)送:甚至存放在同一個服務(wù)器中的多個web頁面也可以通過單個持久TCP連接發(fā)送。通常，HTTP服務(wù)器在某個連接閑置一段特定時間后關(guān)閉它，而這段時間通常是可以配置的。持久連接分為不帶流水線(without pipelining)和帶流水線(with pipelining)兩個版本。如果是不帶流水線的版本，那么客戶只在收到前一個請求的響應(yīng)后才發(fā)出新的請求。這種情況下，web頁面所引用的每個對象(上例中的10個圖像)都經(jīng)歷1個RTT的延遲，用于請求和接收該對象。與非持久連接2個RTT的延遲相比，不帶流水線的持久連接已有所改善，不過帶流水線的持久連接還能進一步降低響應(yīng)延遲。不帶流水線版本的另一個缺點是，服務(wù)器送出一個對象后開始等待下一個請求，而這個新請求卻不能馬上到達。這段時間服務(wù)器資源便閑置了。

HTTP/1.1的默認模式使用帶流水線的持久連接。這種情況下，HTTP客戶每碰到一個引用就立即發(fā)出一個請求，因而HTTP客戶可以一個接一個緊挨著發(fā)出各個引用對象的請求。服務(wù)器收到這些請求后，也可以一個接一個緊挨著發(fā)出各個對象。如果所有的請求和響應(yīng)都是緊挨著發(fā)送的，那么所有引用到的對象一共只經(jīng)歷1個RTT的延遲(而不是像不帶流水線的版本那樣，每個引用到的對象都各有1個RTT的延遲)。另外，帶流水線的持久連接中服務(wù)器空等請求的時間比較少。與非持久連接相比，持久連接(不論是否帶流水線)除降低了1個RTT的響應(yīng)延遲外，緩啟動延遲也比較小。其原因在于既然各個對象使用同一個TCP連接，服務(wù)器發(fā)出第一個對象后就不必再以一開始的緩慢速率發(fā)送后續(xù)對象。相反，服務(wù)器可以按照第一個對象發(fā)送完畢時的速率開始發(fā)送下一個對象。

4：緩存的機制

HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請求，同時在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路的數(shù)量；HTTP利用一個“過期（expiration）”機制來為此目的。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬；HTTP用“驗證（validation）”機制來為此目的。 

三 RTSP協(xié)議與HTTP協(xié)議的聯(lián)系與區(qū)別

RTSP協(xié)議負責在服務(wù)器和客戶端之間建立并控制一個或多個時間上同步的連續(xù)流媒體，其目標是象HTTP協(xié)議為用戶提供文字和圖形服務(wù)那樣為用戶提供連續(xù)媒體服務(wù)。因此，RTSP協(xié)議的設(shè)計在語法和操作上與HTTP協(xié)議很相似，這樣，對于HTTP的大部分擴展也適用于RTSP。

但是RTSP協(xié)議和HTTP協(xié)議在很多方面有著區(qū)別：

1. HTTP是一個無狀態(tài)協(xié)議，而RTSP協(xié)議是有狀態(tài)的。

2. HTTP本質(zhì)上是一個非對稱協(xié)議，客戶端提出請求而服務(wù)器響應(yīng)；而RTSP是對稱的，服務(wù)器和客戶端都可發(fā)送和響應(yīng)請求。

四 HTTPS傳輸協(xié)議

HTTPS（Secure Hypertext Transfer Protocol）安全超文本傳輸協(xié)議，它是一個安全通信通道，它基于HTTP開發(fā)，用于在客戶計算機和服務(wù)器之間交換信息。它使用安全套接字層(SSL)進行信息交換，簡單來說它是HTTP的安全版。
它是由Netscape開發(fā)并內(nèi)置于其瀏覽器中，用于對數(shù)據(jù)進行壓縮和解壓操作，并返回網(wǎng)絡(luò)上傳送回的結(jié)果。HTTPS實際上應(yīng)用了Netscape的安全全套接字層（SSL）作為HTTP應(yīng)用層的子層。（HTTPS使用端口443，而不是象HTTP那樣使用端口80來和TCP/IP進行通信。）SSL使用40 位關(guān)鍵字作為RC4流加密算法，這對于商業(yè)信息的加密是合適的。HTTPS和SSL支持使用X.509數(shù)字認證，如果需要的話用戶可以確認發(fā)送者是誰。

HTTPS和HTTP的區(qū)別：

1：http和https使用的是完全不同的連接方式,用的端口也不一樣,前者是80,后者是443。
2：https協(xié)議需要到ca申請證書，一般免費證書很少，需要交費。
3：http是超文本傳輸協(xié)議，信息是明文傳輸，https 則是具有安全性的ssl加密傳輸協(xié)議
4：http的連接很簡單,是無狀態(tài)的，而HTTPS協(xié)議是由SSL+HTTP協(xié)議構(gòu)建的可進行加密傳輸、身份認證的網(wǎng)絡(luò)協(xié)議，要比http協(xié)議安全

HTTPS解決的問題：
1 . 信任主機的問題. 采用https 的server 必須從CA 申請一個用于證明服務(wù)器用途類型的證書. 改證書只有用于對應(yīng)的server 的時候,客戶度才信任次主機. 所以目前所有的銀行系統(tǒng)網(wǎng)站,關(guān)鍵部分應(yīng)用都是https 的. 客戶通過信任該證書,從而信任了該主機. 其實這樣做效率很低,但是銀行更側(cè)重安全. 這一點對我們沒有任何意義,我們的server ,采用的證書不管自己issue 還是從公眾的地方issue, 客戶端都是自己人,所以我們也就肯定信任該server.
2 . 通訊過程中的數(shù)據(jù)的泄密和被竄改
1. 一般意義上的https, 就是 server 有一個證書.
a) 主要目的是保證server 就是他聲稱的server. 這個跟第一點一樣.
b) 服務(wù)端和客戶端之間的所有通訊,都是加密的.
i. 具體講,是客戶端產(chǎn)生一個對稱的密鑰,通過server 的證書來交換密鑰. 一般意義上的握手過程.
ii. 加下來所有的信息往來就都是加密的. 第三方即使截獲,也沒有任何意義.因為他沒有密鑰. 當然竄改也就沒有什么意義了.
2. 少許對客戶端有要求的情況下,會要求客戶端也必須有一個證書.
a) 這里客戶端證書,其實就類似表示個人信息的時候,除了用戶名/密碼, 還有一個CA 認證過的身份. 應(yīng)為個人證書一般來說上別人無法模擬的,所有這樣能夠更深的確認自己的身份.
b) 目前少數(shù)個人銀行的專業(yè)版是這種做法,具體證書可能是拿U盤作為一個備份的載體.
HTTPS 一定是繁瑣的.
a) 本來簡單的http協(xié)議,一個get一個response. 由于https 要還密鑰和確認加密算法的需要.單握手就需要6/7 個往返.
i. 任何應(yīng)用中,過多的round trip 肯定影響性能.
b) 接下來才是具體的http協(xié)議,每一次響應(yīng)或者請求, 都要求客戶端和服務(wù)端對會話的內(nèi)容做加密/解密.
i. 盡管對稱加密/解密效率比較高,可是仍然要消耗過多的CPU,為此有專門的SSL 芯片. 如果CPU 信能比較低的話,肯定會降低性能,從而不能serve 更多的請求.
ii. 加密后數(shù)據(jù)量的影響. 所以，才會出現(xiàn)那么多的安全認證提示。

五 SDP協(xié)議

SDP會話描述協(xié)議：為會話通知、會話邀請和其它形式的多媒體會話初始化等目的提供了多媒體會話描述。會話目錄用于協(xié)助多媒體會議的通告，并為會話參與者傳送相關(guān)設(shè)置信息。 SDP 即用于將這種信息傳輸?shù)浇邮斩恕?SDP 完全是一種會話描述格式――它不屬于傳輸協(xié)議 ――它只使用不同的適當?shù)膫鬏攨f(xié)議，包括會話通知協(xié)議 （SAP） 、會話初始協(xié)議（SIP）、實時流協(xié)議 （RTSP）、 MIME 擴展協(xié)議的電子郵件以及超文本傳輸協(xié)議 （HTTP）。SDP 的設(shè)計宗旨是通用性，它可以應(yīng)用于大范圍的網(wǎng)絡(luò)環(huán)境和應(yīng)用程序，而不僅僅局限于組播會話目錄。

SDP是會話描述協(xié)議的縮寫，是描述流媒體初始化參數(shù)的格式，由IETF作為RFC 4566頒布。流媒體是指在傳輸過程中看到或聽到的內(nèi)容，SDP包通常包括以下信息：

（1）會話信息· 會話名和目的

　　 · 會話活動時間

　　 由于參與會話的資源是受限制的，因此包括以下附加信息是非常有用的

　　 · 會話使用的帶寬信息

　　 · 會話負責人的聯(lián)系信息

（2）媒體信息

　　 · 媒體類型，例如視頻和音頻

　　 · 傳輸協(xié)議，例如RTP/UDP/IP和H.320。

· 多播地址和媒體傳輸端口（IP多播會話）

　　 · 用于聯(lián)系地址的媒體和傳輸端口的遠端地址（IP單播會話）

SDP描述由許多文本行組成，文本行的格式為<類型>=<值>，<類型>是一個字母，<值>是結(jié)構(gòu)化的文本串，其格式依<類型>而定。

SDP格式（帶*為可選）:

Session description

v= (protocol version) //該行指示協(xié)議的版本

o= (owner/creator and session identifier)

例如： o=mhandley28908445262890842807INIP4126.16.64.4 //o行中包含與會話所有者有關(guān)的參數(shù)（1：第一個參數(shù)表明會話發(fā)起者的名稱，該參數(shù)可不填寫，如填寫和SIP消息中，from消息頭的內(nèi)容一致:2：第二個參數(shù)為主叫方的會話標識符:3：第三個參數(shù)為主叫方會話的版本，會話數(shù)據(jù)有改變時，版本號遞增:4：第四個參數(shù)定義了網(wǎng)絡(luò)類型，IN表示Internet網(wǎng)絡(luò)類型，目前僅定義該網(wǎng)絡(luò)類型:5：第五個參數(shù)為地址類型，目前支持IPV4和IPV6兩種地址類型:6：第六個參數(shù)為地址：表明會話發(fā)起者的IP地址，該地址為信令面的IP地址，信令PDP激活時為手機分配。）

s= (session name) //表明本次會話的標題，或會話的名稱

i=* (session information)

u=* (URI of description)

e=* (email address)

p=* (phone number)

c=* (connection information - not required if included in all media)

b=* (zero or more bandwidth information lines)

One or more time descriptions ("t=" and "r=" lines, see below)

z=* (time zone adjustments)

k=* (encryption key)

a=* (zero or more session attribute lines)

Zero or more media descriptions

Time description

t= (time the session is active)

r=* (zero or more repeat times)

Media description, if present

m= (media name and transport address)

例如： m=audio3458RTP/AVP09697//m行又稱媒體行，描述了發(fā)送方所支持的媒體類型等信息（1：第一個參數(shù)為媒體名稱：表明支持音頻類型。2：第二個參數(shù)為端口號，表明UE在本地端口為3458上發(fā)送音頻流。3：第三個參數(shù)為傳輸協(xié)議，一般為RTP/AVP協(xié)議。4：四-七參數(shù)為所支持的四種凈荷類型編號）

m=video3400RTP/AVP9899 //m行又稱媒體行，描述了發(fā)送方所支持的媒體類型等信息

i=* (media title)

c=* (connection information - optional if included at

session-level)

b=* (zero or more bandwidth information lines)

k=* (encryption key)

a=* (zero or more media attribute lines)