RTP協(xié)議分析

時間：2019-03-06 09:48:01

關(guān)鍵字： rtsp rtcp

手機看文章

掃描二維碼
隨時隨地手機看文章

[導讀]RTP協(xié)議分析BYE包表明一個或多個源將要離開。如果混合器收到BYE包，混合器應(yīng)當發(fā)送這個BYE包，并保持SSRC/CSRC不變。如果混合器關(guān)閉，應(yīng)向貢獻源列表中的所有SSRC，包括它自己的SSRC發(fā)

RTP協(xié)議分析

BYE包表明一個或多個源將要離開。如果混合器收到BYE包，混合器應(yīng)當發(fā)送這個BYE包，并保持SSRC/CSRC不變。如果混合器關(guān)閉，應(yīng)向貢獻源列表中的所有SSRC，包括它自己的SSRC發(fā)送BYE包。BYE包可能會有選擇的包含8個字節(jié)的統(tǒng)計字段，其后跟上幾個字節(jié)的文本表明離開的原因。文本字符串編碼格式和SDES中描述的相同。? ??

一．????RTP協(xié)議背景

流（Streaming）是近年在Internet上出現(xiàn)的新概念，其定義非常廣泛，主要是指通過網(wǎng)絡(luò)傳輸多媒體數(shù)據(jù)的技術(shù)總稱。流媒體包含廣義和狹義兩種內(nèi)涵：廣義上的流媒體指的是使音頻和視頻形成穩(wěn)定和連續(xù)的傳輸流和回放流的一系列技術(shù)、方法和協(xié)議的總稱，即流媒體技術(shù)；狹義上的流媒體是相對于傳統(tǒng)的下載-回放方式而言的，指的是一種從Internet上獲取音頻和視頻等多媒體數(shù)據(jù)的新方法，它能夠支持多媒體數(shù)據(jù)流的實時傳輸和實時播放。通過運用流媒體技術(shù)，服務(wù)器能夠向客戶機發(fā)送穩(wěn)定和連續(xù)的多媒體數(shù)據(jù)流，客戶機在接收數(shù)據(jù)的同時以一個穩(wěn)定的速率回放，而不用等數(shù)據(jù)全部下載完之后再進行回放。

流式傳輸有順序流式傳輸(Progressive Streaming)和實時流式傳輸(Realtime Streaming)兩種方式。實時流式傳輸是實時傳送，特別適合現(xiàn)場事件，實時流式傳輸必須匹配連接帶寬，這意味著圖像質(zhì)量會因網(wǎng)絡(luò)速度降低而變差，以減少對傳輸帶寬的需求?！皩崟r”的概念是指在一個應(yīng)用中數(shù)據(jù)的交付必須與數(shù)據(jù)的產(chǎn)生保持精確的時間關(guān)系，這需要相應(yīng)的協(xié)議支持，這樣RTP和RTCP就相應(yīng)的出現(xiàn)了。

實時傳輸協(xié)議RTP（Realtime Transport Protocol）：是針對Internet上多媒體數(shù)據(jù)流的一個傳輸協(xié)議, 由IETF作為RFC1889發(fā)布，現(xiàn)在最新的為RFC3550。RTP被定義為在一對一或一對多的傳輸情況下工作，其目的是提供時間信息和實現(xiàn)流同步。RTP的典型應(yīng)用建立在UDP上，但也可以在TCP等其他協(xié)議之上工作。RTP本身只保證實時數(shù)據(jù)的傳輸，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù)。
實時傳輸控制協(xié)議RTCP（Realtime Transport Control Protocol）：負責管理傳輸質(zhì)量,在當前應(yīng)用進程之間交換控制信息，提供流量控制和擁塞控制服務(wù)。在RTP會話期間，各參與者周期性地傳送RTCP包，包中含有已發(fā)送的數(shù)據(jù)包的數(shù)量、丟失的數(shù)據(jù)包的數(shù)量等統(tǒng)計資料，因此，服務(wù)器可以利用這些信息動態(tài)地改變傳輸速率，甚至改變有效載荷類型。RTP和RTCP配合使用，能以有效的反饋和最小的開銷使傳輸效率最佳化，故特別適合傳送網(wǎng)上的實時數(shù)據(jù)。

二．????RTP協(xié)議原理及工作機制

?下面我們就從RTP以及RTCP的協(xié)議原理，數(shù)據(jù)包格式，工作機制三個方面來對該協(xié)議做一個基本的認識和了解：

