RTP即时传输协定和即时控制协定.doc

RTP即時傳輸協定和即時控制協定 RTP簡介 RTP是一種提供端對端傳輸服務的即時傳輸協定，用來支援在單目標廣播和多目標廣播網路服務中傳輸即時資料，而即時資料的傳輸則由RTCP協定來監視和控制。 RTP定義在RFC 1889中。資訊包的結構包含廣泛用於多媒體的若干個域，包括聲音點播(audio-on-demand)、影視點播(video on demand)、網際網路電話(Internet telephony)和電視會議(videoconferencing)。RTP的規格沒有對聲音和電視的壓縮格式制定標準，它可以被用來傳輸普通格式的檔。例如，WAV或者GSM(Global System for Mobile communications)格式的聲音、MPEG-1和MPEG-2的電視，也可以用來傳輸專有格式存儲的聲音和電視檔。 使用RTP協定的應用程式運行在RTP之上，而執行RTP的程式運行在UDP的上層，目的是為了使用UDP的埠號和檢查和。如圖16-12所示，RTP可以看成是傳輸層的子層。由多媒體應用程式生成的聲音和電視資料塊被封裝在RTP資訊包中，每個RTP資訊包被封裝在UDP消息段中，然後再封裝在IP資料包中。 　 TCP/IP模型 　 應用層(application) 傳輸層 RTP 　 UDP 　 IP 　 資料連結層(data link) 　 物理層(physical) RTP是傳輸層上的協議 從應用開發人員的角度來看，可把RTP執行程式看成是應用程式的一部分，因為開發人員必需把RTP集成到應用程式中。在發送端，開發人員必需把執行RTP協定的程式寫入到創建RTP資訊包的應用程式中，然後應用程式把RTP資訊包發送到UDP的套接介面(socket interface)，如圖16-13所示；同樣，在接收端，RTP資訊包通過UDP套接介面輸入到應用程式，因此開發人員必需把執行RTP協定的程式寫入到從RTP資訊包中抽出媒體資料的應用程式。 TCP/IP模型 　 應用層(application) 　 RTP 　 套接介面 UDP 　 IP 　 資料連結層(data link) 　 物理層(physical) 　 RTP和UDP之間的介面 現以用RTP傳輸聲音為例來說明它的工作過程。假設音源的聲音是64 kb/s的PCM編碼聲音，並假設應用程式取20毫秒的編碼資料為一個資料塊(chunk)，即在一個資料塊中有160個位元組的聲音資料。應用程式需要為這塊聲音資料添加RTP標題生成RTP資訊包，這個標題包括聲音資料的類型、順序號和時間戳。然後RTP資訊包被送到UDP套接介面，在那裏再被封裝在UDP資訊包中。在接收端，應用程式從套接介面處接收RTP資訊包，並從RTP資訊包中抽出聲音資料塊，然後使用RTP資訊包的標題域中的資訊正確地解碼和播放聲音。 如果應用程式不使用專有的方案來提供有效載荷類型(payload type)、順序號或者時間戳，而是使用標準的RTP協定，應用程式就更容易與其他的網路應用程式配合運行，這是大家都希望的事情。例如，如果有兩個不同的公司都在開發網際網路電話軟體，他們都把RTP合併到他們的產品中，這樣就有希望：使用不同公司電話軟體的用戶之間能夠進行通信。 這裏需要強調的是，RTP本身不提供任何機制來確保把資料及時遞送到接收端或者確保其他的服務品質，它也不擔保在遞送過程中不丟失資訊包或者防止資訊包的次序不被打亂。的確，RTP的封裝只是在系統端才能看到，中間的路由器並不區分那個IP資料報是運載RTP資訊包的。 RTP允許給每個媒體源分配一個單獨的RTP資訊包流，例如，攝像機或者麥克風。例如，有兩個團體參與的電視會議，這就可能打開4個資訊包流：兩台攝像機傳送電視流和兩個麥克風傳送聲音流。然而，許多流行的編碼技術，包括MPEG-1和MPEG-2在編碼過程中都把聲音和電視圖像捆綁在一起以形成單一的資料流程，一個方向就生成一個RTP資訊包流。 RTP資訊包沒有被限制只可應用于單目標廣播，它們也可以在一對多(one-to-many)的多目標廣播樹或者在多對多(many-to-many)的多目標廣播樹上傳送。例如，多對多的多目標廣播，在這種應用場合下，所有發送端通常都把他們的RTP資訊包流發送到具有相同多目標廣播位址的多目標廣播樹上。 RTP資訊包標題域 RTP標題由4個資訊包標題域和其他域組成：有效載荷類型(payload type)域，順序號(sequence number)域，時間戳(timestamp)域和同步源識別字(Synchronization Source Identifier)域等。RTP資訊包的標題域的結構如下圖所示： Payload Type(有效載荷類型) Sequence Number(順序號)