【文章內(nèi)容簡(jiǎn)介】 RTSP / 1*DIGIT . 1*DIGIT 注意，主從版本應(yīng)當(dāng)被看作單獨(dú)的整數(shù)，因?yàn)樗鼈兌加锌赡茉黾樱瑥亩^(guò)一位整 數(shù)。因而， RTSP/ RTSP/，而 RTSP/ RTSP/。 版本號(hào)前面的 0將被接收方忽略，而在發(fā)送方處也不應(yīng)產(chǎn)生。 本文檔定義了 RTSP 協(xié)議的 版本。發(fā)送本規(guī)范定義的請(qǐng)求（ Request）或響應(yīng)（ Respnse）消息的應(yīng)用必須指明 RTSP的版本為 RTSP/。使用該版本號(hào)意味著發(fā)送消息的應(yīng)用至少有條件的遵循本規(guī)范。 應(yīng)用的 RTSP版本即為應(yīng)用至少能有條件遵循的 RTSP版本中的最高版本。 當(dāng)代理及網(wǎng)關(guān)收到與其自身版本不同的 RTSP請(qǐng)求時(shí)，必須小心處理請(qǐng)求的推送，因?yàn)閰f(xié)議版本表明發(fā)送方的能力，代理或網(wǎng)關(guān)不應(yīng)發(fā)出高于自身版本的消息。如果收到高版本的請(qǐng)求，代理或網(wǎng)關(guān)必須降低該請(qǐng)求的版本，并響應(yīng)一個(gè)錯(cuò)誤。而低版本的請(qǐng)求也應(yīng)在被推送前升級(jí)。代理或網(wǎng)關(guān)響應(yīng)請(qǐng)求時(shí)必須和請(qǐng)求的版本相同。 ******************** RTSP URL rtsp和 rtspu前綴表示要通過(guò) RTSP協(xié)議來(lái)定位網(wǎng)絡(luò)資源。本節(jié)詳細(xì)定義了 RTSP URL的語(yǔ)法和語(yǔ)義。 合法的 Inter 主機(jī)域名或 IP 地址 (用十進(jìn)制數(shù)及點(diǎn)組成 ), 見(jiàn)RFC1123， abs_path 在 []中定義。 ******************** []： abs_path = / rel_path rel_path = [ path ] [ 。 params ] [ ? query ] path = fsegment *( / segment ) fsegment = 1*pchar segment = *pchar params = param *( 。 param ) param = *( pchar | / ) scheme = 1*( ALPHA | DIGIT | + | | . ) _lc = *( pchar | 。 | ? ) query = *( uchar | reserved ) fragment = *( uchar | reserved ) pchar = uchar | : | @ | amp。 | = | + uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | natinal escape = % HEX HEX reserved = 。 | / | ? | : | @ | amp。 | = | + extra = ! | * | 39。 | ( | ) | , safe = $ | | _ | . unsafe = CTL | SP | | | % | | natinal = any CTET excluding ALPHA, DIGIT, reserved, extra, safe, and unsafe 權(quán)威的 URL語(yǔ)法及語(yǔ)義信息請(qǐng)參見(jiàn) RFC1738[4]和 RFC1808[9]。 ******************** 注意： fragment和 query標(biāo)識(shí)符在這時(shí)沒(méi)有明確的定義，需要到 RTSP 服務(wù)器上解釋。 rtsp 前綴要求使用可靠協(xié)議（在 Inter上指 TCP 協(xié)議）發(fā)出命令，而 rtspu前綴則說(shuō)明使用不可靠協(xié)議（在 Inter指 UDP協(xié)議）。 如是端口為空或 沒(méi)指定，則缺省為 554 端口。語(yǔ)義如下：擁有被請(qǐng)求的資源的服務(wù)器主機(jī)通過(guò)監(jiān)聽(tīng) TCP 連接 (rtsp 方案 )或主機(jī)上相應(yīng)端口的 UDP 包 (rtspu 方案 )，來(lái)控制所標(biāo)記的資源。資源的請(qǐng)求 URI是 rtsp_URL。 應(yīng)盡可能避免在 URL中直接使用 IP地址。（請(qǐng)參考 RFC1924） 一個(gè)表示或者流是通過(guò)基于文本的媒體標(biāo)記來(lái)標(biāo)識(shí)的，此媒體標(biāo)記使用 URLs (RFC 1738 [20])中的字符集和轉(zhuǎn)義規(guī)則 []。 URLs可以指向一個(gè)流或者一個(gè)流的集合，即是說(shuō)，一個(gè)表示。請(qǐng)求視情況可以指向一個(gè)完整的表示或者表示 中的單個(gè)流，見(jiàn)第十章。注意，某些請(qǐng)求方法只能用于流，而不能用于表示，反之亦然。 例如： RTSP URL: 標(biāo)識(shí)了表示 twister中的音頻流，它可以通過(guò)發(fā)送基于 TCP連接的 RTSP請(qǐng)求至主機(jī) 554端口進(jìn)行控制。 也可以是這樣 RTSP URL： 標(biāo)識(shí)了表示 twister，它可能是由音頻和 視頻流組成的。 這里并沒(méi)有暗示相關(guān)流 URL 的標(biāo)準(zhǔn)。表示的結(jié)構(gòu)關(guān)系和各個(gè)流的 URL 在表示描述中定義。如一個(gè)表示描述可能將一個(gè)流命名為 ，而將整個(gè)表示命名為 。 RTSP URL的路徑組成對(duì)客戶端是不透明的，也不暗含任何服務(wù)器的具體文件系統(tǒng)結(jié)構(gòu)。 簡(jiǎn)單替換 URL中的前綴后，表示描述同樣可以用于非 RTSP 媒體控制協(xié)議。 會(huì)議標(biāo)識(shí) 會(huì)議標(biāo)識(shí)采用 URI 標(biāo)準(zhǔn)編碼方法（即是說(shuō)， LWS 被轉(zhuǎn)義為 %）編碼，并對(duì) RTSP不透明。它們能包含任意字節(jié)值?！颈仨殹勘ＷC會(huì)議標(biāo)識(shí)在全局中的唯一性。在 ，將用到會(huì)議的標(biāo)識(shí)值。 ference 會(huì)議標(biāo)識(shí)用以允許 RTSP 會(huì)話從媒體服務(wù)器參與的多媒體會(huì)議中獲取參數(shù)。這些會(huì)議是用該規(guī)范之外的協(xié)議創(chuàng)建的，例如 [13] 或 SIP [12]協(xié)議。這樣就不用 RTSP 客戶端顯式地提供傳輸信息，而改用其他方式代替，例如，客戶端要求媒體服務(wù)器使用會(huì)議描述中的值。 會(huì)話標(biāo)識(shí) 會(huì)話標(biāo)識(shí)符是非直讀 的任意長(zhǎng)度的字符串。線性空格必須是 URL轉(zhuǎn)義的。會(huì)話標(biāo)識(shí)符【必須】隨機(jī)產(chǎn)生并且【必須】至少由 8個(gè)字節(jié)組成，以保證 其難以被猜出。（詳見(jiàn) 16章） sessin SMPTE 相對(duì)時(shí)間戳 SMPTE 相對(duì)時(shí)間戳表示相對(duì)于開(kāi)始剪輯的時(shí)間 。相對(duì)時(shí)間戳以 SMPTE時(shí)間編碼形式表示以保證幀級(jí)的訪問(wèn)精度。時(shí)間編碼的格式為：時(shí)：分：秒：幀 .子幀，并以 剪輯開(kāi)始為起點(diǎn)。缺省的 SMPTE格式為 SMPTE 30 drp格式，其幀率是 。也可能可通過(guò)選擇使用不同 SMPTE time來(lái)選擇其他 SMPTE 編碼格式（如 SMPTE 25）。 幀域（ frames field）的時(shí)間值在 0到 29 之間。 30幀每秒和 除了整十分鐘外的每分鐘都要丟掉頭兩個(gè)幀（ 00和 01）。忽略幀值為 0的幀，子幀以百分之一幀為單位。 smpterange = smptetype = smptetime [ smptetime ] smptetype = smpte | smpte30drp | smpte25 。 ther timecdes may be added smptetime = 1*2DIGIT : 1*2DIGIT : 1*2DIGIT [ : 1*2DIGIT ] [ . 1*2DIGIT ] 例如： 10:07:33: 25=10:07:0010:07:33: 正常播放時(shí)間 (NPT)指示流相對(duì)于表示 (presentatin)開(kāi)始的位置。時(shí)間戳由一個(gè)十進(jìn)制小數(shù)組成，以秒為單位，小數(shù)點(diǎn)左邊可以是秒或者以小時(shí)：分：秒的形式表示。小數(shù)點(diǎn)右邊表示秒的小數(shù)部分。 表示開(kāi)始時(shí)對(duì)應(yīng) 。負(fù)值沒(méi)有意義。特殊的常數(shù) nw定義為現(xiàn)場(chǎng)事件當(dāng)前瞬間。它只能用于現(xiàn)場(chǎng)事件。 在 DSM CC 中，正常播放時(shí)間（ NPT）是這樣定義的： 直觀地講， NPT 是用戶和程序聯(lián)系的時(shí)鐘。它經(jīng)常在 VCR 上數(shù)字顯示出來(lái)。當(dāng)處于普通播放模式 (倍速 = 1)時(shí)，NPT 正常前進(jìn)。當(dāng)處于快進(jìn)掃描模式時(shí) (倍速為大于 1的正數(shù) )， NPT 快速前進(jìn)。當(dāng)處于反向掃描模式 (倍速小于 1)時(shí)， NPT快速后退。當(dāng)處于 暫停模式時(shí)， NPT停止。 NPT（邏輯上）等同于 SMPTE時(shí)間編碼。 npt time [ npttime ] ) | ( npttime ) npt sec | npthhmmss npt npt hh : nptmm : nptss [ . *DIGIT ] npt npt 59 npt 59 例如： 125 語(yǔ)法遵循 IS 8601規(guī)則。 nptsec標(biāo)志法便于自動(dòng)生成， ntphhmmss 標(biāo)志法便于人閱讀。 nw常數(shù)允許客戶端請(qǐng)求接收實(shí)時(shí)反饋而不是存儲(chǔ)或者延時(shí)的版本。因?yàn)閷?duì)于這種情況而言，絕對(duì)時(shí)間和 0時(shí)間都不 適用。 絕對(duì)時(shí)間 絕對(duì)時(shí)間表示為 IS 8601時(shí)間戳，使用 UTC(GMT)時(shí)間。秒的小數(shù)部分也可能會(huì)出現(xiàn)。 utc time [ utctime ] utc date T utctime Z utc utc tin 比如， 1996年 11 月 8日 14點(diǎn) 37分 UTC時(shí)間為： 選擇標(biāo)簽 選項(xiàng)標(biāo)簽是用來(lái)指示 RTSP新選項(xiàng)的唯一標(biāo)識(shí)符。這些標(biāo)簽用于要求 (Require)(節(jié) )和代理要求 (Prxy Require)( )頭部域中。 語(yǔ)法： 要建立新的 RTSP 選項(xiàng)，可以在選項(xiàng)前加入反轉(zhuǎn)域名的前綴（如：對(duì)于能訪問(wèn)到 則 是個(gè)合適的名 字），或者在英特網(wǎng)權(quán)威數(shù)字分派委員會(huì)注冊(cè)（ IANA）新的選項(xiàng)。 用 IANA注冊(cè)新的選項(xiàng)標(biāo)簽 當(dāng)注冊(cè)新 RTSP選項(xiàng)標(biāo)簽的時(shí)候，應(yīng)該提供以下信息： *選項(xiàng)的名字和描述。名字長(zhǎng)度不限，但是應(yīng)該不多于 20字符。名字【必須不】包含任何空格，控制符或句點(diǎn)。 *指出誰(shuí)擁有選項(xiàng)的改變控制權(quán)（例如， IETF，國(guó)際標(biāo)準(zhǔn)化組織，國(guó)際電信聯(lián)盟 T，其他的國(guó)際標(biāo)準(zhǔn)化體，一個(gè)團(tuán)體，一個(gè)公司，或者一組公司）。 *描述更為詳細(xì)的參考文檔（如果有），比如（按推薦程度排序）， RFC，公開(kāi)發(fā)表的論文，專(zhuān)利文檔，技 術(shù)報(bào)告，源代碼，或者計(jì)算機(jī)手冊(cè)。 *對(duì)于私有的選項(xiàng)，需要給出聯(lián)系地址（郵政地址及電子郵箱）。 4 RTSP 消息 RTSP是基于文本的協(xié)議，采用 IS 10646 字符集和 UTF8編碼方案。每行結(jié)束處行以 CRLF標(biāo)記，但接收方需有能力將 CR 和 LF自行解釋成行終止符。 基于文本的協(xié)議使得易于以自描述方式增加可選參數(shù)。由于參數(shù)的數(shù)量和命令出現(xiàn)的頻率較低，處理效率不予考慮。如定義得較仔細(xì)，文本協(xié)議很容易以腳本語(yǔ)言（如： Tcl、Visual Basic與 Perl）實(shí)現(xiàn)研究原型。 10646字符 集避免了繁瑣的字符集切換，但若應(yīng)用程序使用 USASCII字符集，它將不可見(jiàn) 。 RTCP也采用這種編碼方案。 IS 88591通過(guò)在高位填充 0，直接轉(zhuǎn)成 Unicde。標(biāo)志位不為 0的 IS 88591字符被表示如 100001x 10xxxxxx.。 (見(jiàn) RFC 2279 [21]) RTSP 信息可通過(guò)任何 8bit clean 的低層傳輸協(xié)議傳送。 請(qǐng)求包括方法、方法作用于其上的對(duì)象和進(jìn)一步描述方法的參數(shù)。除非另外說(shuō)明，否則方法是冪等 的。方法還被設(shè)計(jì)為在服務(wù)器端只需要少量或不需要狀態(tài)維護(hù)。 消息類(lèi)型 見(jiàn) [] ******************** []： RTSP 消息由客戶端到服務(wù)器的請(qǐng)求和由服務(wù)器到客戶端的響應(yīng)組成。 RTSP message = Request | Respnse 。 RTSP / messages 請(qǐng)求（ Request）和響應(yīng)（ Respnse）消息都使用 RFC822中實(shí)體傳輸部分規(guī)定（作為消息中的有效載荷）的消息格式。兩者的消息都可能包括一起始行，一個(gè)或多個(gè)頭部域（ headers）、一行表示頭部域結(jié)束的空行（即 CRLF 前沒(méi)有內(nèi)容的行），和一個(gè)消息主體（ messagebdy, 可選）。 genericmessage = startline *messageheader CRLF [ messagebdy ] startline = RequestLine | StatusLine 為了健壯性考慮，服務(wù)器應(yīng)該忽略任何在期望收到請(qǐng)求行時(shí)收到的空行。換句話說(shuō)，如果服務(wù)器正在讀協(xié)議流，在一個(gè)消息開(kāi)始時(shí)如果首先收到了 CRLF，這個(gè) CRLF符應(yīng)被忽略。 ******************** 消息頭部 見(jiàn) []。 ******************** []： RTSP頭部域，包括主頭部（ GeneralHeader,）、請(qǐng)求頭部（ RequestHeader ,節(jié)）、響應(yīng)頭部（ RespnseHeader ,）及實(shí)體頭部（ En