2．1RTP協(xié)議原理

2．1．1 RTP協(xié)議原理

RTP協(xié)議原理比較簡單，負責對流媒體數(shù)據(jù)進行封包并實現(xiàn)媒體流的實時傳輸，即它按照RPT數(shù)據(jù)包格式來封裝流媒體數(shù)據(jù)，并利用與它綁定的協(xié)議進行數(shù)據(jù)包的傳輸，具體見本文2.2.1RTP數(shù)據(jù)格式；RTP本身只保證實時數(shù)據(jù)的傳輸，并不能為按順序傳送數(shù)據(jù)包提供可靠的傳送機制，也不提供流量控制或擁塞控制，它依靠RTCP提供這些服務(wù).

?2．1．2 RTCP協(xié)議原理

RTCP原理是向會話中的所有成員周期性地發(fā)送控制包來實現(xiàn)的，應(yīng)用程序通過接收這些控制數(shù)據(jù)包，從中獲取會話參與者的相關(guān)資料，以及網(wǎng)絡(luò)狀況、分組丟失概率等反饋信息，從而能夠?qū)Ψ?wù)質(zhì)量進行控制或者對網(wǎng)絡(luò)狀況進行診斷.

RTCP協(xié)議的功能是通過不同的RTCP數(shù)據(jù)報文(具體描述的見2.2.2RTCP數(shù)據(jù)包格式)來實現(xiàn)的，主要有如下幾種類型：

·????????SR(Sender Report) 發(fā)送端報告，所謂發(fā)送端是指發(fā)出RTP數(shù)據(jù)報的應(yīng)用程序或者終端，發(fā)送端同時也可以是接收端。

·????????RR(ReceiverReport)?接收端報告，所謂接收端是指僅接收但不發(fā)送RTP數(shù)據(jù)報的應(yīng)用程序或者終端。

·????????SDES?源描述，主要功能是作為會話成員有關(guān)標識信息的載體，如用戶名、郵件地址、電話號碼等，此外還具有向會話成員傳達會話控制信息的功能。

·????????BYE　通知離開，主要功能是指示某一個或者幾個源不再有效，即通知會話中的其他成員自己將退出會話。

·????????APP　由應(yīng)用程序自己定義，解決了RTCP的擴展性問題，并且為協(xié)議的實現(xiàn)者提供了很大的靈活性。

RTCP數(shù)據(jù)報攜帶有服務(wù)質(zhì)量監(jiān)控的必要信息，能夠?qū)Ψ?wù)質(zhì)量進行動態(tài)的調(diào)整，并能夠?qū)W(wǎng)絡(luò)擁塞進行有效的控制。由于RTCP數(shù)據(jù)報采用的是組播方式，因此會話中的所有成員都可以通過RTCP數(shù)據(jù)報返回的控制信息，來了解其他參與者的當前情況。

例如在流媒體應(yīng)用場合下，發(fā)送媒體流的應(yīng)用程序?qū)⒅芷谛缘禺a(chǎn)生發(fā)送端報告SR，該RTCP數(shù)據(jù)報含有不同媒體流間的同步信息，以及已經(jīng)發(fā)送的數(shù)據(jù)報和字節(jié)的計數(shù)，接收端根據(jù)這些信息可以估計出實際的數(shù)據(jù)傳輸速率。另一方面，接收端會向所有已知的發(fā)送端發(fā)送接收端報告RR，該RTCP數(shù)據(jù)報含有已接收數(shù)據(jù)報的最大序列號、丟失的數(shù)據(jù)報數(shù)目、延時抖動和時間戳等重要信息，發(fā)送端應(yīng)用根據(jù)這些信息可以估計出往返時延，并且可以根據(jù)數(shù)據(jù)報丟失概率和時延抖動情況動態(tài)調(diào)整發(fā)送速率，以改善網(wǎng)絡(luò)擁塞狀況，或者根據(jù)網(wǎng)絡(luò)狀況平滑地調(diào)整應(yīng)用程序的服務(wù)質(zhì)量。

