h323協(xié)議簡介(編輯修改稿)
2025-08-31 09:34 本頁面
【文章內(nèi)容簡介】 音頻的通常處理能力。在必要的情況下，MC還可以通過判斷哪些視頻流和音頻流需要多播來控制會議資源。MC并不直接處理任何媒體信息流，而將它留給MP來處理。MP對音頻、視頻或數(shù)據(jù)信息進行混合、切換和處理。 音頻編碼器對從麥克風輸入的音頻信息進行編碼傳輸，在接收端進行解碼以便輸出到揚聲器，音頻信號包含數(shù)字化且壓縮的語音。為進行語音壓縮，傳送和接收A律和u律。、MPEG1音頻則可選擇支持。 視頻編解碼器在視頻源處將視頻信息進行解碼傳輸，在接收端進行解碼顯示。雖然視頻功能可選，；。在分組網(wǎng)絡(luò)上，、。當支持數(shù)據(jù)會議時，數(shù)據(jù)會議可出現(xiàn)協(xié)同工作，如白板、應(yīng)用共享、文件傳輸、靜態(tài)圖像傳輸、數(shù)據(jù)庫訪問、音頻圖像會議等。 、音頻、控制信息的混合。這些功能包括呼叫控制（建立與拆除）、通力切換、命令和指示信令以及用于開放和描述邏輯信道內(nèi)容的報文等。、。，以便輸出到網(wǎng)絡(luò)接口，同時從網(wǎng)絡(luò)接口輸入報文中檢索出接收到控制流。另外，它還完成邏輯幀、順序編號、糾錯與檢錯功能。 ，控制信令和數(shù)據(jù)流的傳送利用了面向連接的傳輸機制。在IP游戲棧中，IP與TCP協(xié)作，共同完成面向連接的傳輸?？煽康膫鬏敱ＷC了數(shù)據(jù)數(shù)據(jù)包傳輸時的流量控制、連續(xù)性以及正確性，但也可能引起傳輸時延以及占用網(wǎng)絡(luò)寬帶。、呼叫信令信道。而視頻和音頻信息采用不可靠的、面向非連接的傳輸方式，即利用用戶數(shù)據(jù)協(xié)議UDP（UserDatagramProtocol）。UDP無法提供很好的QoS，只提供最少的控制信息，因此傳輸時延較TCP小。在有多個視頻流和音頻流的多媒體通信系統(tǒng)中，基于UDP和不可靠傳輸利用IP多點廣播和由IETF實時傳輸協(xié)議RTP處理視頻和音頻信息。IP多播是以UDP方式進行不可靠多點廣播傳輸?shù)膮f(xié)議。RTP工作于IP多播的頂層，用于處理IP網(wǎng)上的視頻和音頻流，每個UDP包均加上一個包含時間戳和序號的報頭。若接收端配以適當?shù)木彌_，那么它就可以種用時間戳和序號信息復(fù)原，再生數(shù)據(jù)包、記錄失序包、同步語音、圖像和數(shù)據(jù)以及改善邊接重放效果。實時控制協(xié)議RTCP用于RTP的控制。RTCP監(jiān)視服務(wù)質(zhì)量以及網(wǎng)上傳送的信息，并定期將包含服務(wù)質(zhì)量信息的控制信息包發(fā)分給所有通信節(jié)點。 在大型分組網(wǎng)絡(luò)如因特網(wǎng)中，為一個多媒體呼叫保留點足夠的寬帶是很重要的，也是很困難的。另一個IETF協(xié)議資源預(yù)流協(xié)議RSVP允許接收端為某一特殊的數(shù)據(jù)流申請一定數(shù)量的寬帶，并得到一個答復(fù)，確認申請是否被許可。，因為寬帶的預(yù)流對IP網(wǎng)絡(luò)上多媒體通信的
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1