【文章內(nèi)容簡介】 口的UDP包(rtspu方案)，來控制所標(biāo)記的資源。資源的請求URI是rtsp_URL。應(yīng)盡可能避免在URL中直接使用IP地址。（請參考RFC1924）一個表示或者流是通過基于文本的媒體標(biāo)記來標(biāo)識的，此媒體標(biāo)記使用URLs (RFC 1738 [20])中的字符集和轉(zhuǎn)義規(guī)則[]。URLs可以指向一個流或者一個流的集合，即是說，一個表示。請求視情況可以指向一個完整的表示或者表示中的單個流，見第十章。注意，某些請求方法只能用于流，而不能用于表示，反之亦然。例如：RTSP URL:rtsp://:554/twister/audiotrack標(biāo)識了表示twister中的音頻流。也可以是這樣RTSP URL：rtsp://:554/twister標(biāo)識了表示twister，它可能是由音頻和視頻流組成的。這里并沒有暗示相關(guān)流URL的標(biāo)準(zhǔn)。表示的結(jié)構(gòu)關(guān)系和各個流的URL在表示描述中定義。RTSP URL的路徑組成對客戶端是不透明的，也不暗含任何服務(wù)器的具體文件系統(tǒng)結(jié)構(gòu)。簡單替換URL中的前綴后，表示描述同樣可以用于非RTSP媒體控制協(xié)議。 會議標(biāo)識會議標(biāo)識采用URI標(biāo)準(zhǔn)編碼方法（即是說，LWS被轉(zhuǎn)義為%）編碼，并對RTSP不透明。它們能包含任意字節(jié)值?！颈仨殹勘ＷC會議標(biāo)識在全局中的唯一性。，將用到會議的標(biāo)識值。conferenceid = 1*xchar會議標(biāo)識用以允許RTSP會話從媒體服務(wù)器參與的多媒體會議中獲取參數(shù)。這些會議是用該規(guī)范之外的協(xié)議創(chuàng)建的， [13] 或 SIP [12]協(xié)議。這樣就不用RTSP客戶端顯式地提供傳輸信息，而改用其他方式代替，例如，客戶端要求媒體服務(wù)器使用會議描述中的值。 會話標(biāo)識會話標(biāo)識符是非直讀的任意長度的字符串。線性空格必須是URL轉(zhuǎn)義的。會話標(biāo)識符【必須】隨機產(chǎn)生并且【必須】至少由8個字節(jié)組成，以保證其難以被猜出。（詳見16章）sessionid = 1*( ALPHA | DIGIT | safe ) SMPTE 相對時間戳SMPTE 相對時間戳表示相對于開始剪輯的時間。相對時間戳以SMPTE時間編碼形式表示以保證幀級的訪問精度。時間編碼的格式為：時：分：秒：，并以 剪輯開始為起點。缺省的SMPTE格式為SMPTE 30 drop格式。也可能可通過選擇使用不同SMPTE time來選擇其他SMPTE編碼格式（如SMPTE 25）。幀域（frames field）的時間值在0到29之間。（00和01）。忽略幀值為0的幀，子幀以百分之一幀為單位。 smpterange = smptetype = smptetime [ smptetime ] smptetype = smpte | smpte30drop | smpte25 other timecodes may be added smptetime = 1*2DIGIT : 1*2DIGIT : 1*2DIGIT [ : 1*2DIGIT ] [ . 1*2DIGIT ]例如： smpte=10:12:33:20 smpte=10:07:33 smpte=10:07:0010:07:33: smpte25=10:07:0010:07:33:正常播放時間(NPT)指示流相對于表示(presentation)開始的位置。時間戳由一個十進制小數(shù)組成，以秒為單位，小數(shù)點左邊可以是秒或者以小時：分：秒的形式表示。小數(shù)點右邊表示秒的小數(shù)部分。負值沒有意義。特殊的常數(shù)now定義為現(xiàn)場事件當(dāng)前瞬間。它只能用于現(xiàn)場事件。在DSM CC中，正常播放時間（NPT）是這樣定義的：直觀地講，NPT是用戶和程序聯(lián)系的時鐘。它經(jīng)常在VCR上數(shù)字顯示出來。當(dāng)處于普通播放模式 (倍速= 1)時，NPT正常前進。當(dāng)處于快進掃描模式時(倍速為大于1的正數(shù))，NPT快速前進。當(dāng)處于反向掃描模式(倍速小于1)時，NPT快速后退。當(dāng)處于暫停模式時，NPT停止。NPT（邏輯上）等同于SMPTE時間編碼。nptrange?，? ( npttime [ npttime ] ) | ( npttime )npttime?，?= now | nptsec | npthhmmssnptsec?，，? 1*DIGIT [ . *DIGIT ]npthhmmss = npthh : nptmm : nptss [ . *DIGIT ]npthh?，，?= 1*DIGIT?，?。 any positive numbernptmm?，，?= 1*2DIGIT?，?。 059nptss?，，?= 1*2DIGIT?，?。 059 例如： npt= npt=12:05: npt=now 語法遵循ISO 8601規(guī)則。nptsec標(biāo)志法便于自動生成， ntphhmmss標(biāo)志法便于人閱讀。now常數(shù)允許客戶端請求接收實時反饋而不是存儲或者延時的版本。因為對于這種情況而言，絕對時間和0時間都不適用。 絕對時間絕對時間表示為ISO 8601時間戳，使用UTC(GMT)時間。秒的小數(shù)部分也可能會出現(xiàn)。utcrange?，? clock = utctime [ utctime ]utctime?，?= utcdate T utctime Zutcdate?，?= 8DIGIT?，，，，，，，，，?。 YYYYMMDD utctime?，?= 6DIGIT [ . fraction ] 。 比如，UTC時間為： 選擇標(biāo)簽選項標(biāo)簽是用來指示RTSP新選項的唯一標(biāo)識符。這些標(biāo)簽用于要求(Require)()和代理要求(Proxy Require)()頭部域中。語法：optiontag = 1*xchar要建立新的RTSP選項，可以在選項前加入反轉(zhuǎn)域名的前綴（如： 是個合適的名字），或者在英特網(wǎng)權(quán)威數(shù)字分派委員會注冊（IANA）新的選項。 用IANA注冊新的選項標(biāo)簽當(dāng)注冊新RTSP選項標(biāo)簽的時候，應(yīng)該提供以下信息： *選項的名字和描述。名字長度不限，但是應(yīng)該不多于20字符。名字【必須不】包含任何空格，控制符或句點。 *指出誰擁有選項的改變控制權(quán)（例如，IETF，國際標(biāo)準(zhǔn)化組織，國際電信聯(lián)盟T，其他的國際標(biāo)準(zhǔn)化體，一個團體，一個公司，或者一組公司）。 *描述更為詳細的參考文檔（如果有），比如（按推薦程度排序），RFC，公開發(fā)表的論文，專利文檔，技術(shù)報告，源代碼，或者計算機手冊。 *對于私有的選項，需要給出聯(lián)系地址（郵政地址及電子郵箱）。4 RTSP消息 RTSP是基于文本的協(xié)議，采用ISO 10646 字符集和UTF8編碼方案。每行結(jié)束處行以CRLF標(biāo)記，但接收方需有能力將CR和LF自行解釋成行終止符。基于文本的協(xié)議使得易于以自描述方式增加可選參數(shù)。由于參數(shù)的數(shù)量和命令出現(xiàn)的頻率較低，處理效率不予考慮。如定義得較仔細，文本協(xié)議很容易以腳本語言（如：Tcl、Visual Basic與Perl）實現(xiàn)研究原型。 10646字符集避免了繁瑣的字符集切換，但若應(yīng)用程序使用USASCII字符集，它將不可見RTCP也采用這種編碼方案。ISO 88591通過在高位填充0，直接轉(zhuǎn)成Unicode。標(biāo)志位不為0的ISO 88591字符被表示如100001x 10xxxxxx.。(見 RFC 2279 [21])RTSP信息可通過任何8bit clean的低層傳輸協(xié)議傳送。 請求包括方法、方法作用于其上的對象和進一步描述方法的參數(shù)。除非另外說明，否則方法是冪等的。方法還被設(shè)計為在服務(wù)器端只需要少量或不需要狀態(tài)維護。 消息類型見[]********************[]：RTSP消息由客戶端到服務(wù)器的請求和由服務(wù)器到客戶端的響應(yīng)組成。RTSP message = Request | Response 。 RTSP / messages請求（Request）和響應(yīng)（Response）消息都使用RFC822中實體傳輸部分規(guī)定（作為消息中的有效載荷）的消息格式。兩者的消息都可能包括一起始行，一個或多個頭部域（headers）、一行表示頭部域結(jié)束的空行（即CRLF前沒有內(nèi)容的行），和一個消息主體（messagebody, 可選）。genericmessage = startline *messageheaderCRLF[ messagebody ]startline = RequestLine | StatusLine為了健壯性考慮，服務(wù)器應(yīng)該忽略任何在期望收到請求行時收到的空行。換句話說，如果服務(wù)器正在讀協(xié)議流，在一個消息開始時如果首先收到了CRLF，這個CRLF符應(yīng)被忽略。******************** 消息頭部見[]。********************[]： RTSP頭部域，包括主頭部（GeneralHeader,）、請求頭部（RequestHeader ,）、響應(yīng)頭部（ResponseHeader ,）及實體頭部（EntityHeader,），[7]給出的通用格式定義。每個頭部域由后緊跟冒號的名字，單空格（SP），字符及域值組成。域名是大小寫敏感的。雖然不提倡，頭部域還是可以擴展成多行使用，只要這些行以一個以上的SP或HT開頭就行。RTSPheader = fieldname : [ fieldvalue ] CRLFfieldname = tokenfieldvalue = *( fieldcontent | LWS )fieldcontent = the OCTETs make up the fieldvalue and consisting of either *TEXT or binations of token, tspecials, and quotedstring頭部域接收的順序并不重要，但良好的習(xí)慣是，先發(fā)送主頭部，然后是請求頭部或響應(yīng)頭部，最后是實體頭部。 當(dāng)且僅當(dāng)頭部域的全部域值都用逗號分隔的列表示時（即，（值）），多個有相同域名的RTSP頭部域才可以表示在一個消息里。而且必須能在不改變消息語法的前提下，將并發(fā)的域值加到第一個值后面，之間用逗號分隔，最終能將多個頭部域結(jié)合成域名：域值對。******************** 消息主體見[]。********************[]：RTSP消息的消息主體（如果有）用來攜帶請求或響應(yīng)的主體。僅在使用傳輸編碼(TransferEncoding)時消息主體和實體主體才有所不同，這種情況在傳輸編碼頭部域中有詳細說明。（見[]）messagebody = entitybody| entitybody encoded as per TransferEncoding傳輸編碼必須能解釋所有保證傳輸安全和正確的應(yīng)用程序的傳輸編碼。傳輸編碼是消息而不是實體的一個屬性，因此可以由任一應(yīng)用程序隨著請求/響應(yīng)鏈添加或者刪除。什么時候允許消息帶消息體的規(guī)則在請求和響應(yīng)兩種情況下有所不同。在請求中有無消息主體的標(biāo)志是是否包含內(nèi)容長度或請求消息頭部域中的傳輸編碼頭部域。只有當(dāng)請求方法允許有實體主體的時候才能在請求中包含消息主體。而對于響應(yīng)消息來說，無論消息中是否存在消息主體都與請求方法和響應(yīng)狀態(tài)編碼無關(guān)。所有響應(yīng)頭部請求方法的消息都不能包含消息主體，盡管有時會因為存在實體 頭部域而使人產(chǎn)生誤解。所有1（信息），204（無內(nèi)容），304（未修改）響應(yīng)都不包含消息主體。而其他響應(yīng)則都包含主體，盡管其長度有可能長度為零。******************** 消息長度當(dāng)信息體包含在信息中時，信息體長度由如下因素決定（按優(yōu)先度排列）： 1. 任何【必須不】包含消息體message body的響應(yīng)消息（如1XX，204，及304響應(yīng)），總是在頭域后的第一個空行后就結(jié)束，而不管實體頭部域是否出現(xiàn)在信息中。（注意：空行中只有CRLF。）2. 如果存在內(nèi)容長度頭部域（ContentLength header field），它的值（單位為byte）就表示消息體的長度。如果此頭部域沒有出現(xiàn)，則假設(shè)其值為0。3. 通過服務(wù)器關(guān)閉連接。（關(guān)閉連接不能被用于指示請求主體（request body）的結(jié)束，因為那樣將使服務(wù)器無法回送響應(yīng)。）注意：RTSP目前并不支持HTTP/塊傳輸編碼(見 [])，需要有內(nèi)容頭部域。假如返回了長度適當(dāng)?shù)谋硎久枋?，服?wù)器應(yīng)該總是可以確定它的長度即便它是動態(tài)產(chǎn)生，使得沒有必要采用塊傳輸編碼。如有實體，即使必須有內(nèi)容長度，且長度沒顯式給出，上述規(guī)則也可確保行為的合理性。5 普通頭部域 除了Pragma、TransferEncoding 和 Upgrade頭部，其余見[] generalheader = CacheControl 。 Section | Connection 。 Section | Date 。 Section | Via 。 Section 6 請求從客戶端到服務(wù)器端或與之相反的請求消息，在消息首行中包括：應(yīng)用于資源的方法、資源的標(biāo)識符及所使用的協(xié)議。Request = RequestLine 。 *( generalheader 。 5章 | requestheader 。 | entityheader ) 。 CRLF [ messagebody ] 。 請求行 請求行 = 方法 空格 請求URI 空格 RTSP版本 CRLF Method = DESCRIBE 。 Section | ANNOUNCE 。 Section | GET_PARAMETER 。 Section | OPTIONS Section | PAUSE 。 Section | PLAY 。 Section | RECORD 。 Section | REDIRECT 。 Section | SETUP 。 Section | SET_PARAMETER 。 Section |1