RTCP具有以下四個功能：?
1、基本功能是提供數(shù)據(jù)傳輸質(zhì)量的反饋.這是RTP作為一種傳輸協(xié)議的主要作用,它與其他協(xié)議的流量和阻塞控制相關(guān).反饋可能對自適應(yīng)編碼有直接作用,但是IP組播的實驗表明它對于從接收機得到反饋信息以診斷傳輸故障也有決定性作用.向所有成員發(fā)送接收反饋可以使"觀察員"評估這些問題是局部的還是全局的.利用類似多點廣播的傳輸機制,可以使某些實體,諸如沒有加入會議的網(wǎng)絡(luò)網(wǎng)絡(luò)業(yè)務(wù)觀察員,接收到反饋信息并作為第三類監(jiān)視員來診斷網(wǎng)絡(luò)故障.反饋功能通過RTCP發(fā)射機和接收機報告實現(xiàn).?
2、RTCP為每個RTP源傳輸一個固定的識別符,稱為標稱名或CNAME.由于當發(fā)生沖突或程序重啟時SSRC可能改變,接收機要用CNAME來跟蹤每個成員.接收機還要用CNAME來關(guān)聯(lián)一系列相關(guān)RTP會話期中來自同一個成員的多個數(shù)據(jù)流,例如同步語音和圖象.?
3、前兩個功能要求所有成員都發(fā)送RTCP包,因此必須控制速率以使RTP成員數(shù)可以逐級增長.通過讓每個成員向所有成員發(fā)送控制包,各個成員都可以獨立地觀察會議中所有成員的數(shù)目.?
4、可選的功能是傳輸最少的會議控制信息,例如在用戶接口中顯示的成員識別.這最可能在"松散控制"的會議中起作用,在"松散控制"會議里,成員可以不經(jīng)過資格控制和參數(shù)協(xié)商而加入或退出會議.RTCP作為一個延伸到所有成員的方便通路,必須要支持具體應(yīng)用所需的所有控制信息通信.

2．2RTP數(shù)據(jù)包格式

2．2．1 RTP數(shù)據(jù)包格式

RTP報文頭格式（見RFC3550 Page12）：

??? 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 12 3 4 5 6 7 8 9 0 1

??+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?? |V=2|P|X|?CC?? |M|???? PT?????| ??????sequence number???????? |

??+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?? |?????????????????????????? timestamp?????????????????????????? |

??+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?? |??????????synchronization source (SSRC) identifier??????????? |

??+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

?? |???????????contributing source (CSRC) identifiers???????????? |

?? |???????????????????????????? ....???????????????????????????? ?|

??+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?以上域具體意義如下：?

版本(V):2比特此域定義了RTP的版本.此協(xié)議定義的版本是2.(值1被RTP草案版本使用,值0用在最初"vat"語音工具使用的協(xié)議中.)?
填料(P):1比特若填料比特被設(shè)置,此包包含一到多個附加在末端的填充比特,不是負載的一部分.填料的最后一個字節(jié)包含可以忽略多少個填充比特.填料可能用于某些具有固定長度的加密算法,或者在底層數(shù)據(jù)單元中傳輸多個RTP包.
擴展(X):1比特若設(shè)置擴展比特,固定頭(僅)后面跟隨一個頭擴展.?
CSRC計數(shù)(CC):4比特 CSRC計數(shù)包含了跟在固定頭后面CSRC識別符的數(shù)目.?
標志(M):1比特標志的解釋由具體協(xié)議規(guī)定.它用來允許在比特流中標記重要的事件,如幀范圍.規(guī)定該標志在靜音后的第一個語音包時置位.

負載類型(PT):7比特此域定義了負載的格式,由具體應(yīng)用決定其解釋.協(xié)議可以規(guī)定負載類型碼和負載格式之間一個默認的匹配.其他的負載類型碼可以通過非RTP方法動態(tài)定義.RTP發(fā)射機在任意給定時間發(fā)出一個單獨的RTP負載類型;此域不用來復用不同的媒體流.?
序列號（sequence number）:16比特每發(fā)送一個RTP數(shù)據(jù)包,序列號加一,接收機可以據(jù)此檢測包損和重建包序列.序列號的初始值是隨機的(不可預(yù)測),以使即便在源本身不加密時(有時包要通過翻譯器,它會這樣做),對加密算法泛知的普通文本攻擊也會更加困難.

時間標志（timestamp）:32比特時間標志反映了RTP數(shù)據(jù)包中第一個比特的抽樣瞬間.抽樣瞬間必須由隨時間單調(diào)和線形增長的時鐘得到,以進行同步和抖動計算.時鐘的分辨率必須滿足要求的同步準確度,足以進行包到達抖動測量.時鐘頻率與作為負載傳輸?shù)臄?shù)據(jù)格式獨立,在協(xié)議中或定義此格式的負載類型說明中靜態(tài)定義,也可以在通過非RTP方法定義的負載格式中動態(tài)說明.若RTP包周期性生成,可以使用由抽樣時鐘確定的額定抽樣瞬間,而不是讀系統(tǒng)時鐘.例如,對于固定速率語音,時間標志鐘可以每個抽樣周期加1.若語音設(shè)備從輸入設(shè)備讀取覆蓋160個抽樣周期的數(shù)據(jù)塊,對于每個這樣的數(shù)據(jù)塊,時間標志增加160,無論此塊被發(fā)送還是被靜音壓縮.?
時間標志的起始值是隨機的,如同序列號.多個連續(xù)的RTP包可能由同樣的時間標志,若他們在邏輯上同時產(chǎn)生.如屬于同一個圖象幀.若數(shù)據(jù)沒有按照抽樣的順序發(fā)送,連續(xù)的RTP包可以包含不單調(diào)的時間標志,如MPEG交織圖象幀.

同步源（SSRC）:32比特 SSRC域用以識別同步源.標識符被隨機生成,以使在同一個RTP會話期中沒有任何兩個同步源有相同的SSRC識別符.盡管多個源選擇同一個SSRC識別符的概率很低,所有RTP實現(xiàn)工具都必須準備檢測和解決沖突.若一個源改變本身的源傳輸?shù)刂?必須選擇新的SSRC識別符,以避免被當作一個環(huán)路源.

有貢獻源（CSRC）列表:0到15項,每項32比特 CSRC列表識別在此包中負載的有貢獻源.識別符的數(shù)目在CC域中給定.若有貢獻源多于15個,僅識別15個.CSRC識別符由混合器插入,用有貢獻源的SSRC識別符.例如語音包,混合產(chǎn)生新包的所有源的SSRC標識符都被陳列,以期在接收機處正確指示交談?wù)?

注意：前12個字節(jié)出現(xiàn)在每個RTP包中,僅僅在被混合器插入時,才出現(xiàn)CSRC識別符列表.

RTP報文擴展頭格式（見RFC3550Page18）：

? 0?????????????????? 1?????????????????? 2?????? ????????????3

??? 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 12 3 4 5 6 7 8 9 0 1

??+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?? |?????defined by profile?????? |?????????? length????????????? |

?? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?? |??????????????????????? header extension?????????????????????? |

?? |???????????????????????????? ....????????????????????????????? |

若RTP頭中的擴展比特位X置1,則一個長度可變的頭擴展部分被加到RTP固定頭之后,.頭擴展包含16比特的長度域,指示擴展項中32比特字的個數(shù),不包括4個字節(jié)擴展頭(因此零是有效值).RTP固定頭之后只允許有一個頭擴展.為允許多個互操作實現(xiàn)獨立生成不同的頭擴展,或某種特定實現(xiàn)有多種不同的頭擴展,擴展項的前16比特用以識別標識符或參數(shù).這16比特的格式由具體實現(xiàn)的上層協(xié)議定義.基本的RTP說明并不定義任何頭擴展本身。

2．2．2 RTCP數(shù)據(jù)包格式

?RTCP包括五種數(shù)據(jù)包類型（RFC3550 Page69）：

abbrev.?name???????????????? value(該值RTCP頭格式中的PT類型字段)

?? SR??????sender report????????? 200 發(fā)送者報告

?? RR??????receiver report??????? 201 接收者報告

?? SDES????source description???? 202 源描述

?? BYE?????goodbye??????????????? 203 退出報告

??APP????? application-defined??? 204 自定義報告

現(xiàn)在我們就SR報文為例詳細描述一下RTCP報文格式（RFC3550Page35）：

??????? 0??????????????????1?????????????????? 2?????????????????? 3

??????? 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

header|V=2|P|??? RC?? |??PT=SR=200?? |???????????? length??????????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |???????????????????????? SSRC of sender??????????????????????? |

??????+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

sender |??????????? ??NTP timestamp, most significant word???????????? |

info??+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |???????????? NTP timestamp, least significantword???????????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |???????????????????????? RTP timestamp???????????????????????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |???????????????????? sender's packet count???????????????????? |

?????? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |????????????????????? sender's octet count???????????????????? |

??????+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report |???????????????? SSRC_1 (SSRC of firstsource)??? ?????????????|

block?+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

? 1??? |fraction lost |?????? cumulative numberof packets lost?????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |?????????? extended highest sequence numberreceived?????????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |????????????????????? interarrival jitter????????????????????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |???????????????????????? last SR (LSR)???????????????????????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |?????????????????? delay since last SR(DLSR)????????????????? |

?????? +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report |???????????????? SSRC_2 (SSRC of secondsource)??????????????? |

block?+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

? 2???:??????????????????????????????...????????????????? ???????????:

??????+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

?????? |????????????????? profile-specificextensions????????????????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

每個RTCP包的開始部分是與RTP數(shù)據(jù)包相類似的固定部分,隨后是一塊結(jié)構(gòu)化單元,它隨負載類型不同長度發(fā)生變化,但是總以32比特終止.

發(fā)射機報告包由3部分組成,若定義,可能跟隨第4個面向協(xié)議的擴展部分.?
第一部分：

8字節(jié)長.該域有以下意義:?
版本(V):2比特 RTP版本識別符,在RTCP包內(nèi)的意義與RTP包中的相同.此協(xié)議中定義的版本號為2.
填料(P):1比特若設(shè)置填料比特,該RTCP包在末端包含一些附加填料比特,并不是控制信息的基本部分.填料的最后一個比特統(tǒng)計了多少個字節(jié)必須被忽略.某些有固定塊大小的加密算法可能需要填料比特.在復合RTCP包中,復合包作為一個整體加密,填料比特只能加在最后一個單包的后面.?
接收報告塊計數(shù)(RC):5比特該包中所含接收報告塊的數(shù)目.零值有效.?
包類型(PT):8比特包含常數(shù)200,用以識別這個為RTCP SR包.?
長度:16比特以32比特字為單位,該RTCP包的長度減一,包括頭和任何填料.(偏移量1保證零值有效,避免了在掃描RTCP包長度時可能發(fā)生的無限循環(huán),同時以32比特為單位避免了對以4為倍數(shù)的有效性檢測.)?
SSRC:32比特 SR包發(fā)起者的同步源標識符.

第二部分：

發(fā)射機信息,20比特長,在每個發(fā)射機報告包中出現(xiàn).它概括了從此發(fā)射機發(fā)出的數(shù)據(jù)傳輸情況.此域有以下意義:?
NTP時間標志:64比特指示了此報告發(fā)送時的壁鐘時刻,它可以與從其它接收機返回的接收報告塊中的時間標志結(jié)合起來,測量到這些接收機的環(huán)路時沿.接收機必須期望此時間標志的準確度遠低于NTP時間標志的分辨率.測量的不確定度不可知,因此也無需指示.某個發(fā)射機,能夠跟蹤逝去時間但是無法跟蹤壁鐘時間,可以用加入會議后的逝去時間代替.假定該值小于68年,則最高比特為零.允許用抽樣時鐘估計逝去壁鐘時間.無法用壁鐘時間或逝去時間的可以設(shè)置此項為零.?
RTP時間標志:32比特?與以上的NTP時間標志對應(yīng)同一時刻,但是與數(shù)據(jù)包中的RTP時間標志具有相同的單位和偏移量.這個一致性可以用來讓NTP時間標志已經(jīng)同步的源間進行媒體內(nèi)/間同步,還可以讓與媒體無關(guān)的接收機估計標稱RTP時鐘頻率.注意在大多數(shù)情況下此時間標志不等于任何臨近的RTP包中的時間標志.然而,通過"RTP時間標志計數(shù)器"和"由在抽樣點上周期性檢測壁鐘時間得到的實際時間"兩者之間的關(guān)系,可以通過相應(yīng)的NTP時間標志計算得到此RTP時間標志.?
發(fā)送的報文數(shù):32比特從開始傳輸?shù)酱薙R包產(chǎn)生時該發(fā)射機發(fā)送的RTP數(shù)據(jù)包總數(shù).若發(fā)射機改變SSRC識別符,該計數(shù)器重設(shè).?
發(fā)送的字節(jié)文數(shù):32比特從開始傳輸?shù)酱薙R包產(chǎn)生時該發(fā)射機在RTP數(shù)據(jù)包發(fā)送的字節(jié)總數(shù)(不包括頭和填料).若發(fā)射機改變SSRC識別符,該計數(shù)器重設(shè).此域可以用來估計平均負載類型數(shù)據(jù)速率.

第三部分：

零到多個接收報告塊,塊數(shù)等于從上一個報告以來該發(fā)射機收聽到的其它源的數(shù)目.每個接收報告塊傳輸關(guān)于從某個同步源來的數(shù)據(jù)包的接收統(tǒng)計信息.若某個源因沖突而改變其SSRC識別符,接收機并不延續(xù)統(tǒng)計數(shù)字.這些統(tǒng)計數(shù)字是:?
SSRC_n(源識別符):32比特在此接收報告塊中信息所屬源的SSRC識別符.?
丟包率:8比特自從前一SR包或RR包發(fā)射以來,從SSRC_n傳來的RTP數(shù)據(jù)包的損失比例,以固定點小數(shù)的形式表示,小數(shù)點在此域的左側(cè),等于將損失比例乘256后取整數(shù)部分.該值定義為損失包數(shù)被期望接收的包數(shù)除,在下一段中定義.若由于復制而導致包損為負值,損失比例值設(shè)為零.注意在收到上一個包后,接收機無法告之以后的包是否丟失,若在上一個接收報告間隔內(nèi)從某個源發(fā)出的所有數(shù)據(jù)包都丟失,那么將不為此源發(fā)送接收報告塊.?
累計包丟失數(shù):24比特從開始接收到現(xiàn)在,從源SSRC_n發(fā)到本源的RTP數(shù)據(jù)包的丟包總數(shù).該值定義為期望接收的包數(shù)減去實際接收的包數(shù),接收的包括復制的或遲到的.由于遲到的包不算作損失,在發(fā)生復制時包損可能為負值.期望接收的包數(shù)定義為擴展的上一接收序號(隨后定義)減去最初接收序號.?
接收到的擴展的最高序列號:32比特低16比特包含從源SSRC_n來的最高接收序列號,高16比特用相應(yīng)的序列號周期計數(shù)器擴展該序列號.注意在同一會議中的不同接收機,若啟動時間明顯不同,將產(chǎn)生不同的擴展項.?
到達間隔抖動:32比特RTP數(shù)據(jù)包到達時刻統(tǒng)計方差的估計值,以時間標志為單位測量,用無符號整數(shù)表達.到達時刻抖動J定義為一對包中接收機相對發(fā)射機的時間跨度差值的平均偏差(平滑后的絕對值).如以下等式所示,該值等于兩個包相對傳輸時間的差值,相對傳輸時間是指包的RTP時間標志和到達時刻接收機時鐘,以同一單位的差值.若Si是包i的RTP時間標志,Ri是包i以RTP時間標志單位的到達時刻值,對于兩個包i和j,D可以表達為?
D(i,j) =(Rj - Ri) - (Sj - Si) = (Rj - Sj) - (Ri - Si)
到達時刻抖動可以在收到從源SSRC_n來的每個數(shù)據(jù)包i后連續(xù)計算,利用該包和前一包i-1的偏差D(按到達順序,而非序號順序),根據(jù)公式J(i) = J(i-1) + (|D(i-1,i)| -J(i-1))/16

計算.無論何時發(fā)送接收報告,都用當前的J值.?
此處描述的抖動計算允許與協(xié)議獨立的監(jiān)視器對來自不同實現(xiàn)的報告進行有效的解釋.?
上一SR報文?(LSR):32比特接收到的來自源SSRC_n的最新RTCP發(fā)射機報告(SR)的64位NTP時間標志的中間32位.若還沒有接收到SR,該域值為零.?
自上一SR的時間延時(DLSR):32比特是從收到來自SSRC_n的SR包到發(fā)送此接收報告塊之間的延時,以1/65536秒為單位.若還未收到來自SSRC_n的SR包,該域值為零.?
假設(shè)SSRC_r為發(fā)出此接收報告塊的接收機.源SSRC_n可以通過記錄收到此接收報告塊的時刻A來計算到SSRC_r的環(huán)路傳輸時延.可以利用最新的SR時間標志(LSR)域計算整個環(huán)路時間A-LSR,然后減去此DLSR域得到環(huán)路傳播時延.?
可以用此來近似測量到一族接收機的距離,盡管有些連接可能有非常不對稱的時延.

RR:接收者報告RTCP包

??????? 0?????????????????? 1?????????????????? 2?????????????????? 3

??????? 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 90 1 2 3 4 5 6 7 8 9 0 1

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

header|V=2|P|??? RC?? |??PT=SR=201?? |???????????? length??????????? |

??????+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

?????? |???????????????????????? SSRC of sender??????????????????????? |

??????+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

report |???????????????? SSRC_1 (SSRC of firstsource)???????????????? |